Webinarium „Co w sieci leci”

Dawid Zięcina:

Dzień dobry Państwu. Jest mi niezmiernie miło powitać Państwa na dzisiejszym webinarze organizowanym przez firmę EXATEL wraz z firmą Flowmon. Nazywam się Dawid Zięcina i w EXATEL zajmuję stanowisko Kierownika Projektu w Zespole Wsparcia Sprzedaży. Ze strony naszego partnera technologicznego, firmy Flowmon, webinar współprowadzi Klaudyna Busza-Kujawska.

Klaudyna Busza-Kujawska:

Dzień dobry, witam serdecznie.

Dawid:

Wspólnie z Klaudyną przedstawimy dzisiaj Państwu takie dosyć wyspecjalizowane narzędzie, którego zastosowanie w bardzo szerokim spektrum umożliwia wielopoziomowy monitoring sieci, a wszystko to w prostym i przyjaznym środowisku graficznym.

EXATEL jako operator działający od 20 lat na rynku usług telekomunikacyjnych, posiada 20 tysięcy kilometrów własnej sieci światłowodowej na terenie całego kraju. Dzięki rozbudowanej i bardzo dobrze zorganizowanej sieci dostępowej, możemy w dowolnej lokalizacji podłączyć Państwu usługi głosowe, jak i dowolne usługi transmisji danych, takie jak dostęp do sieci Internet czy MPLS łączący lokalizacje klientów wielooddziałowych. Obsługujemy klientów z branży finansowej, energetycznej i wielu innych sektorów. To co zdecydowanie wyróżnia nas spośród pozostałych operatorów, to sposób podejścia do kwestii bezpieczeństwa informacji. Gwarantujemy dyskrecję i najwyższy poziom bezpieczeństwa informacji. Posiadamy Certyfikat Bezpieczeństwa Przemysłowego pierwszego stopnia o klauzuli Ściśle Tajne, UE Secret, NATO Secret, Certyfikat ISO 27001 oraz ISO 22301.

Ostatnia dekada to dynamiczny rozwój cyberzagrożeń. Wyprzedzając naszą konkurencję, kilka lat temu rozpoczęliśmy budowę organizacji świadomie dbającej o bezpieczeństwo sieci klientów. Poza zespołami stale monitorującymi funkcjonowanie naszej sieci i urządzeń (NOC), mamy także zespół odpowiedzialny za kontakt z klientami (BOK) i wykwalifikowany zespół profesjonalistów z zakresu cyberbezpieczeństwa (SOC). Nasi eksperci z departamentu cyberbezpieczeństwa, dbają nie tylko o bezpieczeństwo naszej sieci, ale w ramach SOC świadczą także usługi ochrony przed atakami DDoS, usługę Managed Firewall, jak również usługi doradztwa w zakresie bezpieczeństwa IT, w tym testy penetracyjne aplikacji i sieci, inżynierię wsteczną oprogramowania, audyty bezpieczeństwa systemów operacyjnych i baz danych. Cyberbezpieczeństwo to nie tylko wiedza, doświadczenie i ludzie. To także technologia – sprzęt i narzędzia do walki z cyberzagrożeniami. Używamy tylko tych technologii, którymi chronimy się sami. Daje nam to pełną kontrolę nad technologią, która staje się wtedy naszym orężem, a nie przeszkodą w cyberpotyczkach. Stawiamy na sprawdzonych partnerów z którymi utrzymujemy bliskie i dobre relacje. Jednym z wiodących partnerów jest firma Flowmon, której przedstawicielka będzie lada moment demonstrować Państwu zalety i przemyślane autorskie rozwiązania ich platformy.

Z mojej strony przedstawię teraz Państwu najczęstsze obszary zastosowań technologii Flowmon po które sięgamy, żeby spełnić wymagania naszych klientów i pomóc im w codziennych bolączkach, jeżeli chodzi o funkcjonowanie sieci. Dzisiejszy webinar nie jest studium przypadku. Jest to prezentacja rozwiązań firmy Flowmon, więc jeżeli ktoś z Państwa będzie zainteresowany którymś z rozwiązań szczegółowo, to zapraszam do kontaktu po webinarze.

Często w ramach projektów integratorskich EXATEL, nasi inżynierowie zmagają się z niezamierzoną niewiedzą klienta odnośnie tego jak funkcjonuje jego sieć. Coraz większa ilość klientów ma bardzo dobrze opracowany punkt styku z siecią Internet. Są tam naprawdę dobre rozwiązania, które są na bieżąco monitorowane. Zdecydowana większość klientów ma też świadomość zagrożeń na jakie wystawione są ich stacje robocze, dlatego prawie zawsze spotykamy któryś z systemów ochrony typu endpoint protection funkcjonujący na komputerach w sieci klienta. W bardzo dużej liczbie analizowanych przez nas sieci, brakuje jednak informacji o tym, w jaki sposób pracuje sieć i jak wygląda przepływ strumienia danych przez sieć. Niekoniecznie te dane muszą opuszczać sieć klienta. Nawet w sytuacji monitorowania parametrów pracy sieci, bardzo rzadko spotykamy zaimplementowane rozwiązania monitorujące anomalie występujące wewnątrz sieci klienta. Nawet przy przemyślanie wykonanej segmentacji, wskazujemy mimo wszystko takie punkty sieci, które są pozbawione bieżącego monitoringu, chociażby weryfikacji wydajności, obciążenia poszczególnych elementów sieci, na braku weryfikacji czy dany ruch w ogóle jest pożądany.

Coraz częściej spotykamy się też z zapytaniami ze strony klientów, czy jesteśmy w stanie pomóc im poznać jaką charakterystykę ma ruch wewnątrz ich sieci i czy ruch ten jest w ogóle zasadny. W środowiskach sieciowych pracuje obecnie coraz większa liczba aplikacji krytycznych dla biznesu. Ponieważ realizujemy liczne testy penetracyjne aplikacji webowych i mobilnych, a wyniki naszej pracy zadowalają najbardziej wymagające instytucje – co buduje dobrą opinię EXATELA na rynku – wobec tego cały czas rozbudowujemy zespół pentesterów, aby sprostać ilości zapytań zainteresowanych klientów. Pracujemy bardzo blisko klienta i na żywym organizmie aplikacyjnym. Często spotykamy się z pytaniami, czy znamy jakieś metody na problemy z którymi spotyka się klient w środowisku aplikacji sieciowych. Sam dostęp do aplikacji czy zasobów baz danych, to złożona ścieżka technologii, za którą idą poszczególne elementy i każdy z tych elementów może wnosić niechciany lub negatywny udział. Taka inwestygacja przyczyn nieprawidłowego działania aplikacji z punktu widzenia użytkownika końcowego, nie jest zadaniem prostym, w szczególności w rozbudowanych środowiskach IT, tworzonych z wielu komórek organizacyjnych i operacyjnych, takich jak zespoły sieciowców, zespoły utrzymania centrum danych lub serwerów, a na opiekunach aplikacji, programistach i deweloperach skończywszy. Szczególnie cennym rozwiązaniem jest połączenie wiedzy o wydajności sieci, platformy sprzętowej oraz aplikacji, w jednym, skonsolidowanym widoku, co daje IT wgląd bezpośrednio w przyczynę obniżonej wydajności środowiska.

EXATEL posiada własne SOC. Zainteresowanie tą usługą na rynku jest coraz większe. Mamy coraz większą ilość zapytań odnośnie tego typu usługi, w szczególności w świetle ustawy o Krajowym Systemie Cyberbezpieczeństwa. Sam proces analizy i integracji zasobów klienta z SIEM EXATELA, to proces niezwykle istotny dla powodzenia całego przedsięwzięcia. Nie jest to jedyny element, ale jest on praktycznie tym bazowym. Nieprawidłowo zdefiniowane źródła mogą nie dawać rzeczywistego obrazu sytuacji w sieci lub w zasobach klienta. Niezwykle ważnym jest, by bez dużej ingerencji w sieci klienta, móc zaimplementować dodatkowe sondy i źródła dające jak najbardziej kompletną informację o zdarzeniach na zasobach klienta. Gdy klienci dowiadują się, że potrzebujemy jakichś dodatkowych źródeł bo chcemy coś gdzieś umieścić, wyrażą obawy, że wpięcie tych dodatkowych źródeł, będzie wymagało przebudowy infrastruktury, czasowe odłączenie całej sieci bądź jej poszczególnych segmentów, a finalnie obniżenie dostępności infrastruktury poprzez wpięcie kolejnego urządzenia sieciowego, które może zawieść w najmniej oczekiwanej sytuacji. Rozwiązanie firmy Flowmon adresuje te obawy i daje konkretne przykłady zastosowań platformy. Wszystkie wspomniane przeze mnie obszary, potrzeby klientów które dostrzegamy, realizacja zaleceń integratorskich czy audytorskich, wszystko to można zaadresować poprzez jedno wdrożenie rozwiązania firmy Flowmon. Wgląd w stan sieci i ruch sieciowy, śledzenie anomalii, weryfikacja wydajności aplikacji sieciowych, integracja zasobów klienta z systemem SIEM i wiele innych nieporuszonych tutaj ze względów czasowych atutów, uzyskujemy tylko jednym wdrożeniem.

Klaudyna:

Tak jest. W związku z tym, sprawdźmy co w tej sieci leci. Żeby to sprawdzić, możemy wykorzystać do tego celu nasze urządzenia sieciowe, te które już Państwo w sieci posiadacie, ponieważ potrafią one generować flowy. Oczywiście jest to opcja, którą musimy dopiero skonfigurować, ale zawsze warto zweryfikować, na jakich urządzeniach w Państwa sieci, możecie taką funkcjonalność otrzymać. Z jakich urządzeń można takie flowy otrzymać? Najczęściej wykorzystuje się do tego celu routery i switche różnych producentów. Oczywiście będą też tutaj różne rodzaje Netflowa wspierane na różnych rozwiązania. Może to być Netflow w wersji 5., 9., może to być IPFIX, czyli najnowsza, rozszerzona wersja protokołu Netflow. Może to być JFlow. Są tutaj różne opcje, ale głównie są to przede wszystkim routery i switche. Dalej mogą to być firewalle, UTM-y, a od niedawna wspierany jest też Netflow na tego typu systemach. Dodatkowo jeżeli posiadacie w sieci jakieś packet brokery, to one bardzo często mają też możliwość włączenia IPFIX-a i wysyłania flowów do wskazanego miejsca. I jeszcze jeden element – oczywiście mogą to być dedykowane urządzenia. Takim dedykowanym urządzeniem – które powstało po to żeby tworzyć flowy – jest sonda Flowmon.

Jak to wygląda z punktu widzenia elementów, które są potrzebne by otrzymać taki wgląd w swoją sieć? Podstawą jest kolektor i jest to jedyny obowiązkowy element którego potrzebujemy, jeżeli chcemy skorzystać z monitoringu. Jeżeli mamy na swoich urządzeniach sieciowych możliwość włączenia flowów, to wystarczy nam tylko to. Zbieramy flowy z urządzeń sieciowych, a na kolektorze je przechowujemy. Mamy tutaj dostęp do analizy, raportowania, tworzenia swoich widoków, dashboardów, profili, więc może to być całość wdrożenia, tylko jeden sprzęt, chyba że nie mamy w odpowiedniej jakości tych flowów z urządzeń sieciowych, bo tutaj wszystko zależy od konkretnego modelu urządzenia sieciowego, od tego jakie opcje są wspierane. Jeżeli więc nie mamy dobrej jakości flowów, albo w jakimś fragmencie sieci w ogóle nie ma możliwości by uruchomić tam Netflow, to możemy dostawić sondę. Sonda jest też wykorzystywana nie tylko w momencie kiedy nie ma możliwości zbierania flowów z urządzeń sieciowych. Możemy ją dostawić również po to, żeby rozszerzyć widoczność tego, co dzieje się wewnątrz sieci, ponieważ standardowo flowy z urządzeń sieciowych, wspierają informacje do warstwy 3. i 4., IP i porty, natomiast sonda dokłada nam tu jeszcze mnóstwo informacji dodatkowych z warstwy 7. – więc uzyskujemy dużo więcej – i wykonuje też odpowiednie pomiary. Czyli kolektor jest elementem obowiązkowym, natomiast sonda jest opcjonalna. Na kolektorze mogą być zainstalowane różne moduły funkcjonalne w zależności od tego, co chcemy osiągnąć – czy tylko monitoring (bo jest to wbudowana funkcjonalność kolektora), czy analizę behawioralną (czyli wsparcie bezpieczeństwa), osobny moduł do analizy aplikacji i nagrywania pakietów oraz DDoS Defender, do wykrywania ataków wolumetrycznych.

Sam kolektor jest urządzeniem, które zbiera flowy. Wydajność najmniejszego sprzętu to 100 tysięcy flowów na sekundę, a największego 400 tysięcy flowów na sekundę. Kolejne modele różnią się od siebie wielkością storage’u, więc możecie tutaj Państwo odpowiednio dobrać do tego, jak długą historię tych danych chcecie uzyskać, czy chcecie np. przez rok przechowywać informacje szczegółowe o tym co działo się w sieci, czy może przez dwa lata. To już zależy od Państwa i doboru odpowiedniego sprzętu. Kolektor może być zarówno w wersji hardware, jak i w wersji wirtualnej.

Sonda jest tym urządzeniem, które służy do tworzenia flowów, czyli zbiera pakiety, przetwarza je na flowy w formacie IPFIX – czyli w tym najnowszym formacie Netflow’owym – dokładając dodatkowe informacje. Są to informacje z warstwy 2. (tego już jest troszeczkę więcej), z warstwy 3. to co istotne poza standardowymi informacjami – z jakiego adresu IP na jaki adres IP, z jakiego portu na jaki port, ile danych było wysłanych – mamy dodatkowo parę innych informacji, które mogą nam posłużyć zarówno dla bezpieczeństwa, jak i dla weryfikacji wydajności sieci, czyli metryki wydajności sieci. Round Trip Time, Server Response Time, retransmisja, opóźnienia, cheatery, wszystko co jest związane z wydajnością sieci. Plus informacje z warstwy 7. Tutaj sonda robi NBAR2, czyli rozpoznawanie aplikacji bazujące na tym co jest widoczne w warstwie 7., ale poza tym z wielu innych aplikacji są dokładane dodatkowe informacje (z HTTP, z DNS-a), mamy tu też możliwość monitorowania SSL/TLS, informacje związane z ruchem mailowym, VoIP-owym. Tego jest cały czas coraz więcej, bo dokładamy wsparcie dla kolejnych aplikacji.

Sonda zbiera pakiety, a tworzy Netflow, więc można ją podłączyć do sieci albo najczęściej do SPAN portu lub Mirror portu, gdzie otrzymuje kopie ruchu, bądź możemy podłączyć do TAP-a. TAP może być taki całkowicie standardowy, zwykły, stawiany inline’owo na łącza, ale mogą to być oczywiście, jeżeli mają Państwo packet blockery, które są w jakiś sposób bardziej rozbudowane i potrafią filtrować ruchy i przekazywać na porty wyjściowe. Jest to jak najbardziej idealne źródło dla naszych sond. Sonda może też być w wersji hardware. W tej jest wersji jest najczęściej wtedy, gdy chcemy monitorować środowisko fizyczne, bo potrzebujemy jakichś portów 1 lub 10 Gb. Mogą też być 100 Gb, bo taką sondę również mamy z dwoma interfejsami 100 Gb. Ale jest też w wersji wirtualnej. Ostatnio mamy coraz większe zainteresowanie sondami wirtualnymi, ponieważ dają one wgląd w to, co dzieje się wewnątrz środowiska wirtualnego. Jeżeli mamy tak zbudowaną sieć, że np. komunikacja pomiędzy serwerami webowymi, a serwerami baz danych, te serwery będą w różnych VLAN-ach, więc ta komunikacja będzie wychodziła ze środowiska wirtualnego, będzie wykonywany routing i dopiero będzie docierała do serwera bazodanowego, to świetnie, bo gdzieś na zewnątrz tego środowiska wirtualnego, możemy złapać taki ruch, przeanalizować go i zweryfikować. Ale co jeżeli wszystko dzieje się w takiej płaskiej strukturze, że jest przetwarzane pomiędzy maszynami wirtualnymi i zamyka się na środowisku wirtualnym? Tracimy wtedy widoczność tego co się tam dzieje, jak dużo danych jest przesyłanych, czy po której stronie leży problem – po stronie serwera aplikacji czy może serwera baz danych? Tutaj z pomocą przychodzi sonda. Nawet jeżeli mamy zwykłe vSwitche, to też dotyczy środowiska ? (20:04). Mogą to być standardowe switche bez żadnych rozbudowanych opcji. Jest taka możliwość żeby ustawić na nich ? (20:14), czyli właśnie takiego trunka, tryb na porcie monitorującym ? (20:20)  i wtedy wszystko co przechodzi przez takiego switcha, trafia również na sondę. Dzięki temu sonda posiada pakiety, przerabia je na Netflow i mamy informacje o flowach, o komunikacji która właśnie na tym switchu miała miejsce.

Mówiłam że sondy mają możliwość dokładania różnych informacji z warstwy 7., np. z DNS-a. Co to znaczy? W przypadku DNS-a tych elementów jest bardzo dużo, m.in. mamy informację czy było to zapytanie czy odpowiedź, jaki był question name, jaki response data, jakiego typu była to odpowiedź, czy był to adres IP wersji 6., czy wersji 4., czy może ? (21:12), czy został zwrócony jakiś błąd przez serwer, lub informacja że taka domena nie istnieje, co jest bardzo przydatne przy analizie bezpieczeństwa i błędów sieciowych. Tych elementów tutaj jest bardzo dużo i pokażę Państwu jak to wygląda na demo, jak można analizować taki ruch DNS-owy i jakie elementy są możliwe do otrzymania do analizy.

Sieć czy nie sieć, oto jest pytanie. Jeżeli mamy sieciowców po drugiej stronie odbiornika, to zapewne wszyscy powiedzą „jak to, wiadomo że sieć”. Flowmon daje Państwu możliwość na udowodnienie tego, że problem nie leży po stronie sieci, bądź potwierdzenie tego, że rzeczywiście mamy z nią jakiś problem, któremu należy się przyjrzeć i zweryfikować dokładnie w którym miejscu ten problem występuje. Żeby takie informacje otrzymać, potrzebujemy sondy, bo są to dane pomierzone z pakietów, czyli w Netflow nie znajdziecie tych informacji. Będzie to Server Response Time (SRT) i informacja o tym jakie opóźnienie wprowadza serwer, jakie było opóźnienie serwera. Network Round Trip Time (RTT) – to co nas interesuje z punktu widzenia sieci, czyli właśnie opóźnienie wprowadzane przez sieć, informacja jak długo trwało zestawienie Three-Way-Handshake (trzy pakiety muszą przejść żeby ten RTT został pomierzony). Ale poza tym jeszcze obliczane opóźnienia, Jittery, retransmisje, czy pakiety out of order, co w zależności od aplikacji którą monitorujemy, może mieć duże znaczenie, czy właśnie pozwala nam tutaj znaleźć gdzie może leżeć problem, patrząc z punktu widzenia sieciowego. Wiadomo, że jeżeli będziemy mieli wysoki RTT i dużo retransmisji, to niestety będzie to problem sieci i tutaj już nie możemy zrzucać winy na dział aplikacji, tylko należy przyjrzeć się dokładnie w którym miejscu, pomiędzy jakimi parami adresów, którędy idzie ta komunikacja, bo być może jest to problem z jakimś mało wydajnym switchem, bottleneckiem, który mamy gdzieś w sieci. Głównie te dwa parametry mówią nam o tym czy jest w porządku z punktu widzenia sieciowego czy nie. Czyli RTT i retransmisje.

Informacje odnośnie parametrów sieciowych, macie Państwo dostępne w sposób wbudowany w systemie. Nie trzeba tego dodatkowo tworzyć. Oczywiście mogą Państwo utworzyć sobie odpowiednie widoki, dashboardy dla danej części sieci, która Was interesuje, ale na wszystkich wykresach które sobie przygotujecie, na wszystkich widokach ruchu sieciowego, będziecie mieli możliwość włączenia i wyłączenia widoku jak się rozkłada RTT, jak wygląda SRT w danych porach dnia, w związku z tym będzie też widać czy np. wyższy SRT ma związek ze zwiększoną ilością ruchu przesyłanego do serwera przez większą ilością połączeń. Jeżeli przełączymy się na flowy, to wtedy będziemy wiedzieć, że np. więcej użytkowników korzysta z jakiejś aplikacji i może wtedy serwer okazuje się mało wydajny. Tak samo z RTT. Jeżeli wzrasta nam ilość ruchu sieciowego i wzrasta RTT, to przyczyną może być zbyt mała wydajność urządzeń sieciowych.

Dawid wspomniał też o tym, że EXATEL wykorzystuje Flowmona również w kontekście bezpieczeństwa. Mamy moduł Anomaly Detection System, który służy właśnie do analizy behawioralnej, działając na flowach. Analizuje on flowy w kontekście tego, w jaki sposób urządzenia sieciowe się zachowują, jak wygląda zachowanie urządzeń w sieci. Co nam daje taka analiza? Przede wszystkim daje nam możliwość wykrywania incydentów bezpieczeństwa. Mogą to być jakieś ataki przeprowadzane ze środka sieci. Bardzo często brzeg sieci jest dobrze zabezpieczony, ale nie ma widoczności tego co dzieje się wewnątrz. Jeżeli więc jakiś atak nie przechodzi przez firewalla, to nigdy się Państwo o tym nie dowiecie, bo będzie to np. tylko wewnątrz jednego filara. Flowy posłużą nam do tego, żeby otrzymać tę widoczność, natomiast analiza behawioralna do tego, by wykryć że coś nieprawidłowego się dzieje – czyli jakieś ataki, próby wyciągnięcia danych z wewnątrz na zewnątrz, skanowanie portów i podobne symptomy – i urządzenie sieciowe zostało zainfekowane. Poza tym analizę behawioralną możemy wykorzystać do weryfikacji, czy są wykorzystywane jakieś aplikacje, które są niedozwolone przez politykę sieciową firmy, np. korzystanie z TOR-a, Bittorenta czy obchodzenie Proxy w jakiś sposób. Otrzymamy również informację czy do sieci przedostał się malware, również z informacjami gdzie się łączył, jakie dane mógł zdobyć, jeżeli był to jakiś ransomware to gdzie mógł dotrzeć, do jakich urządzeń. Dowiemy się też czy zasoby sieciowe są wykorzystywane zgodnie z przeznaczeniem, a więc np. wykrywanie koparek kryptowalut, czy backupy są wykonywane tak jak być powinny, czy różnego typu ataki wykorzystujące 0-day, czyli coś jeszcze nieznanego, co może się pojawić i nie zostanie zablokowane przez żadne zabezpieczenia na brzegu naszej sieci. Przerwy w dostawie usług sieciowych również będą wykryte. Daje nam to przede wszystkim automatyzację. Możecie Państwo pewnie takie informacje znaleźć sami, analizując po prostu flowy jeden po drugim. Jeżeli wiecie czego szukacie, to jest dużo łatwiej, bo filtrujecie odpowiednie adresy IP, albo rodzaj komunikacji HTTP czy DNS, natomiast jeżeli nie wiecie czego macie szukać, to jest to dużo trudniejsze. W związku z tym taki system daje nam automatyzację i szybkość wykrywania i odnajdywania problemów w sieci. Znowu odwołam się do tego co Dawid wcześniej mówił, ponieważ rzeczywiście z takiej analizy behawioralnej możecie Państwo otrzymać ? (29:13) eventy, zasilać SIEM-a wykrytymi eventami. Są to już tylko wykryte, podejrzane, niepewne zachowania, a nie całość komunikacji, która wydarza się wewnątrz sieci. Tak naprawdę większość z tego jest całkowicie normalna, standardowa i nie ma potrzeby się tym zajmować jeżeli nie mamy żadnego problemu, natomiast tutaj wykrytymi eventami możemy zasilać SIEM-a i już wtedy mamy w SIEM-ie wszystkie najistotniejsze informacje, to co się działo na urządzeniach sieciowych i dodatkowo właśnie w samej sieci.

Monitoring sieci z wykorzystaniem Flowmona jest możliwy w każdej dowolnej sieci, niezależnie od systemu i sprzętów sieciowych jakie Państwo posiadacie, ponieważ po naszej stronie wspieramy wszystkie rodzaje protokołu Netflow, które są dostępne na rynku. W związku z tym jeżeli mamy gdzieś takie informacje, to możemy je zbierać. Jeżeli macie takie switche i routery, które nie mają możliwości oznaczania flowów, to nie ma problemu, możemy wstawić tam sondę, czy to wirtualną czy też fizyczną. Ostatecznie i tak zawsze uzyskamy tę widoczność wewnątrz sieci. Zawsze jest jakiś sposób. Kolektor również może być w postaci maszyny wirtualnej, także wybór leży po Państwa stronie.

Z punktu widzenia bezpieczeństwa, analiza behawioralna jest narzędziem działającym w oparciu o flowy. Jeżeli chcemy, możemy dostawić sondę i mamy wówczas więcej informacji. Mamy informacje z warstwy 7., więc jest tego dużo więcej. Na samych flowach analiza behawioralna również działa świetnie i możemy w ten sposób wspierać też SIEM-a dodatkowymi informacjami związanymi z tym, co dzieje się w ruchu sieciowym.

Demo:

Jeżeli chodzi o monitoring sieciowy, to możecie Państwo analizować różne pliki w waszej sieci, czyli analizować jak ten ruch sieciowy wygląda, co w nim nastąpiło. Jeżeli pojawia się jakiś problem to można analizować dlaczego, kogo to dotyczy, o co chodziło. Możecie Państwo przygotować sobie takie widoki, które pozwalają na szybkie spojrzenie na stan sieci, co się dzieje, jak wygląda, czy jest coś podejrzanego lub wartego przeanalizowania. Takie dashboardy (widoki) możecie np. tworzyć tematycznie. Mogą to być elementy związane z analizą konkretnych serwerów, usług, aplikacji, więc w zależności od tego kto jaką częścią strefy IT wewnątrz firmy się zajmuje, może mieć przygotowane takie widoki. Każdy użytkownik systemu może mieć swoje i tutaj mamy pełną dowolność tworzenia. Tu jest taki przykładowy dashboard, gdzie mamy informacje z analizy behawioralnej o tym, jak wygląda lub ile jest podejrzanej komunikacji, a ile jest ruchu prawidłowego (na zielono). Możemy sobie oczywiście zmieniać przedziały czasowe w jakich chcemy to analizować. Mamy też informacje o tym jakie ostatnio pojawiły się zdarzenia, jakie zostały wykryte, jak dużo ich było. Możemy mieć jeszcze hosty, które wygenerowały najwięcej podejrzanych eventów, więc od razu możemy sobie przejść z takiego widoku. Te widoki są odświeżane na bieżąco. Dalej mamy informacje chociażby o tym, jak wygląda ruch sieciowy, żeby wiedzieć jak bardzo obciążona jest teraz nasza sieć. Dalej możemy mieć jakąś strukturę ruchu związaną z różnymi usługami czy np. z ruchem mailowym. Po prawej stronie mamy widoki typu „top”, np. top usług po TCP, jakiego rodzaju komunikacji jest najwięcej (HTTPS jest najwięcej). Mamy tu też komunikację związaną z transmisją plików i dalej np. najczęściej odwiedzane strony internetowe i można sobie taki widok przygotować. To jest taki ogólny pogląd na to co dzieje się w sieci. Możemy mieć kolejną zakładkę związaną już tylko z monitoringiem np. ruchu HTTP/HTTPS – informacje ile tego ruchu jest obecnie, jak wygląda, jak się rozkłada w czasie, ale również zestawienia typu „top” związane z certyfikatami, szyfrowaniem. Jeżeli chcecie, możecie mieć przygotowany widok dla konkretnych serwerów i mamy wtedy informacje o tym, czy jakieś alarmy się dla niego pojawiły, jak wygląda SRT takiego serwera, czy mamy dużo retransmisji. Tu akurat jest ustawione nie tylko dla tego serwera ale ogólnie dla par adresów, więc możemy zobaczyć czy gdzieś w sieci jest dużo retransmitowanych pakietów pomiędzy takimi parami adresów i jakiś ruch SSH kierowany np. do tego konkretnego serwera. Jeżeli chcemy sobie stworzyć nowy widok (np. dla DNS), to jest to bardzo prosta sprawa. Tworzymy nową zakładkę i wybieramy odpowiednie widoki i zestawy, które chcemy sobie wyświetlać tutaj na stronie. Możecie też wybrać Państwo czy chcecie mieć wykres kołowy, czy może tylko widzieć samą tabelkę. Jest tutaj też kilka opcji do wyboru. Statystyki typu „top” bądź „rozkład w czasie”, trzeba wcześniej przygotować. Mamy np. NXDomain. Dlaczego jest to istotne? NXDomain to odpowiedź od serwera, że taka domena nie istnieje. W związku z tym jeżeli mamy jakiegoś hosta, który otrzymuje bardzo dużo takich odpowiedzi, to co to może oznaczać? Albo wysyła złe zapytania do serwera DNS, czyli po prostu błędy konfiguracji, albo jest to rodzaj skanowania sieci pod kątem odpytania dostępności różnych usług, nazw i otrzymania dzięki temu adresów IP związanych właśnie z tymi nazwami domenowymi. W związku z tym jest to bardzo dobry parametr do monitorowania.

Jeżeli mamy tutaj taki dashboard i widzimy coś co nas zainteresowało, jakąś statystykę albo jakiś pick na wykresie, to możemy przejść do analizy. Otworzy nam się dokładnie ten sam widok, ta sama statystyka, którą byliśmy zainteresowani i dzięki temu będziemy mogli dalej – już na zasadzie nakładania kolejnych elementów, kolejnych statystyk – przeanalizować co tam tak naprawdę się działo. Mamy pokazany filtr, który utworzył się automatycznie. Taki filtr możecie Państwo tworzyć sami. Jeżeli chcecie ograniczyć do tylko jednego adresu IP, to najprościej będzie zrobić „and” i pod prawym przyciskiem „Copy to a filter window”. Co dalej? Widzimy teraz że host, którego mamy na pierwszym miejscu, ma 25 flowów, których odpowiedź serwera była NXDomain, czyli domena nie istnieje. Chcielibyśmy zobaczyć szczegóły. O co pytał? Jak wyglądało to zapytanie? Można to zrobić na kilka sposobów. Z jednej strony możemy wybrać sobie tutaj odpowiednią statystykę i cała część DNS-owa jest tu. Proszę zobaczyć, to są wszystkie elementy związane np. z DHCP, które nasza sonda dokłada do IPFIX-a. informacje o DNS-ach to również rzeczy, które dokłada sonda, dlatego że w samym Netflow mamy najczęściej z urządzeń sieciowych tylko adresy IP i porty i niewiele więcej informacji. Z CISCO można uruchomić NBAR2, więc mamy informację jaka dokładnie została wykryta aplikacja warstwy 7., ale bez tych szczegółów. A tutaj są wszystkie elementy dodatkowe, które możemy sobie przeanalizować, zobaczyć, wyświetlić w systemie dzięki temu, że sonda utworzyła te flowy. Moglibyśmy tutaj zobaczyć jakie było „question name”, ale pokażę Państwu jeszcze inną opcję, przełączenie się na flowy. Ponieważ flowy dają nam taki bardzo fajny widok, zestawienie czy nawet możliwość utworzenia własnego zestawienia informacji o ruchu sieciowym, które chcecie oglądać. Tutaj output extended DNS mam wybrany, mamy informację o source IP, source port, czyli tu jest nasz serwer DNS, który z portu 53. przysłał odpowiedź do tego serwera. Question name wygląda tak. Wygląda na to, że są to po prostu sklejone dwa rodzaje zapytań lub rzeczywiście są niedostępne. Wygląda to jak błędy konfiguracji. I rzeczywiście odpowiedź: NXDomain. Moglibyśmy wyrzucić stąd element TCP Flags, bo ogólnie będziemy tutaj mieli jednak komunikację UDP.

Mówiłam Państwu, że bardzo łatwo można zobaczyć wydajność sieci. Przełączę się na przygotowany widok związany z komunikacją HTTP/HTTPS, bo tu na pewno będziemy mieli ruch TCP, w związku z tym te pomiary mogą być wykonane. Dla ruchu UDP wykonywane są pomiary opóźnień i w związku z tym mamy też Jitter, ale akurat dla HTTP/HTTPS mamy wszystkie RTT, SRT. To właśnie z ruchu TCP te dane się biorą. Są tu oczywiście przygotowane profile, ale takie widoki możecie tworzyć sami. Możecie mieć tutaj widok ruchu, np. komunikacji do konkretnego serwera, czy do konkretnych dwóch lub trzech serwerów. Jeżeli chcecie zobaczyć jak wyglądają parametry wydajnościowe, to pod wykresem jest taka opcja – „Change displayed channels” – i możecie włączyć „Show NPM statistics”. To są właśnie te statystyki wydajnościowe. Są one teraz włączone. Mamy tutaj ruch HTTP/HTTPS. Czy Jitter ma tutaj znaczenie jakieś dla HTTP lub HTTPS? Nie bardzo, więc od razu możemy sobie go wyłączyć. Jeżeli analizowalibyśmy VoIP-a, to jasne, ale nie w tym przypadku. W związku z tym odrzucamy tutaj Jitter żeby nam nie zaburzał. Widzimy jak wygląda Server Response Time, co więcej, jeżeli włączymy/wyłączymy sobie jedną część komunikacji – tak jak teraz oglądamy tylko HTTPS – to te metryki są tylko przeliczone dla HTTPS. Jeżeli mamy włączone oba, to są uśrednione dla obu, i HTTP i HTTPS. Jeżeli mielibyśmy tutaj jeden serwer, to widzielibyście Państwo dokładnie jak to wygląda dla konkretnego serwera. Oczywiście SRT zawsze jest nieco wyższy. Tutaj jest bardzo niewielki, bo 600 ms, więc całkiem nieźle. Włączę http, bo tu wyglądało gorzej. Tu mamy po 3-4 sekundy i tak to standardowo wygląda dla HTTP. Ale chcielibyśmy zobaczyć jeszcze RTT. Możemy znowu wyłączyć SRT i zobaczyć na jakim poziomie – 200 ms, 500 ms – to tutaj wygląda. Powiedzmy, że mamy tutaj jakiś plik. Nie jest to dużo, tu jest 200 ms, ruch jest nie tylko wewnątrz LAN, ale również komunikacja na zewnątrz, więc tu nawet dużo większe wartości mogłyby być widoczne. Oczywiście to wszystko jest kwestią konfiguracji. Normalnie w sieci analizujemy takie parametry, ograniczając się tylko do tego co mamy wewnątrz LAN. Jeżeli teraz chcielibyśmy przeanalizować sobie dla których par adresów ten RTT jest największy. Najłatwiej – można tutaj z jednej strony wykonywać ? (46:03) czyli pod prawym przyciskiem, zobaczyć sobie najpierw konwersację. Ale zrobimy inaczej, bo chodzi mi szczególnie o ten RTT, co oznacza że skasujemy filtr, który mieliśmy poprzednio bo to jest nam już niepotrzebne. Jeżeli chcemy sprawdzić gdzie jest największy RTT, to ma sens sprawdzenie tego pomiędzy dwoma adresami IP, czyli pomiędzy source IP i destination IP, bo wtedy wiemy z którego kierunku do którego mamy dużo tych retransmisji, czy właśnie wysoki RTT. Czyli sortujemy nasz widok. Wybraliśmy sobie konwersację, source IP, destination IP, sortujemy po Flowmon metryki i tutaj mamy maximal round trip time. Zobaczmy. Klikamy „Process”, żeby nam się to przetworzyło i zobaczymy dla których par adresów jest on największy. 23 sekundy, ale widać że to jest wyjście gdzieś tam na publiczny adres, więc tak jak powiedziałam – w świecie może to być dużo więcej. Normalnie interesuje nas tylko komunikacja wewnętrzna, zawsze możemy to ograniczyć do destination network np. tutaj są 10. Nie wiem czy będzie coś w 10, możemy sprawdzić. I mamy. Tam gdzie są niepomierzone, niepoliczone, to są konwersacje, ale bez RTT, bo prawdopodobnie serwer jest po tej stronie, a tu jest klient. Zawsze RTT jest liczony w kierunku od klienta do serwera. W związku z tym mamy tutaj dwa pomiary wewnątrz naszej sieci prywatnej, czyli wewnątrz LAN. 0,3 ms, super, nie ma się do czego przyczepić. Taki widok można przygotować na dashboard, parę adresów z najdłuższym RTT wewnątrz naszej sieci LAN. Gotowe, nie musimy tego szukać, nie musimy tego analizować, nie musimy przeglądać dalej co się dzieje, widzimy od razu gotowe wyniki. Pokażę jeszcze jak możemy sobie ewentualnie przeanalizować jakiś plik, bo mamy tutaj wzrost komunikacji HTTPS. Jeżeli chcemy po prostu zobaczyć pomiędzy jakimi adresami IP to występowało, to wystarczy że pod prawym przyciskiem wybierzemy conversation IP – IP. Oczywiście moglibyśmy wybrać conversation IP port – IP port, wtedy wiedzielibyśmy po której stronie jest serwer, a po której klient. W każdej chwili można to zmienić. Widać że na pierwszym miejscu mamy właśnie tę komunikację. Można sobie zmienić widok, żeby zobaczyć jak to w czasie wyglądało, jak się rozkładało.

Q&A

D: Czy można przetestować sondę?

K: Sondę jak najbardziej można przetestować. Do testów najlepiej przygotować się w ten sposób, że wybieramy najpierw co jest nam potrzebne. Jeżeli chcemy koniecznie sondę, bo chcemy zobaczyć te wszystkie dodatkowe elementy i wykonać pomiary wydajności sieci, to możemy podejść z sondą fizyczną. Sondę fizyczną dobieramy w zależności od tego gdzie ją chcemy podłączyć. Najczęściej mamy w swoim sprzęcie demo, możliwość wypożyczenia sondy z interfejsami 1 Gb jak i z interfejsami 10 Gb, bo te są najczęściej wykorzystywane. Prosimy więc o informację do EXATELA i będziemy wtedy ustalać termin, kiedy sondy będą wolne i będzie je można wykorzystać. Zawsze do pary z sondą dostawiamy kolektor. Może to być kolektor hardware’owy i jest to sprzęt, który możemy jak najbardziej wypożyczyć. Dużo łatwiej będzie pewnie postawić kolektor wirtualny. Jeżeli więc ktoś ma taką możliwość, to zachęcam do skorzystania właśnie z opcji postawienia kolektora wirtualnego. Dodam że kolektor wirtualny jest takim 2 w 1, czyli jest kolektorem i sondą (od razu ma dwa interfejsy monitorujące sondy i to dotyczy tylko kolektora wirtualnego), ponieważ założenie jest takie, że skoro stoi już w tym środowisku wirtualnym, to może przy okazji monitorować je. Możemy więc podłączyć te porty monitorujące i w ten sposób na jednej maszynie wirtualnej, testujemy zarówno funkcjonalność sondy, jak i wszystkie opcje które są dostępne na kolektorze, bo tutaj nie ma żadnych ograniczeń. Oczywiście licencje które dostarczamy, nie mają ograniczeń wydajnościowych, a jedynie ograniczenia czasowe.

D: Czy mechanizm uczy się zachowań użytkowników w sieci?

K: To nie jest analiza UEBA – czyli nie polega na analizie zachowania użytkowników – tylko analiza NBA (Network Behavior Analysis), co oznacza że nie mamy tu konkretnie użytkowników, ale rozróżnienie pomiędzy hosty, serwery, różne rodzaje usług. Hosty tutaj są traktowane może nie wszystkie jednakowo, ale na tej zasadzie, że nie jest to rozróżnione na konkretnego użytkownika, a raczej na konkretny adres IP. W tym naszym systemie NBA, czyli w Anomaly Detection System, jest zastosowanych kilka mechanizmów. Z jednej strony jest to machine learning, który też uczy się zachowania, ilości transakcji, ilości połączeń i komunikacji w sieci i na tej zasadzie raportuje wszystkie odchylenia, nietypowe zachowania, połączenia na nowe porty, ale są też wprowadzane na początku do tego systemu informacje związane z naszą siecią, więc od razu też raportuje. Jest to system, który uruchamiamy, wstępnie konfigurujemy i on od razu po wystartowaniu pokazuje nam część niezgodności, czyli część informacji, które są niezgodne z tym, co wprowadziliśmy i jest podejrzane od samego początku. Od momentu uruchomienia mamy już wykryte jakieś anomalie, które możemy analizować. Na testy w zupełności wystarczą dwa tygodnie i nie ma potrzeby żeby trwały dłużej, tym bardziej że zwykle w ciągu dwóch tygodni, jest wystarczająco dużo ciekawostek wykrytych przez taki system, żeby było się czym zająć.