Jeśli chodzi o monitorowanie bezpieczeństwa wewnętrznej sieci korporacyjnej lub wydziałowej, wielu kojarzy je z kontrolą wycieków informacji i wdrażaniem rozwiązań DLP. A jeśli spróbujesz doprecyzować pytanie i zapytasz, w jaki sposób wykrywasz ataki na sieć wewnętrzną, odpowiedzią będzie z reguły wzmianka o systemach wykrywania włamań (IDS). A to, co było jedyną opcją 10-20 lat temu, dziś staje się anachronizmem. Istnieje skuteczniejsza, a w niektórych miejscach jedyna możliwa opcja monitorowania sieci wewnętrznej - przy użyciu protokołów przepływu, które pierwotnie miały służyć wyszukiwaniu problemów w sieci (rozwiązywaniu problemów), ale z czasem przekształciły się w bardzo ciekawe narzędzie bezpieczeństwa. Porozmawiamy o tym, jakie istnieją protokoły przepływu i które lepiej wykrywają ataki sieciowe, gdzie najlepiej wdrożyć monitorowanie przepływu, na co zwrócić uwagę przy wdrażaniu takiego schematu, a nawet jak „podnieść” to wszystko na sprzęt domowy w zakresie tego artykułu.
Nie będę się rozwodzić nad pytaniem „Po co potrzebny jest monitoring bezpieczeństwa infrastruktury wewnętrznej?” Odpowiedź wydaje się jasna. Ale jeśli mimo to chciałbyś się jeszcze raz upewnić, że dziś nie możesz bez tego żyć, krótki film o tym, jak na 17 sposobów można przedostać się do sieci korporacyjnej chronionej zaporą ogniową. Dlatego założymy, że rozumiemy, że monitoring wewnętrzny jest rzeczą niezbędną i pozostaje tylko zrozumieć, jak można go zorganizować.
Chciałbym wyróżnić trzy kluczowe źródła danych do monitorowania infrastruktury na poziomie sieci:
- „surowy” ruch, który przechwytujemy i poddajemy do analizy określonym systemom analitycznym,
- zdarzenia z urządzeń sieciowych, przez które przechodzi ruch,
- informacje o ruchu otrzymane za pośrednictwem jednego z protokołów przepływu.
Przechwytywanie surowego ruchu jest najpopularniejszą opcją wśród specjalistów ds. bezpieczeństwa, ponieważ pojawiła się historycznie i była pierwszą. Konwencjonalne systemy wykrywania włamań do sieci (pierwszym komercyjnym systemem wykrywania włamań był NetRanger firmy Wheel Group, zakupiony w 1998 roku przez Cisco) precyzyjnie przechwytywały pakiety (i późniejsze sesje), w których szukano określonych sygnatur („decydujące reguły” w terminologia FSTEC), ataki sygnalizacyjne. Oczywiście surowy ruch można analizować nie tylko za pomocą IDS, ale także za pomocą innych narzędzi (na przykład Wireshark, tcpdum czy funkcjonalność NBAR2 w Cisco IOS), jednak zazwyczaj brakuje im bazy wiedzy, która odróżnia narzędzie bezpieczeństwa informacji od zwykłego Narzędzie informatyczne.
A więc systemy wykrywania ataków. Najstarsza i najpopularniejsza metoda wykrywania ataków sieciowych, która dobrze radzi sobie na obrzeżach (nieważne, co - korporacyjne, centrum danych, segment itp.), ale zawodzi w nowoczesnych sieciach przełączanych i definiowanych programowo. W przypadku sieci zbudowanej w oparciu o konwencjonalne przełączniki infrastruktura czujników wykrywania ataków staje się zbyt duża – konieczne będzie zainstalowanie czujnika na każdym połączeniu z węzłem, na którym chcesz monitorować ataki. Każdy producent oczywiście chętnie sprzeda Ci setki i tysiące czujników, ale myślę, że Twój budżet nie jest w stanie udźwignąć takich wydatków. Mogę powiedzieć, że nawet w Cisco (a jesteśmy twórcami NGIPS) nie mogliśmy tego zrobić, choć wydawałoby się, że kwestia ceny jest przed nami. Nie powinnam stać – to nasza własna decyzja. Dodatkowo pojawia się pytanie jak podłączyć czujnik w tej wersji? W szczelinę? Co się stanie, jeśli sam czujnik ulegnie awarii? Potrzebujesz modułu obejściowego w czujniku? Używać rozdzielaczy (dotknij)? Wszystko to sprawia, że rozwiązanie jest droższe i niedostępne dla firmy dowolnej wielkości.
Można spróbować „zawiesić” czujnik na porcie SPAN/RSPAN/ERSPAN i skierować na niego ruch z wymaganych portów przełącznika. Ta opcja częściowo usuwa problem opisany w poprzednim akapicie, ale stwarza kolejny - port SPAN nie może przyjąć absolutnie całego ruchu, który będzie do niego wysyłany - nie będzie miał wystarczającej przepustowości. Będziesz musiał coś poświęcić. Albo pozostaw część węzłów bez monitorowania (wtedy musisz najpierw ustalić dla nich priorytety), albo wysyłaj nie cały ruch z węzła, a tylko określony typ. Tak czy inaczej, możemy przegapić niektóre ataki. Dodatkowo port SPAN można wykorzystać do innych celów. W rezultacie będziemy musieli dokonać przeglądu istniejącej topologii sieci i ewentualnie wprowadzić w niej zmiany, aby maksymalnie pokryć Twoją sieć liczbą posiadanych czujników (i skoordynować to z IT).
Co się stanie, jeśli Twoja sieć korzysta z tras asymetrycznych? A co jeśli wdrożyłeś lub planujesz wdrożyć SDN? A co jeśli potrzebujesz monitorować zwirtualizowane maszyny lub kontenery, których ruch w ogóle nie dociera do fizycznego przełącznika? Są to pytania, których tradycyjni dostawcy IDS nie lubią, ponieważ nie wiedzą, jak na nie odpowiedzieć. Być może przekonają Cię, że wszystkie te modne technologie to tylko szum i nie są Ci one potrzebne. Być może będą rozmawiać o potrzebie rozpoczęcia od małych rzeczy. A może powiedzą, że trzeba postawić potężną młocarnię w centrum sieci i skierować na nią cały ruch za pomocą balanserów. Niezależnie od oferowanej Ci opcji, musisz jasno zrozumieć, jak Ci odpowiada. Dopiero potem podejmij decyzję o wyborze podejścia do monitorowania bezpieczeństwa informacji infrastruktury sieciowej. Wracając do przechwytywania pakietów, chcę powiedzieć, że metoda ta jest nadal bardzo popularna i ważna, ale jej głównym celem jest kontrola graniczna; granice między Twoją organizacją a Internetem, granice między centrum danych a resztą sieci, granice między systemem kontroli procesów a segmentem korporacyjnym. W tych miejscach klasyczne IDS/IPS nadal mają prawo istnieć i dobrze radzą sobie ze swoimi zadaniami.
Przejdźmy do drugiej opcji. Analiza zdarzeń pochodzących z urządzeń sieciowych może być również wykorzystywana do celów wykrywania ataków, ale nie jako główny mechanizm, gdyż pozwala na wykrycie jedynie niewielkiej klasy włamań. Poza tym wiąże się to z pewną reaktywnością – najpierw musi nastąpić atak, następnie musi zostać zarejestrowany przez urządzenie sieciowe, co w ten czy inny sposób zasygnalizuje problem z bezpieczeństwem informacji. Jest kilka takich sposobów. Może to być syslog, RMON lub SNMP. Dwa ostatnie protokoły monitorowania sieci w kontekście bezpieczeństwa informacji stosujemy tylko wtedy, gdy potrzebujemy wykryć atak DoS na sam sprzęt sieciowy, gdyż za pomocą RMON i SNMP można np. monitorować obciążenie centrali urządzenia procesor lub jego interfejsy. Jest to jedna z „najtańszych” (każdy ma syslog lub SNMP), ale także najbardziej nieskuteczna ze wszystkich metod monitorowania bezpieczeństwa informacji infrastruktury wewnętrznej - wiele ataków jest po prostu przed nią ukrywanych. Oczywiście nie należy ich lekceważyć, a ta sama analiza syslog pomaga w odpowiednim czasie zidentyfikować zmiany w konfiguracji samego urządzenia, jego kompromisy, ale nie jest zbyt odpowiednia do wykrywania ataków na całą sieć.
Trzecią opcją jest analiza informacji o ruchu przechodzącym przez urządzenie obsługujące jeden z kilku protokołów przepływu. W tym przypadku, niezależnie od protokołu, infrastruktura wątków koniecznie składa się z trzech komponentów:
- Generowanie lub eksport przepływu. Rolę tę przypisuje się zazwyczaj routerowi, przełącznikowi lub innemu urządzeniu sieciowemu, które przepuszczając przez siebie ruch sieciowy, pozwala wydobyć z niego kluczowe parametry, które następnie przekazywane są do modułu zbierającego. Przykładowo Cisco obsługuje protokół Netflow nie tylko na routerach i przełącznikach, w tym wirtualnych i przemysłowych, ale także na kontrolerach bezprzewodowych, zaporach ogniowych, a nawet serwerach.
- Przepływ kolekcji. Biorąc pod uwagę, że współczesna sieć ma zwykle więcej niż jedno urządzenie sieciowe, pojawia się problem gromadzenia i konsolidacji przepływów, który rozwiązuje się za pomocą tzw. kolektorów, które przetwarzają odebrane przepływy, a następnie przesyłają je do analizy.
- Analiza przepływu Analizator bierze na siebie główne zadanie intelektualne i stosując do strumieni różne algorytmy, wyciąga określone wnioski. Na przykład, w ramach funkcji IT, taki analizator może identyfikować wąskie gardła w sieci lub analizować profil obciążenia ruchem w celu dalszej optymalizacji sieci. A dla bezpieczeństwa informacji taki analizator może wykryć wycieki danych, rozprzestrzenianie się złośliwego kodu lub ataki DoS.
Nie myśl, że ta trójpoziomowa architektura jest zbyt skomplikowana - wszystkie inne opcje (być może z wyjątkiem systemów monitorowania sieci współpracujących z SNMP i RMON) również działają zgodnie z nią. Dysponujemy generatorem danych do analizy, który może być urządzeniem sieciowym lub samodzielnym czujnikiem. Posiadamy system zbierania alarmów oraz system zarządzania całą infrastrukturą monitoringu. Dwa ostatnie komponenty można połączyć w ramach jednego węzła, jednak w mniej lub bardziej dużych sieciach są one zazwyczaj rozłożone na co najmniej dwa urządzenia, aby zapewnić skalowalność i niezawodność.
W przeciwieństwie do analizy pakietów, która opiera się na badaniu danych nagłówka i treści każdego pakietu oraz sesji, z których się składa, analiza przepływu polega na gromadzeniu metadanych o ruchu sieciowym. Kiedy, ile, skąd i gdzie, jak… na te pytania odpowiada analiza telemetrii sieci z wykorzystaniem różnych protokołów przepływu. Początkowo służyły do analizy statystyk i wyszukiwania problemów informatycznych w sieci, jednak wraz z rozwojem mechanizmów analitycznych pojawiła się możliwość zastosowania ich do samej telemetrii ze względów bezpieczeństwa. Warto jeszcze raz zauważyć, że analiza przepływu nie zastępuje ani nie zastępuje przechwytywania pakietów. Każda z tych metod ma swój własny obszar zastosowania. Jednak w kontekście tego artykułu do monitorowania infrastruktury wewnętrznej najlepiej nadaje się analiza przepływów. Masz urządzenia sieciowe (niezależnie od tego, czy działają w oparciu o paradygmat zdefiniowany programowo, czy zgodnie z regułami statycznymi), których atak nie może ominąć. Potrafi ominąć klasyczny czujnik IDS, ale urządzenie sieciowe obsługujące protokół przepływu nie. To jest zaleta tej metody.
Z drugiej strony, jeśli potrzebujesz dowodów dla organów ścigania lub własnego zespołu dochodzeniowego, nie możesz obejść się bez przechwytywania pakietów - telemetria sieciowa nie jest kopią ruchu, którą można wykorzystać do gromadzenia dowodów; jest to potrzebne do szybkiego wykrywania i podejmowania decyzji w dziedzinie bezpieczeństwa informacji. Z drugiej strony, korzystając z analizy telemetrycznej, można „zapisać” nie cały ruch sieciowy (jeśli w ogóle Cisco ma do czynienia z centrami danych :-), ale tylko ten, który bierze udział w ataku. Narzędzia do analizy telemetrycznej w tym zakresie będą dobrze uzupełniać tradycyjne mechanizmy przechwytywania pakietów, dając polecenia do selektywnego przechwytywania i przechowywania. W przeciwnym razie będziesz musiał dysponować kolosalną infrastrukturą pamięci masowej.
Wyobraźmy sobie sieć działającą z szybkością 250 Mbit/s. Jeśli chcesz przechowywać cały ten wolumen, będziesz potrzebować 31 MB pamięci na jedną sekundę transmisji ruchu, 1,8 GB na jedną minutę, 108 GB na godzinę i 2,6 TB na jeden dzień. Do codziennego przechowywania danych z sieci o przepustowości 10 Gbit/s potrzebne będzie 108 TB pamięci masowej. Ale niektóre organy regulacyjne wymagają przechowywania danych dotyczących bezpieczeństwa przez lata... Nagrywanie na żądanie, którego wdrożenie pomaga analiza przepływu, pomaga zmniejszyć te wartości o rzędy wielkości. Nawiasem mówiąc, jeśli mówimy o stosunku objętości zarejestrowanych danych telemetrycznych sieci do całkowitego przechwycenia danych, to wynosi on około 1 do 500. Dla tych samych wartości podanych powyżej, przechowywanie pełnego transkrypcji całego dziennego ruchu wyniesie odpowiednio 5 i 216 GB (można go nawet nagrać na zwykłym pendrive'ie).
Jeśli w przypadku narzędzi do analizy surowych danych sieciowych sposób ich przechwytywania jest prawie taki sam w zależności od dostawcy, to w przypadku analizy przepływów sytuacja jest inna. Istnieje kilka opcji protokołów przepływu, różnice, o których musisz wiedzieć w kontekście bezpieczeństwa. Najpopularniejszym jest protokół Netflow opracowany przez firmę Cisco. Istnieje kilka wersji tego protokołu, różniących się możliwościami i ilością rejestrowanych informacji o ruchu drogowym. Obecna wersja jest dziewiątą (Netflow v9), na bazie której opracowano branżowy standard Netflow v10, znany również jako IPFIX. Obecnie większość dostawców sieci obsługuje w swoich urządzeniach Netflow lub IPFIX. Istnieje jednak wiele innych opcji protokołów przepływu - sFlow, jFlow, cFlow, rFlow, NetStream itp., z których sFlow jest najpopularniejszy. To właśnie ten typ jest najczęściej wspierany przez krajowych producentów sprzętu sieciowego ze względu na łatwość wdrożenia. Jakie są kluczowe różnice pomiędzy Netflow, który stał się de facto standardem, a sFlow? Chciałbym wyróżnić kilka kluczowych. Po pierwsze, Netflow ma pola, które użytkownik może dostosowywać, w przeciwieństwie do stałych pól w sFlow. A po drugie, a to w naszym przypadku najważniejsze, sFlow zbiera tzw. próbkowaną telemetrię; w przeciwieństwie do niepróbkowanego dla Netflow i IPFIX. Jaka jest różnica między nimi?
Wyobraź sobie, że decydujesz się przeczytać książkę „” moich kolegów – Gary’ego McIntyre’a, Josepha Munitza i Nadema Alfardana (część książki można pobrać pod linkiem). Masz trzy możliwości osiągnięcia swojego celu — przeczytaj całą książkę, przejrzyj ją, zatrzymując się na co 10. lub 20. stronie, lub spróbuj znaleźć powtórzenie kluczowych koncepcji na blogu lub w serwisie takim jak SmartReading. Zatem niepróbkowana telemetria odczytuje każdą „stronę” ruchu sieciowego, czyli analizuje metadane dla każdego pakietu. Telemetria próbkowa to selektywne badanie ruchu w nadziei, że wybrane próbki będą zawierać to, czego potrzebujesz. W zależności od szybkości kanału, próbkowane dane telemetryczne będą wysyłane do analizy co 64., 200., 500., 1000., 2000. lub nawet 10000. pakiet.
W kontekście monitorowania bezpieczeństwa informacji oznacza to, że próbkowana telemetria dobrze nadaje się do wykrywania ataków DDoS, skanowania i rozprzestrzeniania złośliwego kodu, ale może przeoczyć ataki atomowe lub wielopakietowe, które nie zostały uwzględnione w próbce przesłanej do analizy. Telemetria niepróbkowana nie ma takich wad. Dzięki temu zakres wykrywanych ataków jest znacznie szerszy. Oto krótka lista zdarzeń, które można wykryć za pomocą narzędzi do analizy telemetrii sieci.
Oczywiście niektóre analizatory Netflow typu open source nie pozwolą na to, ponieważ jego głównym zadaniem jest zbieranie danych telemetrycznych i przeprowadzanie na nich podstawowej analizy z punktu widzenia IT. Aby identyfikować zagrożenia bezpieczeństwa informacji w oparciu o przepływ, konieczne jest wyposażenie analizatora w różnorodne silniki i algorytmy, które będą identyfikować problemy cyberbezpieczeństwa w oparciu o standardowe lub niestandardowe pola Netflow, wzbogacać standardowe dane o dane zewnętrzne z różnych źródeł Threat Intelligence itp.
Dlatego jeśli masz wybór, wybierz Netflow lub IPFIX. Ale nawet jeśli Twój sprzęt współpracuje tylko z sFlow, jak krajowi producenci, to nawet w tym przypadku możesz z niego skorzystać w kontekście bezpieczeństwa.
Latem 2019 roku analizowałem możliwości, jakie mają rosyjscy producenci sprzętu sieciowego i wszyscy z wyjątkiem NSG, Polygon i Craftway zapowiedzieli wsparcie dla sFlow (przynajmniej Zelax, Natex, Eltex, QTech, Rusteleteh).
Następne pytanie, z którym się spotkasz, brzmi: gdzie wdrożyć obsługę przepływu ze względów bezpieczeństwa? W rzeczywistości pytanie nie zostało postawione całkowicie poprawnie. Nowoczesny sprzęt prawie zawsze obsługuje protokoły przepływu. Dlatego przeformułowałbym pytanie inaczej – gdzie zbieranie danych telemetrycznych jest najskuteczniejsze z punktu widzenia bezpieczeństwa? Odpowiedź będzie dość oczywista - na poziomie dostępu, gdzie zobaczysz 100% całego ruchu, gdzie będziesz miał szczegółowe informacje o hostach (MAC, VLAN, identyfikator interfejsu), gdzie będziesz mógł nawet monitorować ruch P2P pomiędzy hostami, co ma kluczowe znaczenie dla wykrywania i dystrybucji złośliwego kodu przez skanowanie. Na poziomie podstawowym możesz po prostu nie widzieć części ruchu, ale na poziomie obwodowym zobaczysz jedną czwartą całego ruchu sieciowego. Ale jeśli z jakiegoś powodu masz w swojej sieci obce urządzenia, które pozwalają atakującym „wchodzić i wychodzić” bez omijania obwodu, analiza telemetrii z niej nic ci nie da. Dlatego w celu uzyskania maksymalnego zasięgu zaleca się włączenie gromadzenia danych telemetrycznych na poziomie dostępu. Jednocześnie warto zaznaczyć, że nawet jeśli mówimy o wirtualizacji czy kontenerach, to w nowoczesnych przełącznikach wirtualnych często spotyka się także obsługę przepływu, która pozwala na kontrolowanie ruchu również tam.
Skoro jednak poruszyłem temat, muszę odpowiedzieć na pytanie: co jeśli sprzęt, fizyczny lub wirtualny, nie obsługuje protokołów przepływu? A może jego włączenie jest zabronione (na przykład w segmentach przemysłowych w celu zapewnienia niezawodności)? A może włączenie go powoduje duże obciążenie procesora (dzieje się to na starszym sprzęcie)? Aby rozwiązać ten problem, istnieją wyspecjalizowane czujniki wirtualne (czujniki przepływu), które są w zasadzie zwykłymi rozdzielaczami, które przepuszczają ruch przez siebie i rozgłaszają go w postaci przepływu do modułu zbierającego. To prawda, że w tym przypadku mamy wszystkie problemy, o których mówiliśmy powyżej w odniesieniu do narzędzi do przechwytywania pakietów. Oznacza to, że musisz zrozumieć nie tylko zalety technologii analizy przepływu, ale także jej ograniczenia.
Kolejna kwestia, o której należy pamiętać, mówiąc o narzędziach do analizy przepływu. Jeśli w odniesieniu do konwencjonalnych sposobów generowania zdarzeń bezpieczeństwa zastosujemy metrykę EPS (zdarzenie na sekundę), to wskaźnik ten nie ma zastosowania do analizy telemetrycznej; zostaje zastąpiony przez FPS (przepływ na sekundę). Podobnie jak w przypadku EPS, nie można tego z góry obliczyć, ale można oszacować przybliżoną liczbę wątków, które generuje 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 i warunków, które pozwolą oszacować, jakie licencje będą potrzebne narzędziom analitycznym i jaka będzie ich architektura? Faktem jest, że czujnik IDS jest ograniczony pewnym pasmem, które może „wyciągnąć”, a kolektor przepływowy ma swoje własne ograniczenia, które należy zrozumieć. Dlatego w dużych, rozproszonych geograficznie sieciach występuje zwykle kilku kolektorów. Kiedy opisałem , podałem już liczbę naszych kolektorów – jest ich 21. I to dla sieci rozproszonej na pięciu kontynentach i liczącej około pół miliona aktywnych urządzeń).
Wykorzystujemy własne rozwiązanie jako system monitorowania Netflow , który koncentruje się szczególnie na rozwiązywaniu problemów związanych z bezpieczeństwem. Posiada wiele wbudowanych silników wykrywających anomalną, podejrzaną i wyraźnie złośliwą aktywność, co pozwala wykryć szeroką gamę różnych zagrożeń - od kopania kryptowalut po wycieki informacji, od rozprzestrzeniania złośliwego kodu po oszustwa. Podobnie jak większość analizatorów przepływu, Stealthwatch zbudowany jest według trzypoziomowego schematu (generator – kolektor – analizator), jednak uzupełniony jest o szereg ciekawych funkcji, istotnych w kontekście rozpatrywanego materiału. Po pierwsze integruje się z rozwiązaniami do przechwytywania pakietów (takimi jak Cisco Security Packet Analyzer), co umożliwia nagrywanie wybranych sesji sieciowych w celu późniejszego dogłębnego zbadania i analizy. Po drugie, specjalnie w celu rozszerzenia zadań związanych z bezpieczeństwem, opracowaliśmy specjalny protokół nvzFlow, który pozwala „rozgłaszać” aktywność aplikacji na węzłach końcowych (serwery, stacje robocze itp.) do telemetrii i przesyłać ją do kolektora w celu dalszej analizy. Jeśli w oryginalnej wersji Stealthwatch współpracuje z dowolnym protokołem przepływu (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na poziomie sieci, to obsługa nvzFlow umożliwia korelację danych także na poziomie węzła. zwiększenie wydajności całego systemu i odnotowanie większej liczby ataków niż konwencjonalne analizatory przepływu sieci.
Oczywiste jest, że jeśli mówimy o systemach analizy Netflow z punktu widzenia bezpieczeństwa, rynek nie ogranicza się do jednego rozwiązania Cisco. Można korzystać zarówno z rozwiązań komercyjnych, jak i darmowych lub shareware. To dość dziwne, jeśli przytaczam rozwiązania konkurencji jako przykłady na blogu Cisco, więc powiem kilka słów o tym, jak można analizować telemetrię sieciową za pomocą dwóch popularnych, podobnych w nazwie, ale wciąż różnych narzędzi - SiLK i ELK.
SiLK to zestaw narzędzi (System for Internet-Level Knowledge) do analizy ruchu, opracowany przez amerykański CERT/CC i obsługujący, w kontekście dzisiejszego artykułu, Netflow (5. i 9., najpopularniejsze wersje), IPFIX i sFlow oraz wykorzystanie różnych narzędzi (rwfilter, rwcount, rwflowpack itp.) do wykonywania różnych operacji na telemetrii sieci w celu wykrycia w niej oznak nieautoryzowanych działań. Ale jest kilka ważnych punktów, na które należy zwrócić uwagę. SiLK to narzędzie wiersza poleceń, które przeprowadza analizę on-line poprzez wprowadzenie takich poleceń (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
niezbyt wygodne. Możesz skorzystać z GUI iSiLK, ale nie ułatwi Ci to zbytnio życia, rozwiązując jedynie funkcję wizualizacji, a nie zastępując analityka. I to jest drugi punkt. W odróżnieniu od rozwiązań komercyjnych, które posiadają już solidną bazę analityczną, algorytmy wykrywania anomalii, odpowiedni przepływ pracy itp., w przypadku SiLK będziesz musiał to wszystko zrobić sam, co będzie wymagało od Ciebie nieco innych kompetencji niż przy korzystaniu z już gotowych- używać narzędzi. To nie jest ani dobre, ani złe – to cecha niemal każdego bezpłatnego narzędzia, które zakłada, że wiesz, co robić, a to tylko Ci w tym pomoże (narzędzia komercyjne w mniejszym stopniu zależą od kompetencji swoich użytkowników, chociaż też zakładają aby analitycy rozumieli przynajmniej podstawy badań i monitorowania sieci). Wróćmy jednak do SiLK-a. Cykl pracy analityka z nim wygląda następująco:
- Formułowanie hipotezy. Musimy zrozumieć, czego będziemy szukać wewnątrz telemetrii sieci, znać unikalne atrybuty, po których zidentyfikujemy określone anomalie lub zagrożenia.
- Budowa modelu. Po sformułowaniu hipotezy programujemy ją przy użyciu tego samego Pythona, powłoki lub innych narzędzi, których nie ma w SiLK.
- Testowanie. Teraz przychodzi kolej na sprawdzenie poprawności naszej hipotezy, którą potwierdzamy lub odrzucamy za pomocą narzędzi SiLK rozpoczynających się od „rw”, „set”, „bag”.
- Analiza rzeczywistych danych. W zastosowaniach przemysłowych SiLK pomaga nam coś zidentyfikować, a analityk musi odpowiedzieć na pytania: „Czy znaleźliśmy to, czego się spodziewaliśmy?”, „Czy odpowiada to naszej hipotezie?”, „Jak zmniejszyć liczbę fałszywych alarmów?”, „Jak poprawić poziom rozpoznawalności? » i tak dalej.
- Poprawa. Na ostatnim etapie poprawiamy to, co zostało zrobione wcześniej – tworzymy szablony, ulepszamy i optymalizujemy kod, przeformułujemy i doprecyzowujemy hipotezę itp.
Cykl ten będzie dotyczył również Cisco Stealthwatch, tylko ten ostatni maksymalnie automatyzuje te pięć kroków, redukując liczbę błędów analityków i zwiększając skuteczność wykrywania incydentów. Przykładowo w SiLK można wzbogacić statystyki sieciowe danymi zewnętrznymi o złośliwych adresach IP za pomocą odręcznie napisanych skryptów, a w Cisco Stealthwatch jest to wbudowana funkcja, która natychmiast wyświetla alarm, jeśli ruch sieciowy zawiera interakcje z adresami IP z czarnej listy.
Jeśli pójdziesz wyżej w „płatnej” piramidzie oprogramowania do analizy przepływów, to po całkowicie darmowym SiLK pojawi się shareware 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 napisać samodzielnie, ELK posiada już wiele gotowych bibliotek/modułów (niektóre płatne, inne nie), które automatyzują analizę telemetrii sieci. Na przykład filtr GeoIP w Logstash pozwala powiązać monitorowane adresy IP z ich lokalizacją geograficzną (Stealthwatch ma tę wbudowaną funkcję).
ELK ma także dość dużą społeczność, która kompletuje brakujące komponenty do tego rozwiązania monitorującego. Na przykład do pracy z Netflow, IPFIX i sFlow możesz użyć modułu , jeśli nie jesteś zadowolony z modułu Logstash Netflow, który obsługuje tylko Netflow.
Dając większą efektywność w zbieraniu przepływów i wyszukiwaniu w nich, ELK obecnie nie posiada bogatej wbudowanej analityki służącej do wykrywania anomalii i zagrożeń w telemetrii sieci. Oznacza to, że zgodnie z opisanym powyżej cyklem życia będziesz musiał samodzielnie opisać modele naruszeń, a następnie zastosować je w systemie walki (nie ma tam wbudowanych modeli).
Istnieją oczywiście bardziej wyrafinowane rozszerzenia dla ELK, które zawierają już pewne modele służące do wykrywania anomalii w telemetrii sieci, jednak takie rozszerzenia kosztują i tu pojawia się pytanie, czy gra jest warta świeczki - napisz sam podobny model, kup go wdrożenie dla Twojego narzędzia monitorującego lub kup gotowe rozwiązanie klasy Analiza Ruchu Sieciowego.
Generalnie nie chcę wdawać się w dyskusję, że lepiej wydać pieniądze i kupić gotowe rozwiązanie do monitorowania anomalii i zagrożeń w telemetrii sieci (np. Cisco Stealthwatch) albo samemu to przemyśleć i dostosować SiLK, ELK lub nfdump lub OSU Flow Tools dla każdego nowego zagrożenia (mówię o dwóch ostatnich ostatni raz)? Każdy wybiera dla siebie i każdy ma swoje własne motywy wyboru którejkolwiek z dwóch opcji. Chciałem tylko pokazać, że telemetria sieciowa jest bardzo ważnym narzędziem zapewniającym bezpieczeństwo sieciowe Twojej infrastruktury wewnętrznej i nie należy jej zaniedbywać, aby nie trafić na listę firm, których nazwa pojawia się w mediach wraz z epitetami „ zhakowany”, „niezgodny z wymogami bezpieczeństwa informacji”, „nie myślący o bezpieczeństwie swoich danych i danych klientów”.
Podsumowując, chciałbym wymienić najważniejsze wskazówki, którymi warto się kierować budując monitoring bezpieczeństwa informacji swojej infrastruktury wewnętrznej:
- Nie ograniczaj się tylko do obwodu! Wykorzystuj (i wybieraj) infrastrukturę sieciową nie tylko do przenoszenia ruchu z punktu A do punktu B, ale także do rozwiązywania problemów związanych z cyberbezpieczeństwem.
- Zapoznaj się z istniejącymi mechanizmami monitorowania bezpieczeństwa informacji w sprzęcie sieciowym i wykorzystaj je.
- W przypadku monitorowania wewnętrznego preferuj analizę telemetryczną - pozwala ona wykryć do 80-90% wszystkich incydentów związanych z bezpieczeństwem informacji w sieci, robiąc jednocześnie to, co jest niemożliwe przy przechwytywaniu pakietów sieciowych i oszczędzaniu miejsca na przechowywanie wszystkich zdarzeń związanych z bezpieczeństwem informacji.
- Do monitorowania przepływów użyj 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żyj protokołu przepływu niepróbkowanego — dostarcza on więcej informacji potrzebnych do wykrywania zagrożeń. Na przykład Netflow lub IPFIX.
- Sprawdź obciążenie sprzętu sieciowego — może on również nie być w stanie obsłużyć protokołu przepływu. Następnie rozważ użycie czujników wirtualnych lub urządzenia Netflow Generation Appliance.
- Wprowadź kontrolę przede wszystkim na poziomie dostępu - dzięki temu będziesz mieć możliwość zobaczenia 100% całego ruchu.
- Jeśli nie masz wyboru i korzystasz z rosyjskiego sprzętu sieciowego, wybierz taki, który obsługuje protokoły przepływu lub ma porty SPAN/RSPAN.
- Połącz systemy wykrywania/zapobiegania włamaniom/atakom na brzegach i systemy analizy przepływu w sieci wewnętrznej (w tym w chmurach).
Jeśli chodzi o ostatnią wskazówkę, chciałbym podać ilustrację, którą podałem już wcześniej. Widać, że jeśli wcześniej służba bezpieczeństwa informacji Cisco niemal w całości budowała swój system monitorowania bezpieczeństwa informacji w oparciu o systemy wykrywania włamań i metody sygnatur, to obecnie stanowią one zaledwie 20% incydentów. Kolejne 20% przypada na systemy analizy przepływów, co sugeruje, że rozwiązania te nie są kaprysem, ale realnym narzędziem w działalności służb bezpieczeństwa informacji współczesnego przedsiębiorstwa. Co więcej, masz do ich realizacji najważniejszą rzecz - infrastrukturę sieciową, w którą inwestycje można dodatkowo zabezpieczyć, przypisując do sieci funkcje monitorowania bezpieczeństwa informacji.
Konkretnie nie poruszyłem tematu reagowania na anomalie czy zagrożenia zidentyfikowane w przepływach sieciowych, ale myślę, że już jest jasne, że monitoring nie powinien kończyć się jedynie na wykryciu zagrożenia. Po nim powinna nastąpić odpowiedź, najlepiej w trybie automatycznym lub automatycznym. Ale to temat na osobny artykuł.
Dodatkowe informacje:
PS. Jeśli łatwiej Ci będzie usłyszeć wszystko, co napisano powyżej, możesz obejrzeć godzinną prezentację, która stała się podstawą tej notatki.
Źródło: www.habr.com