Jak wykorzystywać NetFlow w detekcji ataków DDoS

Skuteczna obrona przed cyberatakami jest obecnie jednym z większych wyzwań współczesnego świata IT. Sieci prywatne, jak i korporacyjne są często celami przeróżnych ataków hakerskich, w tym ataków DDoS, z powodu których straty sięgają nierzadko setek tysięcy a nawet milionów dolarów. Dlatego w EXATEL rozwijamy rozwiązania antyDDoS odpowiadające za ich detekcję i mitygację.

Piotr Grabarski. Inżynier R&D oraz backend developer w firmie EXATEL. Jego obszarami zainteresowań są sieci komputerowe oraz cyberbezpieczeństwo. Miłośnik Linuxa, automatyzacji procesów i oprogramowania charakteryzującego się minimalizmem. W wolnym czasie trenuje siatkówkę i gra na gitarze.

Czym jest atak DDoS?

Ataki Distributed Denial of Service polegają na przeciążeniu zasobów atakowanych urządzeń lub wykonaniu akcji uniemożliwiającej ofierze skorzystanie z pewnych usług. W odróżnieniu od ataków DoS, są one rozproszone – ich źródłem jest więcej niż jedno urządzenie. W dobie internetu, znacząco wzrosła liczba maszyn zombie i botnetów, co sprawiło, że ataki DDoS stały się o wiele tańsze i bardziej popularne.

Dlaczego NetFlow?

Aby przeciwdziałać atakom DDoS, firmy takie jak EXATEL rozwijają rozwiązania antyDDoS odpowiadające za ich detekcję oraz mitygację. Detekcja ma na celu możliwie szybkie zauważenie podejrzanego ruchu, rozpoznanie typu ataku i uruchomienie odpowiedniej mitygacji, czyli procesu filtracji ruchu niechcianego od ruchu właściwego. Tworzenie naszego rozwiązania zaczęliśmy od komponentu mitygującego. Operował on na pełnym ruchu, analizując każdy pakiet i w zależności od tego, czy dany pakiet wpisywał się w reguły filtrowania, odrzucał go lub przesyłał dalej.

Pojawił się wtedy pomysł, by do detekcji wykorzystać ten sam komponent, czyli najpierw wykonywać inspekcję pakietów w celu zbierania statystyk, a następnie zdecydować, czy kolejne pakiety powinny zostać poddane procesowi filtracji. Jednak zauważyliśmy, że takie podejście nie miałoby sensu, bo wprowadzało by opóźnienie dla obserwowanych pakietów, nawet gdy nie zawierałyby złośliwego ruchu. Wtedy zaczęliśmy szukać innego rozwiązania, które umożliwiłoby wydajny monitoring ogromnych sieci korporacyjnych. Tu z pomocą przyszły próbkowane statystyki NetFlow.

Czym jest protokół NetFlow?

NetFlow jest to protokół opracowywany przez firmę Cisco Systems. Występuje w kilku wersjach, a obecnie najczęściej wykorzystywany jest w wersji dziewiątej. NetFlow związany jest z urządzeniami IP i routerami Cisco, które od 1996 roku mają możliwość generowania statystyk z ruchu w postaci rekordów NetFlow. Statystyki te zawierają najważniejsze dane z ruchu, ale w zależności od ustawień routera są próbkowane (samplowane) z różną częstotliwością. Z doświadczenia wiem, że sampling występuje najczęściej w postaci 1:100 (dostajemy informację o jednym pakiecie na sto) lub 1:200, jednak widywałem również częstość próbkowania równą 1:10000. Okrojone dane pozwalają na szybszą i mniej wnikliwą analizę niż w przypadku pełnego ruchu, co jest niewątpliwą zaletą dla firm monitorujących ruch w dużych sieciach transportujących wrażliwe dane.

Odpowiedniki protokołu NetFlow

Sam mechanizm generowania statystyk w postaci NetFlow został opracowany przez Cisco, co oznacza, że nie każdy router będzie generował statystyki ‘out-of-the-box’. Używamy routerów Cisco, ale podobny mechanizm przyjęty został również przez większość innych producentów urządzeń sieciowych, jednak pod innymi nazwami np. Cflowd (Nokia), NetStream (Huawei), sFlow (alternatywa dla NetFlow dostępna u wielu producentów). W rozwiązaniu tworzonym przez nas w EXATEL użyliśmy najpopularniejszego z tych mechanizmów, czyli protokołu NetFlow w wersji 9.

Co się składa na protokół NetFlow?

• NetFlow templates – określają one to, jakie pola będą będą obecne w data recordach i jaki będą miały rozmiar. Jako, że pełnią one jedynie funkcję szablonów to nie ma potrzeby by routery wysyłały je tak często jak data recordy. Pozostają one ważne tak długo, aż zdekodowany zostanie kolejny template o takim samym ID i nadpisze poprzedni.
• NetFlow data records – zawierają wartości tych pól NetFlow, które zadeklarowane były w template’ach oraz informacje pozwalające na odnalezienie odpowiedniego NetFlow template i poprawne zdekodowanie danych.
• Option templates i option records – działają praktycznie tak samo jak NetFlow templates i NetFlow data records, z tą różnicą, że wysyłane są zdecydowanie rzadziej niż zwykłe rekordy i zawierają inne dane dotyczące m.in. routerów. Przykładem może być wspomniany wcześniej sampling.

Dekodowanie rekordów NetFlow

Źródło grafiki.

NetFlow jest protokołem stanowym i dynamicznym. Routery wysyłają najpierw template’y oraz option template’y. Dopiero na ich podstawie aplikacje dekodujące mogą poprawnie przetworzyć dane. Następnie trafiają one do komponentu nazywanego zwykle collectorem, który odpowiada za agregację otrzymanych danych i przekazanie ich do analizy. Sprawa bardziej się komplikuje, gdy mamy wiele routerów, z którego każdy ma kilka interfejsów i kilka różnych częstości próbkowania (samplingów).

Projektując nasze rozwiązanie antyDDoS, potrzebowaliśmy możliwie szybko dekodować i agregować zbierane pakiety NetFlow, więc szukaliśmy biblioteki napisanej w C lub C++. Nie udało nam się znaleźć niczego, co spełniałoby nasze wymagania. Zdecydowaliśmy się więc napisać własną bibliotekę do dekodowania NetFlow i uczyliśmy się tego formatu w praktyce.

Początkowo nie odczytywaliśmy option recordów, gdyż wysyłane są one bardzo rzadko i w testowych plikach pcap można było ich wcale nie doświadczyć. Następnie zauważyliśmy, że routery mogą mieć inny sampling w zależności od interfejsu, a nawet, że każdy z interfejsów może mieć więcej niż jeden sampler. Przykładowo, czasami wysyłać informację o jednym pakiecie na sto, a innym razem o jednym na tysiąc, co znacząco wpływało na detekcję wolumetryczną. Ostatecznie jednak bibliotekę udało się skończyć, wdrożyć, a nawet opublikować jako open source, co również było pewnego rodzaju ewenementem w firmie z bardzo restrykcyjną polityką bezpieczeństwa kodu. W EXATEL nikt tego przed nami nie zrobił.

Jakie przykładowe pola możemy odczytać z NetFlow w wersji 9?

Korzystając z NetFlow v9 możemy uzyskać informację o prawie 100 polach obecnych w NetFlow rekordach. Zależnie od potrzeby możemy konfigurować, które pola będą zrzucane przez nasze routery lub na poziomie naszej aplikacji dekodować jedynie te, które nas interesują. W detekcji wolumetrycznej najważniejsze są dla nas informacje o tym, jak duży ruch skierowany jest na dany adres IP na danym porcie.

W NetFlow byłyby to pola:

• IN_BYTES – liczba bajtów we flow,
• IN_PKTS – liczba pakietów we flow,
• IPV4_DST_ADDR/IPV6_DST_ADDR – adres docelowy IPv4 lub IPv6,
• L4_DST_PORT – docelowy port.

Jest to absolutne minimum pozwalające analitykowi na zauważenie ataku i uruchomienie mitygacji. Inne pola mogą okazać się przydatne, gdy zechcemy wiedzieć, z jakim atakiem mamy do czynienia (np. określenie protokołu czy flag tcp) lub kto jest atakującym (informacje o źródłowym IP, porcie lub porównywanie zebranych próbek ze znanymi botnetami).

IPFIX – rozszerzenie protokołu NetFlow 9

Ze względu na ograniczoną liczbę pól protokół NetFlow v9 doczekał się swojego następcy zwanego IPFIX (IP Flow Information eXport), który został opisany przez IETF. Protokół ten jest kompatybilny z NetFlow v9, posiada większą liczbę pól (ponad 400) oraz umożliwia wysyłanie flow zawierających pola o dynamicznych rozmiarach np. adresy URL.

IPFIX jest lepszym rozwiązaniem, gdy potrzebujemy agregować jakieś niestandardowe informacje. Z tego powodu Cisco opracowało własny mechanizm personalizacji formatu danych zwany Flexible NetFlow, który pozwala na konfigurację routerów w celu zrzucania dodatkowych pól. W pewnym momencie pojawiła się u nas potrzeba, by rozróżniać wchodzące i wychodzące VRF ID pakietów (ingress i egress VRF). Informacji o tym nie było w naszym flow, ale po korekcie w konfiguracji routerów, byliśmy w stanie obsługiwać dodatkowe pola bez większych zmian kodzie.

W naszej aplikacji protokół NetFlow 9 sprawdził się bardzo dobrze, ale możliwe, że protokoły opracowane przez inne firmy, również zdałyby tu egzamin. Co do samego mechanizmu, to myślę, że idea zrzucania próbkowanych statystyk ruchu z routerów nie powinna być pomijana podczas dyskusji o architekturze projektowanych systemów antyDDoS.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z