Retencja danych – jak logować ruch.

Jakiś czas temu pisałem o retencji danych, natomiast nigdy nie napisałem jak albo czym logować dane o ruchu sieciowym na Linuksie. Niedawno otrzymałem spam o treści „XXX posiada w swojej ofercie gotowe rozwiązanie do zbierania, przechowywania i analizowania ruchu sieciowego zgodnych z ustawą o retencji danych”. Cena dla małych ISP niewąska, bo za coś, co obsłuży ruch do 1 Gbps, składającego się z jednej sondy, jednego kolektora, softu i wdrożenia wołają dziewięć tysięcy euro.

Całość rozwiązania opiera się o netflow, który od dawna był polecany jako narzędzie do analizy ruchu i wykrywania anomalii. Skoro już padło (nie z moich ust ;-)) odważne stwierdzenie, że jest to sposób zgodny z ustawą o retencji danych, to można przedstawić zarys, jak to zrobić samemu. Tym bardziej, że część ISP nadal korzysta z jakichś mało wydajnych i logujących znacznie mniej informacji rzeźb w stylu logowanie przy pomocy iptables. Oraz – co ważne – rozwiązanie oparte o netflow zapewnia zbieranie o logowaniu ruchu z hostów za NAT (jeśli uruchomione jest na routerze robiącym NAT).

Jeśli chodzi o protokół NetFlow oraz wysyłkę i zbieranie danych, w Debianie (i zapewne większości innych dystrybucji) od dawna dostępne są narzędzia zawarte w pakiecie flow-tools. Do wysyłki służy fprobe, do odbioru flow-capture Jak widać z Wikipedii (próbki sobie tym razem daruję), dla każdego połączenia (flow), zapisywane są czas rozpoczęcia i zakończenia połączenia, typ połączenia, docelowy i źródłowy adres IP, a także porty źródłowy i docelowy. To z ciekawszych rzeczy zgodnych z ustawą. Obciążenie generowane na maszynie zbierającej nie jest duże, choć przy dużych kilkudziesięciu Mbps robi się zauważalne.

Natomiast jeśli chodzi o sFlow, to w Debianie dopiero począwszy od wersji Wheezy, jest narzędzie do zbierania sfdump zawarte w pakiecie nfdump-sflow. Ta wersja korzysta z próbkowania, czyli badany jest co któryś pakiet na interfejsie. Dzięki temu obciążenie na urządzeniu zbierającym, czyli sondzie, jest praktycznie pomijalne.

Zebrane flowy, niezależnie od protokołu zbierania, zajmują stosunkowo niewiele miejsca (automatyczna kompresja), a wykorzystać je można nie tylko na potrzeby związane z retencją danych, ale także (przede wszystkim) do wykrywania anomalii w ruchu sieciowym czy – w przypadku zbierania danych z urządzeń mających informacje związane z BGP – do planowania sieci. Widać wówczas nie tylko z których IP jest ruch, ale także AS docelowy i źródłowy.

Zdaję sobie sprawę, że powyższe to żaden rocket science i pewnie większość sieciowców kojarzy temat (choć mali ISP – niekoniecznie). Natomiast w środowisku związanym z Linuksem może być to pewna ciekawostka. Celowo nie zamieszczam przykładów konfiguracji – dokumentacja jest dobra. Gdyby były pytania lub niejasności, proszę pytać w komentarzach, postaram się odpowiedzieć.

Na koniec uwaga: IANAL, więc nie podejmuję się określenia, czy taki sposób jest zgodny z przepisami nt. retencji danych. Na pewno zebrane dane są dokładniejsze i wygodniejsze, niż logi DHCP, logi z iptables itp. Jeśli chodzi o prywatność, to zawierają dokładnie tyle, na ile pozwala i ile wymaga ustawa. Nie jest logowany sam ruch, tylko dane o nim.

Obowiązki przedsiębiorcy telekomunikacyjnego, czyli kolejne genialne pomysły rządzących.

Po projekcie rozporządzenia w sprawie retencji danych, wejściu tego rozporządzenia w życie oraz pomyśle na minimalną prędkość Internetu, przyszła kolej na kolejny genialny pomysł pomysł rządzących. Chodzi o projekt rozporządzenia dotyczącego wymagań i sposobu zapewnienia przez przedsiębiorcę telekomunikacyjnego warunków dostępu i utrwalania. Znaczy – normalnie mówiąc – podsłuchu i rejestracji rozmów telefonicznych i transmisji internetowych.

Czemu projekt jest fatalny? Po pierwsze, czasy reakcji. W wariancie najbardziej ręcznym są 2h w dzień od 6 do 22 i 4h od 22 do 6. W wariancie najbardziej automatycznym (odpowiednio 15 i 30 minut w wariancie najbardziej automatycznym). Od czasu zgłoszenia zapotrzebowania do umożliwienia podsłuchu/nagrywania. W piątek, świątek, niedzielę. Proponowałbym, żeby miłościwie nam panujący autorzy projektu zapoznali się z czasami reakcji obowiązującymi w branży. I może z prawem pracy jeszcze. I policzyli, ile potrzeba osób, by obsadzić w ten sposób 24/7 jeden „slot”.

Po drugie, ilości ludzi. W najgorszym, czyli najmniej zautomatyzowanym wariancie jest to 1 pracownik na 1500 numerów telefonicznych oraz adresów IP. Przydzielonych ISP. Czyli taki dostawca sieci, który ma nieszczęście mieć IPv6 (minimalnie /48, mniej się nie przydziela) ma – mówiąc kolokwialnie, ale inaczej się nie da – przejebane. Bo klasa /48 to 2 do potęgi 80, czyli 1208925819614629174706176 (1,209 razy 10 do potęgi 24, będzie czytelniej). Nawet ten z pełną automatyką i tylko jednym pracownikiem na 45000 adresów IP będzie musiał mieć 2,68 razy 10^19 pracowników.

Nie wiem, czy wymagana na maturze powinna być bardziej matematyka, czy geografia, bo nie wiem czy rządzący nie orientują się, ilu jest ludzi na świecie, czy po prostu nie policzyli tego. W każdym razie ten wariant likwiduje bezrobocie na Ziemi na parę wieków. Obawiam się jednak, że mają świadomość, co czynią, bo w uzasadnieniu (wpływ regulacji na rynek pracy) piszą o korzystnym wpływie na rynek pracy…

Nawet, jeśli zmienią powyższe z przydzielonych ISP na przydzielone klientom końcowym – niewiele to wnosi. Przy IPv6 klient końcowy dostaje /64 czyli 1,8 razy 10^19 adresów IP… Zresztą, nie potrzeba IPv6. Nawet nędzne 1,6 do 2,5 mln klientów Neostrady w TPSA (znalezione przy okazji tego wpisu, pewnie się zmieniło) to – najbardziej optymistycznie – minimalnie 35 do 55 osób. W samej tylko TPSA, do samej tylko Neostrady. Licząc po klientach, nie IP przydzielonych ISP, czyli bardzo, ale to bardzo skromnie (na to w projekcie nie wpadli jeszcze)…

Najbardziej martwi mnie to, że prawo jest z założenia martwe, niespecjalnie potrzebne (chyba, że u nietypowych ISP pracowałem – pytanie do adminów sieci – jak często u was robią zrzuty/zapisy transmisji, licząc na 1k abonentorok?), daje spore pole do nadużyć (konkurs bez nagród: kto może zlecić w Polsce założenie podsłuchu tego typu?) i będzie służyło zapewne głównie ochronie rządzących, czego przykład mieliśmy podczas użycia ABW do interwencji w sprawie z strony ośmieszającej(?) prezydenta. Aha, gdyby ktoś miał wątpliwości, to Kowalski za góra 5 euro miesięcznie obejdzie to wszystko przy pomocy VPN i silnej kryptografii, podobnie jak przy pomocy ustawy antyhazardowej.

Inne ciekawostki z dokumentu: przedmiot projektowanego aktu prawnego nie jest objęty prawem Unii Europejskiej. Faktycznie, bardziej pachnie Białorusią.

PS Czuję, że na pl.internet.polip znów będzie wrzało…

Źródło, czyli projekt dokumentu.

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.