Wykrywanie anomalii w sieci

Nie tylko flow

Czytając powyższe informacje, można zadać sobie pytanie. A co z rozpoznawaniem aplikacji? Mając do dyspozycji tylko i wyłącznie flows, nie jesteśmy w stanie wywnioskować, z jaką dokładnie aplikacją mamy do czynienia. Co więcej, nie jesteśmy w stanie sprawdzić, czy aplikacja ta zachowuje się niezgodnie ze swoim przeznaczeniem. Możemy co prawda zastosować bardzo proste techniki rozpoznawania, takie jak numer portu, czy też - opierając się na statystykach ruchu - stwierdzić, że mamy do czynienia np. z P2P czy tunelem VPN - ale o pełnej analizie nie ma mowy. Dlatego wielu producentów stara się dokładać kolejne moduły, pozwalające na pełną analizę każdego pakietu i rozpoznawanie aplikacji. Są one zbliżone w sposobie funkcjonowania do dobrze znanego Wiresharka. Dla przykładu, Cascade wykorzystuje do tego celu moduł Sensor, Peakflow X - moduł Application Intelligence. Lancope planuje wprowadzenie podobnej funkcjonalności wraz z wersją 5.10, która jeszcze w tym roku pojawi się na rynku.

Równie istotne co rozpoznawanie aplikacji (zwłaszcza z punktu wiedzenia bezpieczeństwa) jest powiązanie ruchu z konkretnym użytkownikiem. To - dzięki integracji z usługami katalogowymi - NBA również potrafią. Funkcjonalność taka jest najczęściej realizowana poprzez czytanie dziennika zdarzeń kontrolera domeny. Można do tego celu wykorzystać agenta instalowanego bezpośrednio na kontrolerze domeny lub posłużyć się systemem pośredniczącym. Aby ułatwić identyfikację użytkownika i powiązanie go z konkretną stacją, NBA mogą skorzystać z informacji dostępnych na serwerach DNS czy DHCP.

Wykrywanie anomalii w sieci

Juniper STRM – konsola zarządzania – poprzez przeglądarkę WWW

NBA potrafią też współpracować z innymi systemami. Przykładem może być integracja z rozwiązaniami badania podatności. Dzięki niej możemy - bez potrzeby zmiany konsoli - z poziomu NBA zalecić skan podejrzanej stacji. Niektóre rozwiązania pozwalają również na tworzenie zapytań, które odpytywałyby inne systemy o informacje związane z daną stacją, np. serwis WHOIS czy system inwentaryzacji zasobów.

Typowe rozwiązanie NBA składa się z kilku elementów: sensora/kolektora rekordów flow, modułu zajmującego się ruchem aplikacyjnym, modułu korelacyjnego (serca systemu) oraz konsoli zarządzania.

W zależności od wielkości środowiska może występować potrzeba zastosowania jednego lub wielu sensorów. Wszystko zależy od natłoku informacji. Jeden sensor flow - zależnie od producenta i sposobu mierzenia natężenia (niektórzy liczą w fps - flows per second , np. Lancope, Arbor; inni w fpm - flows per minute, np. Riverbed) - jest w stanie obsłużyć do kilkudziesięciu tysięcy rekordów flow na sekundę (np. 50 tys. Arbor Peakflow X Enterprise Wide Controller). Niektóre systemy NBA mają dedykowane rozwiązania służące do monitoringu środowiska maszyn wirtualnych, np. poprzez instalację odpowiedniego agenta na serwerze VMware. Jest to krok we właściwym kierunku - dla osób monitorujących stan sieci śledzenie częstych przenosin maszyn wirtualnych (np. dzięki technologii VMotion) jest sporą niedogodnością.

Wykrywanie anomalii w sieci

Uzyskanie informacji o ilości flowów na routerze Cisco

Rozwiązania NBA nie należą do tanich - cena za zestaw może wynieść od kilkuset do nawet kilku milionów złotych. Wszystko oczywiście zależy od wielkości środowiska, ilości zbieranych flowów. Każdy producent udostępnia własne narzędzia do przeprowadzenia odpowiednich wyliczeń, np. Lancope prowadzi blog NetFlowNinjas, gdzie znajdziemy opisy, jak wyliczyć odpowiednie wartości. Potrzebne informacje, które mogą pomóc we wstępnych szacunkach, można uzyskać także bezpośrednio na urządzeniach sieciowych, które mają wysyłać dane. Na przykład na sprzęcie Cisco możemy wydać komendę: sh ip cache verbose flow:

Pomimo wysokiej ceny, NBA uważane są za ten typ narzędzi, dla którego stosunkowo łatwo wyliczyć ROI. Dzięki ich zastosowaniu skraca się czas reakcji na zagrożenia, identyfikowanie wąskich gardeł oraz znajdowanie przyczyn problemów.


TOP 200