Blokada portu 25 w Dialogu.

„Trochę” przespałem, a tymczasem Dialog poszedł w ślady TPSA, jeśli chodzi o blokowanie spamu wychodzącego z sieci.

Jak Dialog podaje w informacji prasowej, od dnia 18 maja rozpoczęli blokadę portu 25, służącego do wysłki pocztyspamu. Z tego co wiem, informacje do abonentów zostały wysłane w kwietniu, więc widać, że powoli firmy przestają podchodzić do tego działania superostrożnie i zaczynają po prostu wychodzić z założenia, że „informujemy i wyłączamy”. Nie ma co ukrywać, TPSA zrobiła dużo dobrego swoją odważną (ale też przemyślaną i bardzo starannie zaplanowaną) akcją.

Jeśli chodzi o większych polskich darmowych dostawców usług pocztowych, to i WP i Onet pozwalają na korzystanie z szyfrownia przy logowaniu do poczty, więc niezależnie od dostawcy warto zmienić ustawienia progrmu pocztowego tak, aby korzystać z szyfrowania. Nowy Thunderbird AKA Icedove nawet przy podaniu adresu email z WP lub Onetu sam sugeruje ustawienia z włączonym szyfrowaniem.

Ci, którzy nie mogą korzystać z szyfrownia, powinni zmienić sposób wysyłki poczty (TPSA postarała się bardziej niż Dialog z ilością instrukcji, dlatego linkuję do nich).

Jeśli chodzi o sposób usunięcia blokady, to – w przeciwieństwie do TPSA – użytkownik nie może sam odblokować portu 25, ale także w Dialogu taka możliwość istnieje. Aby odblokować port 25 w Dialogu należy skontaktować się z Dialogiem np. za pośrednictwem infolinii.

Przepisy o retencji danych wchodzą w życie.

Jakiś czas temu pisałem o rozporządzeniu w sprawie retencji danych, jak można się było spodziewać, weszło ono w życie.

VaGla komentuje sprawę szerzej, natomiast mnie interesują zmiany, które zostały wprowadzone, z punktu widzenia administratora sieci ethernetowej.

Przede wszystkim pojawiło się piękne, wieloznaczne słowo lub. Chodzi o §6 rozporządzenia. Port sieciowy (na dodatek o zmienionej definicji), został przeniesiony z dotychczasowego punktu 1 d) w brzmieniu adres IP i numer wykorzystywanego portu sieciowego do punktu 1 f) w brzmieniu identyfikator zakończenia sieci, w którym użytkownik końcowy uzyskał dostęp do Internetu, w szczególności identyfikator cyfrowej linii abonenckiej DSL (Digital Subscriber Line), numer wykorzystywanego portu sieciowego lub adres MAC urządzenia końcowego inicjującego połączenie.

Czyli jeśli logujemy MAC adres (oczywiście nikt nie bierze pod uwagę, że po pierwsze to się zmienia, po drugie sporo kart zintegorwanych nie ma swojego natywnego MAC, po trzecie, że MAC adresy potrafią się – nawet sprzętowo – powtórzyć, ale nie wymagajmy za wiele), to nie trzeba logować portu.

Kolejna sympatyczna (w zasadzie nieunikniona) zmiana, to §14, mówiący o sześciomiesięcznym okresie dostosowawczym dla tych, którzy w dniu wejścia w życie nie spełniają wymagań rozporządzenia. Wejście w życie nie zostało zmienione – był nim 1 stycznia 2010 r.

Czyli ci, którzy nie spełniają wymogów rozporządzenia, mają przed sobą pracowite pół roku.

Szkoda tylko, że rozporządzenie nadal nie jest jasne. Część rzeczy wyjaśnia (albo zaciemnia) dopiero uzasadnienie. Przykładowo, jeśli chodzi o pocztę elektroniczną napisano Odnośnie usługi poczty elektronicznej podkreślić należy, że ustawa zalicza do usług telekomunikacyjnych przekazywanie poczty elektronicznej, a nie usługę poczty elektronicznej.

Zapraszam do uwag, szczególnie prawników i administratorów „osiedlówek” i sieci radiowych, zarówno tych większych, jak i tych mniejszych.

Retencja danych – przepisy wykonawcze.

Ustawa nakazująca operatorom przechowywanie danych o połączeniach istnieje od dawna, ale do tej pory dostawcy internetu robili, co mogli/chcieli, bo przepisów wykonawczych nie było. Wszystko wskazuje na to, że niebawem się to zmieni, bo Minister Infrastruktury przygotowuje rozporządzenie w tej sprawie. I nie wygląda ono różowo, szczególnie dla mniejszych ISP, opierających się o sieci ethernetowe, a ich także – obok dostawców telefonii i poczty elektronicznej – dotyczy.

Projekt rozporządzenia Ministra Infrastruktury w sprawie szczegółowego wykazu danych oraz rodzajów operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dostępnych usług telekomunikacyjnych obowiązanych do ich zatrzymania i przechowywania, o którym piszę, można przeczytać w całości na stronach Ministerstwa Infrastruktury, podobnie jak dołączone do niego uzasadnienie. Gorąco polecam lekturę obu tych pism przed czytaniem reszty wpisu, a na pewno przed komentowaniem.

Pisać będę z punktu widzenia najbliższego mi, czyli dostawcy internetu i tylko na temat dostarczania usługi internetowej. Pocztę elektroniczną i telefony całkowicie pomijam, choć zdanie administratorów – szczególnie serwerów pocztowych – także mnie interesuje i zapraszam do komentowania.

Przede wszystkim wygląda, że ustawodawca albo zapomniał o istnieniu i zasadach działania sieci opartych o ethernet, albo w ogóle nie zdaje sobie sprawy, w jaki sposób one działają. Ruch w obrębie sieci rozgłoszeniowej w takiej sieci zamykać się może w obrębie jednego przełącznika. Switche są różne, ale nawet te zarządzalne rzadko kiedy oferują wsparcie dla logowania czegokolwiek wymaganego w ustawie. O logowaniu połączeń między użytkownikami dostawcy korzystający ze switchy niezarządzalnych mogą całkiem zapomnieć. Oczywiście, można podzielić sieć na mniejsze (dla każdego użytkownika osobna sieć), ale w ten sposób po pierwsze bardziej obciąża się router, po drugie traci się największą zaletę takiej sieci, jaką jest decentralizacja ruchu lokalnego.

W rozporządzeniu brakuje definicji połączenia. O ile w przypadku telefonii sprawa jest dość oczywista i można ją traktować „na chłopski rozum’, o tyle w przypadku Internetu nie jest tak prosto, szczególnie, że istnieją protokoły bezpołączeniowe. Czy każdy pojedynczy wysłany pakiet traktować wówczas jako połączenie? Co traktować jako rozpoczęcie połączenia? Co jako zakończenie połączenia? W której warstwie modelu OSI należy badać połączenie?

Zauważyć należy, że rozporządzenie wprowadzać ma obowiązek logowania portów. W uzasadnieniu można przeczytać, że dotychczasowa praktyka wskazuje, że obecnie w większości przypadków operatorzy posiadają te dane i nie są one specjalnie generowane w celu retencji ale nie wierzę, że mowa w tym przypadku o portach. O ile większość mi znanych małych ISP jest w stanie określić IP użytkownika i ew. aktywność o zadanej porze, o tyle z portami sprawa ma się zupełnie inaczej (faktem jest, że służby praktycznie nigdy o to nie pytają).

Błędem jest też zapis, że port sieciowy określa rodzaj usługi komunikacyjnej w sieci teleinformatycznej. Istnieją oczywiście pewne zalecenia i standardy, ale port ani nie definiuje usługi, ani usługa nie definiuje portu. Nie ma żadnego problemu w wykorzystaniu nietypowego portu dla danej usługi, co więcej, stosunkowo często jest to stosowane (choćby jako redukcja zagrożenia ze strony skanerów szukających podatności w danych usługach).

Ciekawe jest też wymaganie określenia momentu nawiązania połączenia i rozłączenia z Internetem, także w przypadku adresacji statycznej. Oczywiście definicji Internetu brakuje… Co w przypadku popularnego wśród mniejszych operatorów DHCP, gdzie rozpoczęcie owszem, łatwo określić, ale koniec już nie bardzo…

Ostatnia niefortunna rzecz to – moim zdaniem – termin, od kiedy rozporządzenie miałoby zacząć obowiązywać. Planowaną datą jest bowiem 1 stycznia 2010 r., co praktycznie nie daje mniejszym operatorom możliwości dostosowania się do niego, także po doprecyzowaniu ww. nieścisłości.

Szczerze mówiąc, ciekaw jestem opinii, szczególnie administratorów mniejszych, opartych o ethernet sieci, na temat tego projetku. Chętnie też poznam uwagi na temat ew. błędów w mojej interpretacji ww. rozporządzenia.