Tag: debian

Opublikowane w

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.

Opublikowane w

Zawieszanie w wykonaniu Androida.

Gdy poprzednio pisałem o Androidzie na tablecie nie byłem zachwycony. Jestem parę miesięcy używania później i coraz bardziej utwierdzam się w przekonaniu, że to nie to. Zdecydowaną większość rzeczy wolę robić jednak na komputerze przenośnym. Jakość konsumpcji treści, tj. czytania tekstów również niczego nie urywa. Komórka jednak dużo mniejsza, lżejsza i wygodniejsza w trzymaniu. Ale parę zastosowań się znalazł.

Ostatnio miałem przygodę. Zwykle jak nie korzystam z tabletu, to po prostu blokuję ekran i zostawiam go podłączonego do ładowarki. Ostatnio dłuższy czas nie używałem, zerkam, a tam ekran bootowania z animowanym napisem Android. Pomyślałem, że się rebootnął i – z lekkim uśmiechem – że chłopaki z Google skiepścili sprawę, bo Linux się nie wiesza[1], ale kolejne zerknięcia parę godzin później ujawniło, że to zwis.

Nie pomogło odpięcie od ładowarki, krótkie ani długie wciskanie przycisku power. Za to reagował na klawisze dotykowe na obudowie. Skończyło się tak, że zostawiłem go, żeby się rozładował z nadzieją, że się włączy. No i tym razem się udało.

Incydent przypomniał mi, że miałem poćwiczyć bootowanie Debiana na tym urządzeniu. Szybkie poszukiwania zaowocowały odkryciem, że obrazy systemu Wheezy dla tabletów (nieoficjalne oczywiście) zniknęły. A szkoda, bo genialnie uprościłyby sprawę. Tak czy inaczej jak tylko coś zdziałam w tym temacie, to nie omieszkam opisać.

[1] Linux też się wiesza. Tylko pomijalnie rzadko i zwykle deterministycznie, tj. za sprawą np. skopanego modułu.

Opublikowane w

Aktualizacja microcode procesora w Debianie Wheezy – HOWTO.

Jakiś czas temu pisałem o 3 rzeczach, których zapewne nie aktualizujesz w Debianie (piszę w Debianie, ale zapewne prawdziwe jest dla większości dystrybucji opartych na nim). Jeśli chodzi o mikrokod, było prosto, łatwo, i przyjemnie. I minęło, wraz z nadejściem Wheezy’ego.

Magiczne polecenie update-intel-microcode, o którym wówczas pisałem, niestety nie jest już obecne w Debianie poczynając od wersji Wheezy. Zamiast tego, trzeba zrobić wszystko ręcznie. Nie wnikałem, ale zapewne chodziło o kwestie licencyjno-copyrightowe – przy pobieraniu pliku z mikrokodem ze strony Intela jest pytanie o zaakceptowanie licencji. W każdym razie nie ma już narzędzia i trzeba zadbać ręcznie o aktualizację mikrokodu.

Jest za to inne narzędzie, które – wraz z bazowymi mikrokodami – znajduje się w pakiecie intel-microcode.

Po pierwsze wchodzimy na stronę Intela, skąd możemy pobrać mikrokod. Wielkiego wyboru nie widzę, ale może się zmienić – wybieramy najnowszą wersję. Akceptujemy licencję, pobieramy plik. Na dysku ląduje plik o nazwie zbliżonej do microcode-20120606-v2.tgz. Należy go rozpakować, a naszym oczom ukaże się microcode.dat. To są mikrokody, których szukacie! 😉

Po drugie, przy pomocy narzędzia iucode_tool produkujemy z niego pliki w formie strawnej dla pozostałych narzędzi. Ja zdecydowałem się na rozpakowanie ich „na boczek”, żeby ręcznie porównać:

mkdir /tmp/ucode && iucode_tool -K/tmp/ucode/ /tmp/microcode.dat

Po tym zabiegu w katalogu /tmp/ucode mamy w tym momencie całkiem sporą ilość plików, które są gotowymi do użycia mikrokodami. Aby były używane, należy je skopiować do /lib/firmware/intel-ucode. Oczywiście jest możliwość rozpakowywania bezpośrednio w domyślną systemową lokalizację, wystarczy użyć przełącznika –overwrite i nie podawać katalogu docelowego.

Pora na użycie. I tu przyznaję zaczynają się schody. O ile wcześniej bez problemu można było załadować mikrokod online, to teraz iucode_tool -vk /tmp/ucode/* niby się wykonuje (wczytując wszystkie, czyli dla różnych procesorów mikrokody – zupełnie tego nie rozumiem), ale chyba nie działa. W każdym razie śladu w dmesg żadnego… Wygląda, że mikrokod jest dodawany do initramfs. Aby dodać mikrokody znajdujące się w domyślnej systemowej lokalizacji do wszystkich zainstalowanych kerneli, popełniamy:

update-initramfs -k all -uv

Po reboocie powinniśmy działać na nowym mikrokodzie. Uwaga: domyślnie do initramfs trafiają tylko mikrokody dla procesora, na którym jest wydawane polecenie. Można to zmienić w /etc/default/intel-microcode.

Dla procesorów AMD istnieje analogiczny pakiet, ale nie mam takiego pod ręką, by przetestować.

Przy pisaniu wpisu posiłkowałem się opisem Mikrokodu na wiki Arch. Co prawda niewiele się zgadza, ale może komuś się przyda. Warto też zajrzeć na ogłoszenie dotyczące mikrokodu, które znalazłem już po napisaniu wpisu.