Argus wszystkowidzący – audyt aktywności w sieci

Wstęp

Argus składa się z dwóch części. Pierwszą z nich jest serwer, kolektor ruchu argus, który rejestruje ruch w sieci z jednego lub większej liczby interfejsów sieciowych danej maszyny. Zebrane informacje są składane w tzw. przepływy sieciowe. Przepływ najogólniej rzecz ujmując definiowany jest jako komunikacja między nadawcą a odbiorcą w oparciu o pewien protokół. Co więcej, komunikacja nie musi być zrealizowana z wykorzystaniem protokołów typowo połączeniowych (jak np. TCP). Równie dobrze może to być choćby ARP. Całość można bardziej szczegółowo prześledzić czytając dalszą część tekstu.

Dane o przepływach są zapisywane na dysku lub wysyłane do podłączonego klienta.

Działanie

1. Zbieranie danych

Zobaczmy i przeanalizujmy kilka przykładów.

argus -d -w argus.flows

W tym przypadku argus będzie pracował w trybie deamona (-d) oraz zapisywał (-w) zebrane dane w pliku o nazwie argus.flows.

argus -w argus.flows – ip and not icmp

W pliku argus.flows zostaną zapisane przefiltrowane informacje na temat ruchu pakietów IP bez pakietów ICMP. Więcej o filtrach BPF w dalszej części.

argus -w argus-udp://192.168.0.1:561 „icmp” -w argus-udp://192.168.0.1:562 „not icmp” – ip

Program argus wspiera wielokrotne strumienie wyjściowe (stdout), każdy z własnym filtrem przepływu. W tym przypadku strumienie wyjściowe wysyłane są pakietami UDP na dany adres. Przepływ pakietów ICMP (filtr „icmp”) przesyłany jest na adres 192.168.0.1 na port 561, a cała reszta („not icmp”) na port 562.

Zanim przejdę dalej chciałbym się odnieść do jednego pytania, które mogło się pojawić. Mianowicie, co zrobić, by bez większych zmian, dodać argusa do naszej sieci?

Rozwiązaniem może być tzn. port mirroring na przełączniku lub urządzenie zwane tapem sieciowym. Każde z nich ma swoje plusy i minusy. W przypadku przełącznika plusem jest to, że wystarczy ustawić specjalny port na istniejącym już urządzeniu, np. span w przypadku urządzeń firmy Cisco lub rap dla urządzeń firmy 3Com, by cała komunikacja była również przekazywana do analizatora. Niestety należy zauważyć, że pakiety są kopiowane aktywnie, obciążając procesor, co w przypadku dużego ruchu może skutkować zmniejszeniem wydajności oraz utratą części informacji, gdyż taki rodzaj portu ma niski priorytet.

Jeśli przyjrzeć się tapowi sieciowemu, to działa on podobnie jak hub: pasywnie kopiuje dane w warstwie fizycznej, nie wymagając przy tym żadnej wcześniejszej konfiguracji, ale w przeciwieństwie do niego może działać w pełnym duplexie, co pozwala na pełne wykorzystanie łącza oraz eliminuje kolizje.

Warto wspomnieć, że tapy sieciowe mają dostępnych kilka mechanizmów zwiększających swoją niezawodność (nie chcemy wprowadzać do sieci dodatkowego komponentu, który charakteryzowałby się wysoką awaryjnością).

 2. Analiza danych

Przejdźmy do drugiej części programu argus do tzw. klientów, narzędzi z rodziny ra*, analizujących dane zebrane przez kolektor ruchu. Omówię tutaj tylko kilka wybranych programów takich jak ra, racluster, rasort oraz ragraph.

Ra

Ra odczytuje oraz filtruje informacje ze strumienia wejściowego (stdin), pliku wygenerowanego przez argus-serwer lub danych netflow (Cisco), jflow (Juniper) czy sflow (InMon). Przetworzone dane można zapisać do pliku (tak samo jak w przypadku argusa, używając -w) albo przesłać do strumienia wyjściowego.

ra -r argus.flows – tcp

Interesująca nas komunikacja TCP zostaje odczytana (-r) z pliku argus.flows oraz przedstawiona na ekranie.

Przejdźmy do tematu filtrów. BPF (ang. BSD Packet Filter) zapewnia surowy interfejs do warstwy łącza danych, dając dostęp do odbieranych oraz wysyłanych pakietów programom, które go wykorzystują. Dodatkowo BPF pozwala na filtrowanie pakietów (stąd filtr BPF), co zapobiega kopiowaniu niechcianych informacji z jądra systemu operacyjnego do oprogramowania działającego w trybie użytkownika.

Interpreter trybu użytkownika zapewnia biblioteka libpcap, która jest używana przez program argus do filtrowania strumienia wejściowego. Argus może również konwertować komunikację z plików w standardzie libpcap, np. z tcpdump. Warto zapoznać się ze składnią filtrów, która składa się z jednego lub kilku prymitywnych rodzajów słów kluczowych. Jednym z nich jest typ, w którego skład wchodzą m.in. sieć (np. net 192.168.0.0/16), port (np. port 80) i host (np. host 10.10.10.101). Kolejnym jest kierunek określający kierunek przepływu ze źródła do punktu docelowego (src) lub z punktu docelowego do źródła (dst), np. przepływ ze źródła do sieci o adresie 192.168.200.0 (dst net 192.168.200.0/24). Należy wspomnieć o wcześniej przedstawionych protokołach, w których skład wchodzą protokoły IP wersji 4 (ipv4) oraz wersji 6 (ipv6). Bardziej skomplikowane filtry tworzy się przez łączenie słów kluczowych przy pomocy koniunkcji (and), alternatyw (or) lub negacji (not). Użyty wcześniej filtr ip odpowiada alternatywie filtrów IP wersji 4 i 6 (ipv4 or ipv6).

Jak już wcześniej wspomniałem, nie tylko argus może być źródłem informacji. Weźmy dla przykładu protokół netflow, który jest prekursorem przepływów. Jest on obecnie kompatybilny z argusem aż do wersji 8 (są prowadzone prace nad kompatybilnością z wersją 9). Jeśli mamy w naszej sieci urządzenia obsługujące ten protokół, możemy je tak skonfigurować, by wysyłały informacje wprost do naszego klienta odczytującego dane. Standardowo informacje są eksportowane pakietami UDP na port 2055, aby je odczytać, należy określić źródło danych (-C).

ra -C 10.10.10.1:2055

Racluster

Kolejnym interesującym narzędziem jest racluster. Jego zadaniem jest agregacja wpisów w zależności od kryteriów przepływu zadanych w wierszu poleceń lub w pliku konfiguracyjnym. Podobnie jak inne programy z rodziny ra* on również obsługuje filtry BPF oraz możliwość formatowania danych wyjściowych.

racluster -r argus.flows -m proto -s stime dur trans proto srate drate pkts bytes state – ipv4

W tym przypadku agregujemy dane o poszczególnych protokołach przesyłanych protokołem ipv4 (-m proto oraz filtr ipv4). Równocześnie zmieniliśmy dane wyjściowe (-s), by prezentowały czas pojawienia się pierwszego wpisu (stime), czas trwania (dur), liczbę przepływów (trans), protokół (proto), częstotliwość pakietów ze źródła (srate), częstotliwość pakietów z punktu docelowego (drate), sumę pakietów (pkts), sumę bajtów przepływów (bytes) oraz stany przepływów (state).

Widzimy, że racluster w porównaniu z ra nie wyświetla danych w jakiejś konkretnej kolejności. Jeśli chcemy je posortować w zależności od interesującego nas parametru, z pomocą przychodzi nam rasort.

Rasort

Jest to narzędzie sortujące wpisy na podstawie ustalonych kryteriów w wierszu poleceń.

rasort -r argus.flows -m bytes -s stime trans proto bytes sbytes dbytes pkts

Dane otrzymane przez racluster posortowaliśmy w zależności od sumy bajtów przepływów (-m bytes). Dodatkowo wyświetliliśmy informację na temat sumy bajtów wysłanych przez źródło (sbytes) oraz punkt docelowy (dbytes).

Tabelki to dobry sposób przedstawiania zebranych informacji, ale co zrobić, jeśli interesuje nas forma graficzna ułatwiająca późniejszą analizę?

Ragraph

Również i w tym przypadku dostajemy do ręki narzędzie ragraph pozwalające w prosty sposób przedstawić uzyskane przez nas dane w postaci wykresu.

ragraph pkts proto -M 1s -title 'Średnia liczba pakietów TCP przesłana w czasie 1s’ -vertical-label 'Liczba pakietów’ -r argus.flows – tcp

W tym przypadku mamy wykres słupkowy o rozdzielczości 1 sekundy (-M 1s) przedstawiający liczbę przesłanych pakietów TCP. Warto zauważyć, że mamy możliwość ustalenia własnego tytułu (-title) oraz etykiety osi OY.

ragraph spkts dpkts proto -M 1s -title 'Średnia liczba pakietów TCP przesłana w czasie 1s przez źródło i punkt docelowy’ -vertical-label 'Liczba pakietów (źródło [+] / punkt docelowy [-])’ -r argus-data -w argus-data-spkts-dpkts-tcp.png – tcp

Możemy również otrzymać zestawienie pakietów pochodzących ze źródła (spkts) oraz z punktu docelowego (dpkts) dla interesującego nas protokołu.

Wspomniana wcześniej częstotliwość (-M) może być dostosowywana do naszych potrzeb. Ragraph daje pełną dowolność co do jego wyboru. Może być to np. konkretna liczba sekund (s), minut (m), godzin (h), dni (d), miesięcy (M) lub lat (y).

ragraph pkts proto -M 1s -r argus.flows – icmp or udp

ragraph pkts proto -M 1m -r argus.flows – icmp or udp

ragraph pkts proto -M 10m -r argus.flows – icmp or udp

ragraph pkts proto -M 1h -r argus.flows – icmp or udp

 ragraph pkts proto -M 24h -r argus.flows – icmp or udp

By ułatwić sobie życie możemy zautomatyzować pracę argusa przy pomocy różnych skryptów oraz daemona cron. Przykładowo interesuje nas czy w naszej sieci nie ma jakiś podejrzanych hostów generujących duży ruch ICMP. Zamiast analizować dane ręcznie można ustawić by codziennie o 23:59 cały ruch z danego dnia był zapisywany w osobnym pliku oraz by z tych danych został wygenerowany wykres dla pięciu najaktywniejszych hostów. Co pozwoli nam szybko i łatwo okreslić czy coś jest nie tak.

argus -d -w /tmp/argus/argus.flows

59 23 * * * : ./argus-top5-hosts.sh

* Od redakcji – plik argus.flows może zawierać potencjalnie wrażliwe dane, więc rekomendujemy zapisywać go w miejscu, gdzie nie mają dostępu inni użytkownicy systemu operacyjnego.

A oto przykładowy skrypt:

Interesujące materiały

http://www.qosient.com/argus/index.shtml

http://nsmwiki.org/index.php?title=Argus

http://www.oucs.ox.ac.uk/network/security/documents/itss-argus.pdf

http://cert.org/flocon/2012/presentations/Argus.FloCon.2012.Tutorial.pdf

http://netsniff-ng.org/bpf.pdf

http://eecs.wsu.edu/~sshaikot/docs/lbpcap/libpcap-tutorial.pdf

http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf

http://www.ntop.org/pf_ring/port-mirror-vs-network-tap/

– Daniel Iziourov