Debian Wheezy i Zabbix.

Dziś nieco się zdziwiłem, a raczej rozczarowałem. Okazuje się, że w nadchodzącym stabilnym wydaniu Debiana nie będzie Zabbiksa. W ogóle. Co prawda bardzo łatwo zrobić paczkę z publikowanych źródeł – i tak właśnie robię, bo serwer Zabbiksa czyli zabbix-server warto mieć w najnowszej wersji – ale wersja zabbix-agent  ma już niewielkie znaczenie, gdyż starsze wersje agenta zwykle współpracują ze znacznie nowszymi serwerami bez żadnych problemów. A jednak jest wygodnie było mieć agenta dostępnego w oficjalnym repozytorium pakietów.

Rozwiązań jest kilka: można pakiety robić samodzielnie, być może pojawią się też w backportach, ale dziś dowiedziałem się, że istnieje też repozytorium pakietów prowadzone przez twórców Zabbiksa. Znaleźć w nim można wersje dla Debiana (tylko stable), Ubuntu oraz RHEL.

Data wydania Wheezy’ego podana.

Odbieram dziś pocztę, a tam:

We now have a target date of the weekend of 4th/5th May for the release. We have checked with core teams, and this seems to be acceptable for everyone.  This means we are able to begin the final preparations for a release of Debian 7.0 – „Wheezy”.

Yay!

Jest szansa, że akurat będę u rodziców, co oznacza… Upgrade na desktopie (jedyny desktop bez testing/unstable)! I może na Dockstarze też! I oczywiście wpisik na ten temat. Nie mogę się doczekać. 😉

Z innych ciekawych rzeczy, opisywany kiedyś wajig rozwija się w interesujący sposób. Pojawiły się na przykład opcje update-pciids oraz update-usb-ids, o których wspominano w komentarzu do wpisu o 3 rzeczach, których nie aktualizujesz w Debianie. Co prawda wolałbym mikrokod, ale pożyjemy, zobaczymy… Dotyczy wersji wajig dostępnej we Wheezy.

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.