Gdy mowa o monitorowaniu bezpieczeństwa wewnętrznej sieci korporacyjnej lub rządowej, wielu osobom nasuwa się skojarzenie z kontrolą wycieków informacji i wdrażaniem rozwiązań DLP. A jeśli spróbujemy sprecyzować pytanie i zapytać, jak wykrywacie ataki w wewnętrznej sieci, to odpowiedzią zazwyczaj będzie wzmianka o systemach wykrywania włamań (intrusion detection systems, IDS). To, co było jedyną opcją jeszcze 10-20 lat temu, dzisiaj staje się anachronizmem. Istnieje bardziej efektywny, a miejscami jedyny możliwy sposób monitorowania wewnętrznej sieci — wykorzystanie protokołów flow, które pierwotnie były przeznaczone do diagnozowania problemów sieciowych (troubleshooting), ale z czasem przekształciły się w bardzo interesujące narzędzie bezpieczeństwa. O tym, jakie protokoły flow istnieją i które z nich najlepiej pomagają wykrywać ataki sieciowe, gdzie najlepiej wdrożyć monitoring flow, na co zwrócić uwagę przy rozwoju takiego schematu, a nawet jak to wszystko „uruchomić” na rodzimym sprzęcie, będziemy rozmawiać w niniejszym artykule.
Nie będę się zatrzymywał na pytaniu „Dlaczego monitoring bezpieczeństwa wewnętrznej infrastruktury jest potrzebny?” Odpowiedź na nie wydaje się być jasna. Ale jeśli wciąż chcesz się upewnić, że dzisiaj bez tego nigdzie się nie da, krótki filmik, w którym omówiono 17 sposobów na włamanie do korporacyjnej sieci chronionej zaporą sieciową. Dlatego uznajmy, że rozumiemy, iż wewnętrzny monitoring to rzecz potrzebna i pozostało tylko zrozumieć, jak go zorganizować.
Wyróżniłbym trzy kluczowe źródła danych do monitorowania infrastruktury na poziomie sieci:
- „surowy” ruch, który przechwytujemy i przesyłamy do analizy w systemach analitycznych,
- zdarzenia z urządzeń sieciowych, przez które przechodzi ruch,
- informacje o ruchu uzyskiwane za pomocą jednego z protokołów flow.
Przechwytywanie surowego ruchu to najpopularniejsza metoda wśród specjalistów ds. bezpieczeństwa, ponieważ historycznie to właśnie ona powstała jako pierwsza. Standardowe systemy wykrywania ataków (pierwszym komercyjnym systemem tego typu był NetRanger od firmy Wheel Group, nabyty przez Cisco w 1998 roku) zajmowały się właśnie przechwytywaniem pakietów (a później także sesji), w których poszukiwano określonych sygnatur („kluczowych reguł” w terminologii FSTEC), sygnalizujących o atakach. Oczywiście, surowy ruch można analizować nie tylko za pomocą IDS, ale również z wykorzystaniem innych narzędzi (np. Wireshark, tcpdump czy funkcjonalność NBAR2 w Cisco IOS), jednak zazwyczaj brakuje im bazy wiedzy, która odróżnia narzędzie bezpieczeństwa od zwykłego narzędzia IT.
Zatem, systemy wykrywania ataków. Najstarsza i najpopularniejsza metoda wykrywania ataków sieciowych, która całkiem dobrze radzi sobie ze swoimi zadaniami na obrzeżach (niezależnie od tego, czy są to firmy, centra danych, segmenty itp.), ale zawodzi w nowoczesnych sieciach przełączanych i definiowanych programowo. W przypadku sieci zbudowanej na podstawie standardowych przełączników infrastruktura sensorów wykrywania ataków staje się zbyt rozbudowana — trzeba zainstalować jeden sensor na każde połączenie z węzłem, którego ataki chcesz monitorować. Każdy producent oczywiście z chęcią sprzeda Ci setki czy tysiące sensorów, ale myślę, że Twój budżet nie wytrzyma takich wydatków. Mogę powiedzieć, że nawet w Cisco (a my jesteśmy twórcami NGIPS) nie udało nam się tego zrealizować, mimo że z pozoru nie powinno być to pytanie o cenę — to przecież nasze własne rozwiązanie. Ponadto, pojawia się pytanie, jak podłączyć sensor w takiej wersji? W przerwie? A co, jeśli sam sensor ulegnie awarii? Czy wymagać modułu bypass w sensorze? Używać rozgałęźników (tap)? To wszystko podnosi koszt rozwiązania i czyni je nieosiągalnym dla firmy każdej wielkości.
Można spróbować „zawiesić” czujnik na porcie SPAN/RSPAN/ERSPAN i kierować na niego ruch z potrzebnych portów przełącznika. Ta opcja częściowo rozwiązuje problem opisany w poprzednim akapicie, ale rodzi inny — port SPAN nie może przyjąć całego ruchu, który będzie na niego kierowany — brak mu wystarczającej przepustowości. Będzie trzeba z czegoś zrezygnować. Można pozostawić część węzłów bez monitorowania (wcześniej należy dokonać ich priorytetyzacji) lub kierować nie cały ruch z węzła, a tylko określonego typu. W każdym przypadku możemy przegapić niektóre ataki. Ponadto, port SPAN może być zajęty do innych celów. Ostatecznie będziemy musieli przeanalizować istniejącą topologię sieci i ewentualnie wprowadzić w niej poprawki, aby maksymalnie wykorzystać posiadane czujniki (i skoordynować to z IT).
A co jeśli wasza sieć używa asymetrycznych tras? A jeśli wprowadzono lub planowane jest wprowadzenie SDN? A co jeśli musicie monitorować zwirtualizowane maszyny lub kontenery, których ruch w ogóle nie dociera do fizycznego przełącznika? Na te pytania producenci tradycyjnych IDS nie lubią odpowiadać, bo nie wiedzą, jak to zrobić. Być może będą skłaniać was do przekonania, że te wszystkie nowoczesne technologie to tylko hype i nie są wam potrzebne. Może powiedzą o konieczności rozpoczęcia od małego. A może zasugerują, że powinniście zainstalować potężną maszynę w centrum sieci i kierować na nią cały ruch za pomocą load balancerów. Niezależnie od tego, jaką opcję wam zaproponują, musicie sami jasno zrozumieć, jak dobrze pasuje do waszych potrzeb. Dopiero potem podejmijcie decyzję o wyborze podejścia do monitorowania bezpieczeństwa infrastruktury sieciowej. Wracając do przechwytywania pakietów, chcę powiedzieć, że ta metoda nadal pozostaje bardzo popularna i ważna, ale jej głównym przeznaczeniem jest kontrola granic; granic między waszą organizacją a Internetem, granic między centrum danych a resztą sieci, granic między systemem zarządzania produkcją a segmentem korporacyjnym. W tych miejscach klasyczne IDS/IPS wciąż mają prawo do istnienia i porządnie radzą sobie z postawionymi zadaniami.
Przejdźmy do drugiej opcji. Analiza zdarzeń pochodzących z urządzeń sieciowych może być także wykorzystana do wykrywania ataków, ale nie jako główny mechanizm, gdyż pozwala ona na wykrycie tylko wąskiego zakresu intruzji. Dodatkowo, ma ona pewną reakcję – atak musi najpierw wystąpić, potem musi być zarejestrowany przez urządzenie sieciowe, które w pewien sposób zasygnalizuje problem z bezpieczeństwem informacyjnym. Jest kilka takich sposobów. Może to być syslog, RMON lub SNMP. Ostatnie dwa protokoły do monitorowania sieci w kontekście bezpieczeństwa informacyjnego są używane tylko wtedy, gdy konieczne jest wykrycie ataku DoS na same urządzenia sieciowe, ponieważ za pomocą RMON i SNMP można na przykład śledzić obciążenie procesora centralnego urządzenia lub jego interfejsów. To jeden z najtańszych sposobów (syslog lub SNMP ma każdy), ale również najmniej efektywny spośród wszystkich metod monitorowania bezpieczeństwa informacyjnego wewnętrznej infrastruktury – wiele ataków jest po prostu przed nim ukrytych. Oczywiście, nie należy ich lekceważyć, a analiza syslog pomaga w terminowym identyfikowaniu zmian w konfiguracji samego urządzenia, jego kompromitacji, ale do wykrywania ataków w całej sieci nie jest zbyt odpowiednia.
Trzecia opcja to analiza informacji o ruchu przechodzącym przez urządzenie wspierające jeden z kilku protokołów przepływu. W tym przypadku, niezależnie od protokołu, infrastruktura pracy z przepływami składa się zawsze z trzech komponentów:
- Generowanie lub eksport przepływu. Ta rola jest zazwyczaj powierzana routerowi, przełącznikowi lub innemu urządzeniu sieciowemu, które przepuszczając ruch sieciowy, pozwala wydobywać z niego kluczowe parametry, które następnie są przesyłane do modułu zbierania. Na przykład, w przypadku Cisco protokół Netflow wspierany jest nie tylko na routerach i przełącznikach, w tym także na wersjach wirtualnych i przemysłowych, ale również na kontrolerach bezprzewodowych, zaporach sieciowych a nawet serwerach.
- Zbieranie przepływów. Biorąc pod uwagę, że w nowoczesnej sieci zazwyczaj jest więcej niż jedno urządzenie sieciowe, pojawia się zadanie zbierania i konsolidacji przepływów, które rozwiązywane jest za pomocą tzw. kolektorów, które przeprowadzają przetwarzanie odebranych przepływów, a następnie przekazują je do analizy.
- Analiza przepływu. Analyzer przejmuje główne inteligentne zadanie i, stosując różne algorytmy do przepływów, wyciąga różne wnioski. Na przykład w ramach funkcji IT taki analizator może identyfikować wąskie gardła w sieci lub analizować profil obciążenia ruchu w celu dalszej optymalizacji sieci. A w kontekście bezpieczeństwa, taki analizator może wykrywać wycieki danych, rozprzestrzenianie złośliwego oprogramowania lub ataki DoS.
Nie należy myśleć, że taka trójwarstwowa architektura jest zbyt skomplikowana — wszystkie inne opcje (z wyjątkiem, być może, systemów monitorowania sieci działających na SNMP i RMON) również działają zgodnie z nią. Mamy generator danych do analizy, którym jest urządzenie sieciowe lub oddzielny czujnik. Mamy system zbierania sygnałów alarmowych i system zarządzania całą infrastrukturą monitorowania. Te dwa ostatnie komponenty mogą być połączone w ramach jednego węzła, ale w bardziej lub mniej dużych sieciach zazwyczaj są rozdzielone między co najmniej dwa urządzenia w celu zapewnienia skalowalności i niezawodności.
W przeciwieństwie do analizy pakietów, polegającej na badaniu nagłówków i ciała danych każdego pakietu oraz sesji je tworzących, analiza przepływów opiera się na zbieraniu metadanych o ruchu sieciowym. Kiedy, ile, skąd i dokąd, jak… oto pytania, na które odpowiada analiza telemetrii sieciowej za pomocą różnych protokołów przepływu. Początkowo były one wykorzystywane do analizy statystyk i wykrywania problemów IT w sieci, ale z biegiem rozwoju mechanizmów analitycznych, stało się możliwe ich zastosowanie do tej samej telemetrii i dla celów bezpieczeństwa. Warto jeszcze raz zaznaczyć, że analiza przepływów nie zastępuje i nie unieważnia przechwytywania pakietów. Każda z tych metod ma swoje miejsce zastosowania. Jednak w kontekście tego artykułu, to właśnie analiza przepływów najlepiej nadaje się do monitorowania wewnętrznej infrastruktury. Posiadasz urządzenia sieciowe (i nie ma znaczenia, czy działają w paradygmacie programowalnym, czy według statycznych reguł), które atak nie może ominąć. Czujnik klasycznej IDS można obejść, natomiast urządzenie sieciowe wspierające protokół przepływu już nie. To jest przewaga tej metody.
Z drugiej strony, jeśli potrzebujesz dowodów dla organów ścigania lub własnej grupy do zbadania incydentów, nie obejdziesz się bez przechwytywania pakietów – telemetria sieciowa nie jest odpowiednikiem ruchu, który można wykorzystać przy zbieraniu dowodów; potrzebna jest do szybkiego wykrywania i podejmowania decyzji w zakresie bezpieczeństwa informacji. Z drugiej strony, korzystając z analizy telemetrii, możesz „zapisywać” nie cały ruch sieciowy (jeśli coś, zajmuje się tym Cisco i centra danych :-), ale tylko ten, który bierze udział w ataku. Narzędzia do analizy telemetrii w tym zakresie dobrze uzupełnią tradycyjne mechanizmy przechwytywania pakietów, dając polecenie do selektywnego przechwytywania i przechowywania. W przeciwnym razie będziesz musiał zbudować kolosalną infrastrukturę do przechowywania.
Załóżmy sieć działającą z prędkością 250 Mb/s. Jeśli chcesz przechowywać cały ten ruch, będziesz potrzebował 31 MB pamięci na jedną sekundę przesyłania ruchu, 1,8 GB na jedną minutę, 108 GB na jedną godzinę i 2,6 TB na jeden dzień. Do przechowywania danych dziennych z sieci o przepustowości 10 Gb/s potrzebujesz pamięci o pojemności 108 TB. A niektórzy regulatorzy wymagają przechowywania danych w zakresie bezpieczeństwa przez lata… Nagrywanie „na żądanie”, które ułatwia realizację analizy strumieni, pozwala znacznie zmniejszyć te wartości. A propos, jeśli mówimy o stosunku objętości zapisywanych danych telemetrii sieciowej do pełnego przechwytywania danych, to wynosi on około 1 do 500. Dla tych samych podanych wcześniej wartości, przechowywanie pełnej dekodowanej dzienników całego ruchu dziennego wyniesie odpowiednio 5 i 216 GB (można to nawet zapisać na zwykłej pamięci flash).
Jeśli metody analizy surowych danych sieciowych prawie nie różnią się między dostawcami, to analiza przepływów wygląda inaczej. Istnieje kilka rodzajów protokołów flow, o różnicach, które należy znać w kontekście bezpieczeństwa. Najpopularniejszym z nich jest protokół Netflow, opracowany przez firmę Cisco. Istnieje kilka wersji tego protokołu, które różnią się swoimi możliwościami i zakresem informacyjnym o ruchu. Aktualna wersja — dziewiąta (Netflow v9), na podstawie której stworzono przemysłowy standard Netflow v10, znany również jako IPFIX. Dziś większość producentów sprzętu sieciowego wspiera właśnie Netflow lub IPFIX. Poza tym istnieją różne inne warianty protokołów flow — sFlow, jFlow, cFlow, rFlow, NetStream itp., z których sFlow jest najbardziej popularny. Jest on najczęściej wspierany przez krajowych producentów sprzętu sieciowego ze względu na prostotę realizacji. Jakie są kluczowe różnice między Netflow, który stał się de facto standardem, a sFlow? Kluczowych różnic jest kilka. Po pierwsze, Netflow ma pola konfigurowalne przez użytkownika w przeciwieństwie do stałych pól w sFlow. Po drugie, i to jest najważniejsze w naszym przypadku, sFlow zbiera tzw. telemetrię próbkowaną; w przeciwieństwie do telemetrii niepróbkowanej w Netflow i IPFIX. Jakie są więc różnice między nimi?
Wyobraź sobie, że postanowiłeś zapoznać się z książką “” moich kolegów — Gary'ego McIntyre'a, Josepha Muniza i Nadema Al-Fardana (pod tym linkiem możesz pobrać część książki). Masz trzy możliwości, aby osiągnąć swój cel — przeczytać książkę w całości, przebiec ją wzrokiem, zatrzymując się na każdej 10. lub 20. stronie, lub spróbować znaleźć streszczenie kluczowych koncepcji na jakimś blogu lub serwisie typu SmartReading. Tak więc telemetria niepróbkowana — to czytanie każdej „strony” ruchu sieciowego, czyli analiza metadanych każdego pakietu. Telemetria próbkowana — to wybiórcze badanie ruchu w nadziei, że w wybranych próbkach znajdzie się to, czego potrzebujesz. W zależności od prędkości kanału, telemetria próbkowana będzie wydawać do analizy każdy 64., 200., 500., 1000., 2000. lub nawet 10000. pakiet.
W kontekście monitorowania bezpieczeństwa oznacza to, że próbkowana telemetria dobrze nadaje się do wykrywania ataków DDoS, skanowania, rozpowszechniania złośliwego oprogramowania, ale może przeoczyć ataki atomowe lub wielopakietowe, które nie znalazły się w próbce wysłanej do analizy. Telemetria niesamplowana nie ma tych wad i z jej pomocą zakres wykrywanych ataków jest znacznie szerszy. Oto krótka lista zdarzeń, które można wykrywać za pomocą narzędzi analizy telemetrii sieciowej.
Oczywiście, żaden open source analizator Netflow nie pozwoli Ci na to, ponieważ jego głównym zadaniem jest zbieranie telemetrii i przeprowadzanie podstawowej analizy z perspektywy IT. Aby wykrywać zagrożenia w oparciu o flow, konieczne jest wyposażenie analizatora w różne silniki i algorytmy, które będą wykrywać problemy związane z cyberbezpieczeństwem w oparciu o standardowe lub niestandardowe pola Netflow, wzbogacając standardowe dane zewnętrznymi danymi z różnych źródeł Threat Intelligence itd.
Dlatego jeśli masz wybór, zatrzymaj się na Netflow lub IPFIX. Ale nawet jeśli twoje urządzenie obsługuje tylko sFlow, jak u krajowych producentów, to nawet w takim przypadku możesz w kontekście bezpieczeństwa wyciągnąć z niego korzyści.
Latem 2019 roku przeprowadziłem analizę możliwości, jakie mają rosyjscy producenci sprzętu sieciowego i wszyscy oni, z wyjątkiem NSG, Poligonu i Krafteya, twierdzili, że obsługują sFlow (przynajmniej Zelax, Natex, Eltex, QTech, Rusteletech).
Następne pytanie, które przed Tobą stanie, to gdzie wdrożyć wsparcie dla flow w celach bezpieczeństwa? W rzeczywistości, pytanie jest nieco niepoprawnie postawione. W nowoczesnym sprzęcie wsparcie dla protokołów flow jest praktycznie zawsze obecne. Dlatego sformułowałbym pytanie inaczej — gdzie najefektywniej gromadzić telemetrię z punktu widzenia bezpieczeństwa? Odpowiedź będzie dość oczywista — na poziomie dostępu, gdzie zobaczysz 100% całego ruchu, gdzie będziesz mieć szczegółowe informacje o hostach (MAC, VLAN, ID interfejsu), gdzie będziesz mógł śledzić nawet ruch P2P między hostami, co jest kluczowe dla wykrywania skanowania i rozprzestrzeniania złośliwego kodu. Na poziomie jądra niektóre dane ruchu możesz po prostu nie zobaczyć, a na poziomie perymetru zobaczysz dobrze, jeśli jedną czwartą całego ruchu sieciowego. Ale jeśli z jakiegoś powodu w Twojej sieci pojawiły się obce urządzenia, które pozwalają przestępcom „wchodzić i wychodzić”, pomijając perymetr, analiza telemetrii z nich nic Ci nie da. Dlatego dla maksymalnego zasięgu zaleca się włączenie zbierania telemetrii właśnie na poziomie dostępu. Warto przy tym zauważyć, że nawet jeśli mówimy o wirtualizacji lub kontenerach, to w nowoczesnych wirtualnych przełącznikach również często występuje wsparcie dla flow, co pozwala na kontrolowanie ruchu również tam.
Ale skoro poruszyłem ten temat, to muszę odpowiedzieć na pytanie, co jeśli jednak sprzęt, fizyczny lub wirtualny, nie wspiera protokołów flow? Lub jego włączenie jest zabronione (na przykład w segmentach przemysłowych dla zapewnienia niezawodności)? Lub jego włączenie prowadzi do wysokiego obciążenia procesora (tak zdarza się w przypadku starszego sprzętu)? Do rozwiązania tego problemu istnieją specjalistyczne wirtualne sensory (flow sensor), które w zasadzie są zwykłymi rozgałęźnikami, przepuszczającymi przez siebie ruch i retransmitującymi go w postaci flow do modułu zbierania. Prawda, w tym przypadku napotykamy cały szereg problemów, o których rozmawialiśmy wcześniej w odniesieniu do środków przechwytywania pakietów. To znaczy trzeba zrozumieć nie tylko zalety technologii analizy ruchu, ale także jej ograniczenia.
Kolejny aspekt, o którym warto pamiętać, mówiąc o narzędziach analizy przepływów. Jeśli dla typowych narzędzi generowania zdarzeń bezpieczeństwa stosujemy metrykę EPS (event per second, zdarzenia na sekundę), to w analizie telemetrii ten wskaźnik nie ma zastosowania; zostaje zastąpiony metryką FPS (flow per second, przepływ na sekundę). Podobnie jak w przypadku EPS, nie można go obliczyć z góry, ale można oszacować przybliżoną liczbę przepływów generowanych przez dane urządzenie w zależności od jego zadania. W Internecie można znaleźć tabele z przybliżonymi wartościami dla różnych typów urządzeń korporacyjnych oraz warunków, co pozwoli ci oszacować, jakie licencje są potrzebne do narzędzi analitycznych i jaka będzie ich architektura. Faktem jest, że czujnik IDS ma określoną przepustowość, którą jest w stanie „pociągnąć”, a także kolektor przepływów ma swoje ograniczenia, które należy zrozumieć. Dlatego w dużych, terytorialnie rozproszonych sieciach zwykle jest kilka kolektorów. Kiedy opisywałem, , już wspomniałem o liczbie naszych kolektorów — jest ich 21. A to w sieci rozciągającej się na pięciu kontynentach i liczącej około pół miliona aktywnych urządzeń).
Jako system monitorowania Netflow wykorzystujemy nasze własne rozwiązanie , które jest specjalnie zaprojektowane do rozwiązywania problemów związanych z bezpieczeństwem. Posiada wiele wbudowanych silników do wykrywania anomalii, podejrzanej i wyraźnie złośliwej aktywności, co pozwala na detekcję szerokiego zakresu różnych zagrożeń — od kopania kryptowalut po wycieki informacji, od rozprzestrzeniania złośliwego oprogramowania po oszustwa. Podobnie jak większość analityków ruchu, Stealthwatch oparty jest na schemacie trzystopniowym (generator — kolektor — analityk), ale został wzbogacony o szereg interesujących funkcji, które są istotne w kontekście omawianego materiału. Po pierwsze, integruje się z rozwiązaniami do przechwytywania pakietów (np. Cisco Security Packet Analyzer), co pozwala na nagrywanie wybranych sesji sieciowych do dalszego szczegółowego śledzenia i analizy. Po drugie, specjalnie w celu rozszerzenia zadań bezpieczeństwa, opracowaliśmy protokół nvzFlow, który pozwala na “transmisję” aktywności aplikacji na końcowych węzłach (serwerach, stacjach roboczych itp.) do telemetrii i przesyłanie jej do kolektora w celu dalszej analizy. Jeśli w swojej pierwotnej wersji Stealthwatch działa z dowolnym protokołem flow (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na poziomie sieci, to wsparcie nvzFlow pozwala na korelację danych także na poziomie węzła, tym samym zwiększając efektywność całego systemu i pozwalając na zobaczenie większej liczby ataków, niż zwykłe sieciowe analizy ruchu.
Jasne jest, że mówiąc o systemach analizy Netflow z perspektywy bezpieczeństwa, rynek nie ogranicza się do jednego rozwiązania od Cisco. Można korzystać zarówno z rozwiązań komercyjnych, jak i darmowych lub połowicznie darmowych. Dość dziwnie byłoby, gdybym na blogu Cisco przytaczał przykłady rozwiązań konkurencji, dlatego powiem kilka słów o tym, jak telemetria sieciowa może być analizowana za pomocą dwóch popularnych, podobnie nazwanych, ale mimo to różnych narzędzi — SiLK i ELK.
SiLK to zestaw narzędzi (System for Internet-Level Knowledge) do analizy ruchu, stworzony przez amerykański CERT/CC, który wspiera w kontekście dzisiejszego artykułu Netflow (5. i 9. najpopularniejsze wersje), IPFIX oraz sFlow. Dzięki różnym narzędziom (rwfilter, rwcount, rwflowpack i innym) pozwala na przeprowadzanie różnych operacji na telemetrii sieciowej w celu wykrywania oznak nieautoryzowanych działań. Należy jednak wskazać kilka ważnych punktów. SiLK jest narzędziem działającym w trybie wiersza poleceń i do przeprowadzania analizy operacyjnej, wymaga ciągłego wprowadzania poleceń, takich jak (wykrywanie pakietów ICMP większych niż 200 bajtów):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
to nie jest zbyt wygodne. Możesz używać graficznego interfejsu iSiLK, ale nie ułatwi on znacząco życia, pełniąc jedynie funkcję wizualizacji, a nie zastępowania analityka. I to jest druga kwestia. W przeciwieństwie do rozwiązań komercyjnych, które mają już wbudowaną solidną bazę analityczną, algorytmy wykrywania anomalii, odpowiednie workflow itp., w przypadku SiLK musisz to przeprowadzić samodzielnie, co wymaga od Ciebie innych kompetencji, niż przy użyciu gotowych narzędzi. To ani dobre, ani złe — to cecha prawie każdego darmowego narzędzia, które zakłada, że wiesz, co robić, a ono po prostu Ci w tym pomoże (narzędzia komercyjne mniej zależą od kompetencji ich użytkowników, chociaż również zakładają, że analitycy rozumieją przynajmniej podstawy przeprowadzania dochodzeń sieciowych i monitorowania). Wracając do SiLK. Cykl pracy analityka z nim wygląda następująco:
- Formułowanie hipotezy. Musimy rozumieć, czego będziemy szukać w telemetrii sieciowej, znać unikalne atrybuty, na podstawie których zidentyfikujemy różne anomalia lub zagrożenia.
- Budowanie modelu. Po sformułowaniu hipotezy programujemy ją przy użyciu tego samego Pythona, shella lub innych narzędzi, które nie wchodzą w skład SiLK.
- Testowanie. Nadeszła pora na sprawdzenie zasadności naszej hipotezy, która zostaje potwierdzona lub obalona przy pomocy narzędzi SiLK, zaczynających się od 'rw', 'set', 'bag'.
- Analiza rzeczywistych danych. W użytkowaniu przemysłowym SiLK pomaga nam identyfikować różne zjawiska, a analityk musi odpowiedzieć na pytania: „Czy znaleźliśmy to, co zakładaliśmy?”, „Czy to odpowiada naszej hipotezie?”, „Jak zmniejszyć liczbę fałszywych alarmów?”, „Jak poprawić poziom rozpoznawania?” itp.
- Udoskonalenie. Na końcowym etapie poprawiamy to, co zostało wcześniej wykonane — tworzymy szablony, optymalizujemy kod, reformułujemy i precyzujemy hipotezy itd.
Ten cykl będzie stosowany także w Cisco Stealthwatch, który automatyzuje te pięć kroków w jak największym stopniu, zmniejszając liczbę błędów analityka i zwiększając szybkość wykrywania incydentów. Na przykład w SiLK statystyki sieci można wzbogacić o zewnętrzne dane dotyczące złośliwych adresów IP przy użyciu własnoręcznie napisanych skryptów, podczas gdy w Cisco Stealthwatch jest to wbudowana funkcja, która natychmiast zgłasza alarm, jeśli w ruchu sieciowym występuje interakcja z adresami IP z czarnej listy.
Jeśli spojrzeć wyżej w hierarchii płatnych rozwiązań do analizy flow, to za całkowicie darmowym SiLK stoi warunkowo darmowy ELK, składający się z trzech kluczowych komponentów — Elasticsearch (indeksowanie, wyszukiwanie i analiza danych), Logstash (wejście/wyjście danych) i Kibana (wizualizacja). W przeciwieństwie do SiLK, gdzie wszystko trzeba pisać samodzielnie, ELK ma już wiele gotowych bibliotek/modułów (część płatnych, część darmowych), które automatyzują analizę telemetrii sieciowej. Na przykład filtr GeoIP w Logstash pozwala powiązać obserwowane adresy IP z ich lokalizacją geograficzną (w Stealthwatch jest to wbudowana funkcja).
ELK ma także spore społeczność, która dopisuje brakujące komponenty do tego rozwiązania monitorującego. Na przykład, aby pracować z Netflow, IPFIX i sFlow, można skorzystać z modułu , jeśli nie odpowiada ci Logstash Netflow Module, który obsługuje tylko Netflow.
Dając więcej szybkości w zbieraniu flow i jego przeszukiwaniu, ELK obecnie nie ma bogatej wbudowanej analityki wykrywania anomalii i zagrożeń w telemetrii sieciowej. To znaczy, stosując opisany wcześniej cykl życia, będziesz musiał samodzielnie opracować modele naruszeń, a następnie używać ich w systemie operacyjnym (brak wbudowanych modeli).
Z pewnością istnieją bardziej zaawansowane rozszerzenia do ELK, które już zawierają niektóre modele wykrywania anomalii w telemetrii sieciowej, ale takie rozszerzenia są płatne i pojawia się pytanie, czy warto inwestować — napisanie podobnego modelu samodzielnie, zakup gotowej implementacji dla swojego narzędzia monitorującego, czy kupno gotowego rozwiązania klasy Network Traffic Analysis.
W ogóle nie chcę wdawać się w polemikę, czy lepiej wydać pieniądze i kupić gotowe rozwiązanie do monitorowania anomalii i zagrożeń w telemetrii sieciowej (na przykład Cisco Stealthwatch), czy zająć się tym samodzielnie, modyfikując np. SiLK, ELK, nfdump lub OSU Flow Tools (mam na myśli ostatnie dwa z nich). w zeszłym razem)? Każdy wybiera dla siebie i każdy ma swoje motywy, aby wybrać jedną z dwóch opcji. Chciałem tylko pokazać, że telemetria sieciowa to bardzo ważne narzędzie w zapewnieniu bezpieczeństwa sieci dla swojej wewnętrznej infrastruktury i nie można jej bagatelizować, aby nie dołączyć do listy firm, których nazwa pojawia się w mediach z przymiotnikami takimi jak „zhakowana”, „nieprzestrzegająca wymogów bezpieczeństwa” czy „niezajmująca się bezpieczeństwem swoich danych i danych klientów.”
Podsumowując, chciałbym wymienić kluczowe porady, które warto stosować przy budowaniu monitorowania bezpieczeństwa informacji swojej wewnętrznej infrastruktury:
- Nie ograniczaj się tylko do perymetru! Używaj (i wybieraj) infrastruktury sieciowej nie tylko do przesyłania ruchu z punktu A do punktu B, ale także do rozwiązywania kwestii cyberbezpieczeństwa.
- Zbadaj istniejące mechanizmy monitorowania bezpieczeństwa informacji w swoim sprzęcie sieciowym i wykorzystaj je.
- Do wewnętrznego monitorowania preferuj analizę telemetrii — pozwala ona na wykrycie 80-90% wszystkich incydentów sieciowych w zakresie bezpieczeństwa, jednocześnie wykonując to, co jest niemożliwe przy przechwytywaniu pakietów sieciowych i oszczędzając miejsce potrzebne do przechowywania wszystkich zdarzeń związanych z bezpieczeństwem informacji.
- Do monitorowania strumieni używaj Netflow v9 lub IPFIX – dostarczają one więcej informacji w kontekście bezpieczeństwa i pozwalają monitorować nie tylko IPv4, ale także IPv6, MPLS itp.
- Używaj niesamplingowego protokołu flow – daje on więcej informacji do wykrywania zagrożeń. Na przykład, Netflow lub IPFIX.
- Sprawdź obciążenie swojego sprzętu sieciowego – być może nie poradzi sobie z przetwarzaniem także protokołu flow. Wówczas rozważ zastosowanie wirtualnych czujników lub urządzenia do generacji Netflow.
- Wprowadź kontrolę przede wszystkim na poziomie dostępu – to pozwoli ci zobaczyć 100% całego ruchu.
- Jeśli masz ograniczony wybór i korzystasz z rosyjskiego sprzętu sieciowego, wybierz taki, który obsługuje protokoły flow lub ma porty SPAN/RSPAN.
- Kombinuj systemy wykrywania/zapobiegania włamaniom/atakom na granicach oraz systemy analizy ruchu w wewnętrznej sieci (w tym w chmurach).
Co do ostatniej rady, chciałbym przytoczyć ilustrację, którą już wcześniej prezentowałem. Widzisz, że jeśli wcześniej służba bezpieczeństwa Cisco niemal w całości opierała swój system monitorowania bezpieczeństwa na systemach wykrywania włamań i metodach sygnaturowych, to teraz na ich udział przypada zaledwie 20% incydentów. Kolejne 20% przypadków dotyczy systemów analizy ruchu, co świadczy o tym, że te rozwiązania to nie fanaberia, a realne narzędzie w działaniach służb bezpieczeństwa nowoczesnego przedsiębiorstwa. Tym bardziej, że dla ich wdrożenia masz to, co najważniejsze – infrastrukturę sieciową, której inwestycje można dodatkowo zabezpieczyć, powierzając sieci także funkcje monitorowania bezpieczeństwa.
Specjalnie nie poruszałem tematu reagowania na wykryte w sieci anomalie lub zagrożenia, ale myślę, że i tak wiadomo, że monitorowanie nie powinno kończyć się tylko na wykryciu zagrożenia. Powinno za tym podążać reagowanie, a najlepiej w trybie automatycznym lub zautomatyzowanym. Ale to już temat na osobny materiał.
Dodatkowe informacje:
P.S. Jeśli łatwiej ci przyswajać słuchowo wszystko, co zostało napisane powyżej, możesz obejrzeć godzinną prezentację, która stanowiła podstawę tej notatki.
Źródło: habr.com
