Webinar – Monitorowanie ruchu szyfrowanego

Dawid Zięcina:

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

Klaudyna Busza-Kujawska:

Dzień dobry.

Dawid:

Wspólnie z Klaudyną przestawimy dziś Państwu narzędzie, które umożliwia monitorowanie ruchu HTTPS bez deszyfracji. Zanim przejdziemy do głównej części webinaru, pozwolę sobie przedstawić Państwu kilka informacji na temat naszej firmy. EXATEL jest spółką akcyjną będącą własnością Skarbu Państwa i podlegamy pod MON. Na rynku usług telekomunikacyjnych jesteśmy od ponad 20 lat. To co wyróżnia nas na rynku od samego początku, to sposób w jaki podchodzimy do kwestii związanych z bezpieczeństwem informacji. Dlatego naszym mottem jest to, że mamy najbezpieczniejszą sieć w kraju. System który opracowaliśmy polega na tym, że mamy trzy dedykowane działy – dział obsługi sieci (NOC), Biuro Obsługi Klienta (BOK) i dodatkowo w strukturach naszej firmy działa wyspecjalizowana komórka cyberbezpieczeństwa, która prowadzi Security Operations Center. Z racji tego że bardzo poważnie podchodzimy do kwestii związanych z bezpieczeństwem, możemy pochwalić się też tym, że posiadamy świadectwa bezpieczeństwa przemysłowego pierwszego stopnia o klauzuli ściśle tajne oraz UE Secret i NATO Secret. Posiadamy także certyfikaty ISO 27001 oraz 22301. Naszym głównym polem działania od zawsze była telekomunikacja. Mamy ponad 20 tysięcy kilometrów własnej sieci światłowodowej na terenie całego kraju, dzięki czemu bardzo sprawnie możemy dostarczyć Państwu usługi transmisji danych, Internet, sieci korporacyjne czy też telefonię IP w dowolnym miejscu kraju. Mamy redundantne połączenia międzynarodowe, a ostatnio uruchomiliśmy dodatkową, niezależną fizyczną ścieżkę do wyjścia przez Frankfurt. Zapewniamy także bezpieczeństwo sieci naszych klientów. Przejawia się to w tym, że mamy bardzo wysokie gwarantowane SLA i monitorujemy zasoby naszej sieci i usług, które świadczymy klientom w systemie 24/7/365.

Coraz więcej firm na rynku chwali się tym, że ma spore doświadczenie w zakresie cyberbezpieczeństwa. Wyprzedzając konkurencję, już kilka lat temu stworzyliśmy struktury w departamencie cyberbezpieczeństwa i świadczymy na rynku nasze usługi. Poza zespołami stale monitorującymi zagrożenia w sieci, mamy ekspertów z departamentu cyberbezpieczeństwa, którzy świadczą takie usługi jak ochrona przed atakami DDoS, Managed Firewall, usługi doradztwa bezpieczeństwa IT, w tym testy penetracyjne aplikacji i sieci, inżynierię wsteczną oprogramowania, bezpieczeństwo systemów operacyjnych i baz danych. Nasi eksperci mogą pochwalić się bardzo bogatą listą cennych na rynku certyfikatów, co potwierdza kompetencje i umiejętności naszego zespołu. Sam zespół i doświadczenie, to jednak nie wszystko. Dlatego stawiamy na zaufanych partnerów technologicznych. To co w zakresie technologii i rozwiązań proponujemy naszym klientom, w pierwszym etapie jest testowane przez nas. My także korzystamy z tych rozwiązań, wobec czego w prosty sposób jesteśmy w stanie przeciwdziałać pewnym zagrożeniom wynikającym z danej technologii i adaptować technologie do rozwiązań w już istniejących infrastrukturach klientów. Jednym z naszych wiodących partnerów, jest firma Flowmon.

Co powoduje, że warto przenieść się ze standardowego ruchu HTTP na zabezpieczony ruch HTTPS? Pod kątem bezpieczeństwa – jeżeli mówimy o trójkącie CIA (Confidentiality, Integrity, Availabilty), na którym bazuje całe bezpieczeństwo – HTTPS gwarantuje nam integralność i poufność danych. Informacje są trudniejsze do przechwycenia, nie mamy tego elementu dostępności, natomiast samo środowisko w którym działa HTTPS, nie gwarantuje takiego elementu (mechanizmu). Co ciekawe, dynamiczny wzrost ruchu HTTPS w sieci, nastąpił po roku 2014, kiedy to Google zaproponowało że będzie to dodatkowo punktowało w rankingu witryn, które działają w oparciu o protokół HTTPS. Wtedy to ruszyło całe SEO i zaczęto pozycjonować swoje strony w taki sposób, aby te dodatkowe punkty przechwycić i wyprzedzić konkurencję. Tutaj slajd prezentujący jak ruch HTTPS dynamicznie rośnie. Są to dane w ujęciu o statystyki Google’a i przeglądarki Chrome. Widać, że jeszcze parę lat temu był to ruch poniżej 50%, a obecnie zbliżamy się do granicy 90%. Dane statystyczne na nasz kraj mówią o tym, że w tej chwili ruch HTTPS przekroczył już ponad 70% całego ruchu w sieci, więc ten wolumen jest coraz większy.

Często gdy rozmawiamy z klientami, pytamy w jaki sposób mają zabezpieczoną swoją sieć i na co zwracają uwagę. Pokazują wtedy swoje technologie i rozwiązania, a my mówimy: a jak sprawdzacie HTTPS? Mówią wtedy: nie sprawdzamy. Czyli maja poważną lukę i nie wiedzą co tam się dzieje. Dlaczego nie sprawdzają? Bo nie chcą deszyfrować tego ruchu i być posądzani, że patrzą np. w dane, które ich pracownicy mogą przesyłać do banków. Oczywiście najprościej jest nie robić tego w trakcie pracy, natomiast wiadomo, że nie można tego w 100% wykluczyć. Jeżeli ktoś nie chce w 100% deszyfrować tego ruchu, bo nie chce tego robić z zasady, albo ze względów budżetowych nie chce inwestować w platformę do deszyfracji, to można się zastanowić co możemy zobaczyć nie inwestując w takie rozwiązania, albo nie podejmując decyzji o podglądaniu co się dzieje w ruchu szyfrowanym, który wysyłany jest przez naszych użytkowników/pracowników do sieci. Jak przyjrzymy się w jaki sposób działa HTTPS, to mamy tam element, kiedy nawiązywane jest połączenie od klienta do serwera, kiedy klient przedstawia się serwerowi, podaje informacje jakie metody szyfrowania obsługuje i serwer (jeżeli ma dopuszczone te parametry) odpowiada klientowi podsyłając mu automatycznie certyfikat. Klient odpowiada, następuje ustalenie klucza i przechodzimy wtedy już do części zaszyfrowanej. Jak widać mamy kilka elementów, którym można się przyglądać, nie naruszając w specjalny sposób poufności danych, które mogą się tam znajdować. Wyobraźmy sobie teraz, że jeżeli pomiędzy klientem i serwerem ustawimy wyspecjalizowane urządzenie, które będzie nasłuchiwało w jaki sposób ta nieszyfrowana część rozmowy się odbywa, to możemy tam wychwycić kilka ciekawych elementów. Rozwiązanie firmy Flowmon działa w taki sposób, że ma wgląd w metadane. Na bazie metadanych generowany jest flow, który następnie jest przetwarzany przez inteligencję zaszytą na tej platformie. Przetwarzanie przez Flowmona bazuje na analityce zachowania się sieci, czyli Network Behavior Analysis (NBA). Tutaj taki bardziej przybliżony schemat w jaki sposób to działa. Bazujemy w zasadzie na pięciu kluczowych elementach, które mogą być rozszerzone w zależności od tego jakie flowy otrzymujemy. Podstawowa informacja to adres źródłowy docelowy, port źródłowy docelowy i protokół dostępny w trakcie komunikacji.

Poza tymi zaletami, HTTPS gwarantuje poufność oraz integralność danych i że są one zaszyfrowane, a osoba z zewnątrz nie jest w stanie zajrzeć do tego co tam jest, to dla osób, które zajmują się bezpieczeństwem, przysparza pewnych kłopotów, bo nie wiemy i z założenia nie mamy wiedzieć co tam jest. Jak HTTPS może utrudnić życie zwykłego administratora sieci? Przytoczę tutaj historię z mojego wczesnego życia związanego z sieciami komputerowymi. Otóż okazało się, że w dużej korporacji spora część ruchu generowanego przez użytkowników to Bittorrent. Gdy szefostwo zostało o tym poinformowane, wpadło na pomysł, by zakazać używania takiej aplikacji. Zakaz został wydany oczywiście bez rezultatu i dalej ruch był na takim samym poziomie. Jeden z szefów zaczął więc ostro googlować na ten temat i dostałem przykaz by zablokować wszystkie porty w UDP od 1014 do 65534. Świetny pomysł, Bittorrent przestałby działać, a przy okazji parę innych aplikacji. Poczytałem trochę na ten temat i znalazłem informację, że wystarczy zablokować porty na których agent Bittorrenta standardowo działa. Okazało się jednak, że po zablokowaniu tych portów, Bittorrent przerzucił się na legalny ruch 8080 (Proxy) i 80 (TCP). Podszedłem więc ambitnie do tematu i zacząłem szukać w jaki sposób mogę znaleźć ten ruch na porcie 80. Wystartował tcpdump, czyli sniffer. Wystartował skrypt, który szukał stringów związanych z nawiązaniem sesji, czyli GET i tam szukałem sobie specyficznych informacji, które agent Bittorrentowy wysyła do serwera. Działało to przez chwilę, dopóki użytkownicy (którzy pewnie czytali ten sam poradnik i znaleźli tę wskazówkę) nie zorientowali się, że można to sobie nakryć SSL-em, przejść na HTTPS i wtedy wyszukiwanie GET bez elementów deszyfracji (czyli tak naprawdę bez deszyfratora) na nic się zda. Tak też się stało i ja już tego ruchu nie widziałem, natomiast wolumen danych nie zmalał w stosunku do tego zanim zostały wprowadzone te obostrzenia. Jedyne rzeczą, którą pozostało mi zrobić, było nałożenie limitu na ilość jednocześnie nawiązywanych sesji, co skutkowało sporą ilością telefonów od niezadowolonych użytkowników innych aplikacji, które czasami przestawały działać, albo działały w dziwny sposób. Po tej całej historii zacząłem się zastanawiać i zadawać pytania bardziej doświadczonym kolegom: skoro nie jesteśmy sobie w stanie poradzić z Bittorrentem i użytkownicy są w stanie ukryć przed nami ten ruch, to co jeszcze są w stanie ukryć? Z racji tego, że byłem po stronie administratora sieci IT, a nie bezpiecznika, to generalnie po zadaniu tego pytania i braku odpowiedzi zwrotnej (bo nie wiedzieli), przestało mnie to interesować. Dzisiaj jednak mógłbym spróbować zadać to samo pytanie: czy za pomocą urządzenia dedykowanego, np. Flowmona, jesteśmy w stanie zidentyfikować np. Bittorrenta? Jeżeli tak, to w jaki sposób? Czy jestem w stanie zidentyfikować inny ruch, który może budzić nasze podejrzenia i jest zaszyty pod HTTPS? To pytanie kieruję do Klaudyny. Zademonstruj proszę w jaki sposób możemy sobie z tym poradzić.

Klaudyna:

Jak najbardziej możemy tutaj coś zdziałać. Trzeba zwrócić uwagę na to, w jaki sposób zachowują się hosty, które korzystają z Bittorrenta. Korzystają one z tych dziwnych portów. Może też być 443, może być 80, może być szyfrowany ruch. Nie zajrzymy więc do środka, nie zobaczymy URL-i, ale za to będzie bardzo dużo połączeń wychodzących na zewnątrz do różnych krajów świata. Dodatkowo część z tych zapytań będzie bez odpowiedzi, bo to wszystko zależy od tego czy po drugiej stronie mamy użytkownika od którego można pobrać w danym momencie jakiś fragment czy nie. W związku z tym zachowanie takiego hosta w sieci będzie dosyć specyficzne. Do wykrywania różnych podejrzanych zachowań, służy nam właśnie analiza behawioralna, czyli analiza zachowania hostów w sieci. Nie interesuje nas tutaj czy ruch jest szyfrowany czy nie. Nie ważne czy to HTTPS czy jakikolwiek inny ruch (np. SSH), ważne jest to jak host się zachowuje, z kim się łączy, jak wyglądają wysyłane pakiety, ich wielkość, częstotliwość ich wysyłania, obie strony komunikacji. Istotne jest, że żeby wykorzystać taką analizę behawioralną, nie potrzebujecie Państwo wstawiać jakichś kolejnych elementów, konkretnych sond DPI do swojej sieci. Możecie wykorzystać te urządzenia, które już posiadacie w sieci, tzn. routery, switche, które są w stanie dostarczyć nam Netflow w jakiejś formie. Może to być Netflow w wersji 9, 5, IPFIX – czyli najnowsza i ustandaryzowana wersja Netflow – może to być JFlow lub Netstream. Wystarczy sprawdzić czy urządzenia sieciowe które Państwo posiadacie, mają możliwość skonfigurowania i uruchomienia takiej funkcjonalności. Wówczas bazując na tych danych, możemy wykonać analizę behawioralną.

Pokażę jak to wygląda u nas. Zobaczmy np. tego Bittorrenta. Wygląda to w ten sposób, że zachowanie hosta, który próbował gdzieś niecnie wykorzystać nasze zasoby firmowe – w postaci Internetu do pobrania jakichś elementów typu filmy – wygląda tak, że zachowanie takiego hosta jest klasyfikowane jako komunikacja typu Bittorrent z różnymi dwudziestomasześcioma hostami. Jak widać była to komunikacja z różnych krajów. Jeżeli chcemy zobaczyć dokładnie jak to wyglądało flow po flow’le, to zobaczycie Państwo: tutaj mamy Source, Port Destination, to też jest na różnych rodzajach portów. Pojawi się tutaj różnego rodzaju komunikacja. Czasami jest brak komunikacji, albo jest dużo zapytań, tak jak w tym miejscu, wychodzących tylko z naszego hosta wewnątrz sieci, a odpowiedzi po drugiej stronie. Sklasyfikowane to rzeczywiście zostało jako komunikacja z Bittorrentem. Ale nie jest to jedyne podejrzane zachowanie, które przy analizie ruchu (HTTPS lub jakiegokolwiek innego) może zostać wykryte. Przy HTTPS akurat, bardzo częstą anomalią lub podejrzanym zachowaniem jest DIVCOM – tak u nas nazywa się metoda wykrywająca te zdarzenia – Diversity of Communication. Pokazuje nam ona, że host zachowuje się w dziwny sposób. Mamy tutaj hosta z wewnątrz LAN-u, który komunikuje się z wieloma adresami IP na różnych portach. Będzie tu m.in. port 80, 443 i inne porty. Możemy zobaczyć z iloma krajami i iloma różnymi adresami IP komunikuje się ten host. Mamy tutaj jakiegoś podejrzanego użytkownika, któremu możemy się dalej przyglądać, co on jeszcze takiego robi i czy może jakieś podobne lub innego rodzaju zdarzenia możemy zaobserwować właśnie dla tego konkretnego adresu. Mamy tutaj jeszcze jakieś dodatkowe anomalie związane z nadmiarową komunikacją. Także mamy tu na pewno przypadek, któremu warto się przyjrzeć i przeanalizować dokładniej co on takiego robi i jakie aplikacje są zainstalowane na takim hoście. I to wszystko bazując nawet na samych flowach urządzeń sieciowych.

Dawid:

Gdybym miał wcześniej takie narzędzie, to pewnie nie musiał bym wtedy tyle kombinować. Wracając do kwestii związanych z ruchem HTTPS. Co to jest Secure, jak to działa? Generalnie webinar nie jest poświęcony temu, żeby analizować w jaki sposób to działa, natomiast warto przyjrzeć się temu co sprawia, że ten HTTPS w ogóle działa, czyli jaki tam protokół jest zaszyty. SSL/TLS, jak każdy protokół zawiera zestaw instrukcji i wskazówek w jaki sposób dba o urządzenia, które obsługują ten sam protokół i mają ze sobą rozmawiać. W dużym uproszczeniu i nie wchodząc w obszar matematyki, krzywych eliptycznych i dlaczego tak, a nie inaczej… Dla niektórych rzeczy które teraz powiem, mogą wydać się wręcz banalne, ale chcę je zaznaczyć, by za chwilę móc zobaczyć w jaki sposób Flowmon może nam pomóc w codziennej pracy, jeżeli chodzi o analizę ruchu HTTPS. Co z tym SSL-em, po co on w ogóle jest? Protokół ten ma zapewniać bezpieczeństwo połączenia sieci, czyli ten SSL/TLS nałożony na HTTP, powoduje że mamy te „S” na końcu. Protokół ten znajduje się pomiędzy warstwą TCP, a warstwą aplikacji, co powoduje, że jest on w sieci tak naprawdę przezroczysty. Opiera się on całkowicie na protokołach połączeniowych, co powoduje kompletność transmisji. Mamy pod tym TCP, które dba, żeby ta kompletność następowała.

W przypadku gdy mówimy o HTTPS, to jest to komunikacja SSL-owa. Za chwilę pokażę, że już tak naprawdę w tej chwili jest to głównie TLS, a za chwilę będzie tylko i wyłącznie TLS. TLS, który został wprowadzony zastępując SSL-a, ma zapewnić uwierzytelnienie, czyli element autentykacji oparty na certyfikatach. Komunikaty są podpisywane i przesyłane wraz z certyfikatem strony. SSL/TLS jest protokołem typu klient-serwer, czyli to zawsze agent klienta nawiązuje połączenie do serwera.

Rys historyczny SSL-a:

W 1994 roku pojawił się pomysł żeby to wprowadzić (SSL 1), ale był on na tyle nieudolny, że pierwsza dostępna wersja SSL-a to jest wersja nr. 2, która powstała w 1995 roku. Była ona wykorzystywana na początku praktycznie tylko przez ośrodki akademickie. W 1996 roku nastąpił rozwój, poprawiono SSL o kilka elementów związanych z podatnością na ataki. Na dzień dzisiejszy, zarówno SSL 2 i SSL 3 są uznawane za wycofane i nie należy ich już używać. Generalnie jeżeli 2. czy 3. pojawią się gdzieś w sieci, to przeglądarki od razu zgłaszają, że z tą stroną nie można się połączyć, ponieważ jest ona niebezpieczna. Poprawka SSL 3, czyli nieoficjalny standard 3.1 to jest już rok 1999. Tutaj pierwszy raz pojawia się TLS w wersji 1.0, który żyje sobie spokojnie przez kolejne 7 lat i dopiero w 2006 znowu zostaje dodanych kilka poprawek i uwaga – TLS 1 i 1.1 w 2020 roku zostają wygaszone i uznane za nieaktualne. Pozostaje nam TLS 1.2 od roku 2008, które wykorzystuje szyfrowanie SHA o kluczu długości 256 bitów.

Najnowszą, obowiązującą od 2018 roku wersją, jest TLS 1.3, który jest uznawany w tej chwili jako standard jeżeli chodzi o protokół HTTPS. Dlaczego te protokoły były zmieniane i co się tam działo? Generalnie za każdym razem kiedy ten protokół był skompromitowany i zostały wskazane pewne podatności, dzięki którym można było naruszyć bezpieczeństwo transmisji danych, były opracowywane poprawki i wypuszczana nowa wersja protokołu. Najbardziej znane podatności na protokół SSL, to jest BEAST, POODLE i CRIME. Czy dzięki rozwiązaniom takim jak te od firmy Flowmon, możemy dokładniej przyglądać się w jaki sposób protokół, który ma nam zagwarantować poufność i integralność danych w ruchu HTTP, może być weryfikowany?

Klaudyna:

Jak najbardziej. Na początku Dawid opowiedział o tym jak wygląda zestawienie tego połączenia szyfrowanego. Najpierw mamy zestawienie połączenia TCP, a później zestawienie połączenia szyfrowanego, a więc ustalenie po stronie klienta, serwera, w jaki sposób mogą zaszyfrować dalszą komunikację. Ta część dogadywania się pomiędzy klientem a serwerem, jest częścią nieszyfrowaną, którą możemy analizować, mamy w nią wgląd. Oczywiście dalej już jeżeli dane są zaszyfrowane, to rzeczywiście do analizy tych informacji byłby potrzebny deszyfrator, by zobaczyć co jest w środku. Jeżeli natomiast opieramy się tutaj na nieszyfrowanej analizie, ale sprawdzeniu co jest możliwe pod kątem widoczności w HTTPS, to właśnie m.in. zweryfikowanie jaką wersję nasze serwery firmowe wykorzystują, czy na pewno wszędzie jest TLS w wersji 2 czy może pojawia się gdzieś komunikacja niższa, słabsza, jeżeli klient wymusi zestawienie takiego połączenia.

W jaki sposób na Flowmonie możemy sprawdzić taką komunikację? Zacznę może od prostego zweryfikowania, jakiego rodzaju jest widoczna komunikacja i jakie wersje protokołu TLS są wykorzystywane w sieci. W związku z tym włączę tylko HTTPS. Weźmy tutaj jakiś przedział czasu, w którym troszeczkę danych zostało przesłanych. Co możemy dalej zrobić? Możemy sprawdzić TLS Server Version. Zobaczmy co nam się pojawi. Dużo komunikacji typu N/A. Dlaczego? Bo w trakcie zestawienia połączenia HTTPS, możemy wyciągnąć dodatkowe informacje o certyfikatach, o serwerze, o kliencie, bo tam występuje ta wymiana. Cała reszta komunikacji jest dla nas zaszyfrowana, więc tutaj oczywiście wpada nam wszystko to, czego już nie widzimy. To co jest dla nas najistotniejsze, z samego początku połączenia mamy tutaj. Widać więc, że jest TLS 1.2, ale jest też wykorzystywany 1.0. Co dalej? Możemy zobaczyć np. komunikację – jakie adresy, które hosty rozmawiały z jakimi serwerami, żeby przede wszystkim zidentyfikować właśnie potencjalnego kandydata na aktualizację. Możemy więc wybrać statystykę pod tytułem konwersacje IP port – IP port. Proszę zobaczyć, w tym miejscu wyfiltrował mi się TLS 1.0, ponieważ właśnie na niego kliknęłam i mamy teraz zestawione połączenia, które hosty, które serwery, wiemy dokładnie gdzie jest klient i gdzie jest serwer, bo mamy Source Port Destination, które nam w tej komunikacji się pojawiają. Oczywiście nie musimy tego robić. Teraz działa to na zasadzie „sprawdźmy co widać w naszej sieci”, natomiast na stałe możemy ustawić konkretny widok, np. jako zestawienie TLS po stronie klienta, TLS po stronie serwera i rzeczywiście możemy ograniczyć to do naszej sieci prywatnej, czyli ograniczyć do adresacji prywatnej, albo wybierając tylko VLAN w którym będą nasze serwery. Z drugiej strony jeszcze jedno zestawienie, które też może być bardzo interesujące, ponieważ możemy mieć taki dashboard na co dzień wyświetlony i weryfikować czy coś się tutaj nowego pojawia, czy coś może zniknęło lub pojawiło się dodatkowego, np. adresy IP i Server Name, czyli SN wyciągnięte już z certyfikatu. Jako wspólne zestawienie dokładnie wiemy kogo to dotyczy, co to za usługa i co należy sprawdzić, poprawić czy zmienić. Mamy tu oczywiście jakieś publiczne hosty żeby można było cokolwiek pokazać, natomiast ma to sens by analizować to wewnątrz własnej sieci LAN. Oczywiście możemy też ustawić alert, żeby mieć informacje o tym, jeżeli pojawi się taka komunikacja w sieci. To też jest możliwe.

Dawid:

Chciałem teraz Państwu wspomnieć słówko o tym, co jest sednem całego HTTPS-a, czyli o szyfrowaniu. Nie będziemy sięgać do matematyki i mówić dlaczego pewne dowody matematyczne mówią o tym, że jedno szyfrowanie jest słabsze od drugiego. Generalnie każdy wie o co w tym wszystkim chodzi. Natomiast pod kątem Flowmona i tego co można robić przy weryfikacji tego w jaki sposób jest transmisja szyfrowana, chciałbym pokazać taki slajd, gdzie to szyfrowanie jest pokazane na samym dole. To co mówiliśmy wcześniej – są pewne informacje w ruchu HTTPS na początku otwarte, gdzie strona klienta dogaduje się z serwerem. To zapytanie ze strony agenta/klienta wygląda mniej więcej w taki sposób, że agent przedstawia się serwerowi mówiąc „cześć, jestem taki i taki, mówię takim językiem, czy ty również mówisz tym językiem?” Ewentualnie klient może powiedzieć, że mówi kilkoma językami i zapytać serwer czy tymi językami także włada. W zależności od konfiguracji, serwer może albo narzucić klientowi że mówi w konkretnym języku i dogadają się między sobą, albo powiedzieć, że nie rozumie w ogóle tego co do niego mówisz, on rozmawiam w jednym konkretnym języku, którego ty w ogóle nie rozumiesz. Może być tak jeżeli sobie obostrzymy po stronie serwera, że akceptuje tylko i wyłącznie zapytania ze strony klientów oznaczone protokołem TLS 1.3, wykorzystującym odpowiednią długość klucza. Jeżeli klient nie spełni tego wymogu, to pokaże nam się po prostu informacja, że ta strona nie może zostać wyświetlona. Jeżeli więc chcemy być bardzo bezpieczni, to prowadząc jakiś serwis WWW, możemy odciąć całkiem sporą rzeszę naszych użytkowników. Jeżeli mówimy o tym szyfrowaniu na samym dole, to warto mu się przyglądać z punktu widzenia nas jako ludzi od bezpieczeństwa sieci czy też po prostu administratorów sieci. To szyfrowanie jest dla nas istotne pod kątem zgodności z polityką bezpieczeństwa. Jeżeli mamy standardy bezpieczeństwa i opracowaną politykę w której jest zdefiniowane jaką długość klucza można używać, w jaki sposób szyfrowanie ma następować jeżeli chodzi o ruch HTTPS, to powinniśmy weryfikować czy nie ma aby od tego odstępstw. Może też nastąpić jakaś anomalia. Jeżeli strony uzgodnią pewną wersję i nagle klient mówi „słuchaj, to gadamy w jakimś prymitywnym języku” i tutaj następuje taka anomalia, warto byłoby też odpowiedzieć że coś takiego nastąpiło bądź występuje regularnie w naszej sieci. Warto też sprawdzać czy klucze, które są używane, zestawy kryptograficzne, ta matematyka, która jest podszyta w ruchu HTTPS-owym, nie jest uznana już jako łatwa do złamania. Czyli mówimy tutaj o algorytmach szyfrowania, o długości klucza. Uznanym już np. za nieaktualny czy też łatwy do złamania, jest klucz SHA1, który nie jest wspierany przez najnowsze przeglądarki. Pojawia się już informacja, że strona jest niezabezpieczona i zamiast tej zamkniętej zielonej kłódki, może pojawić się informacja o tym, że coś jest nie tak z tym ruchem.

Czy możemy obserwować jak to szyfrowanie wygląda w przypadku ruchu HTTPS? Czy możemy wychwytywać pewne anomalie, które mogą stanowić dla nas pewne ryzyko?

Klaudyna:

Oczywiście możemy analizować, podobnie jak analizowałam przed momentem wersje TLS, które się tutaj wyświetlają. Możemy wybrać po prostu kolejny element, który jest np. związany właśnie z tym kluczem publicznym czy długością klucza. Natomiast chciałabym Państwu pokazać coś innego, bo nie będziemy za każdym razem wykonywać tej samej akcji. Na pewno łatwiej będzie nam utworzyć taki widok, wrzucić go na dashboard i mieć tam podsumowanie związane właśnie z tym, jakie elementy lub jaki rodzaj szyfrowania jest wykorzystywany w naszej sieci. Pokażę więc jak można stworzyć szybko taki widok. Mamy tutaj już utworzony ruch HTTP, ale nas interesuje tylko HTTPS. Co robimy dalej? Wybieramy elementy, które chcemy żeby były wyświetlone w naszej tabeli, w naszym podsumowaniu. Sprawdzamy gdzie tutaj jest nasze całe TLS-owe i możemy np. wszystko co będzie związane właśnie z rodzajem szyfrowania umieścić w jednym miejscu, możemy jeszcze dodać trochę N/A związanego z tą komunikacją, która jest po zaszyfrowaniu. Żeby to odfiltrować, wyświetlimy sobie wszystkie elementy, gdzie np. jakiś element już był. Wystarczy w ten sposób ?(39:33-39:45) powinniśmy w ten sposób się pozbyć wszystkich N/A. Wykonamy jeszcze jedną akcję, przeliczenie żebyśmy zaraz zobaczyli na naszym wykresie odpowiednie elementy. Możemy jeszcze wybrać sobie takie zestawienie, gdzie będziemy widzieć nasze zestawienie posortowane po flowach, czyli tak naprawdę stała komunikacja od tej do której najwięcej połączeń tego typu było. Oczywiście tutaj jeszcze moglibyśmy dodać np. ograniczenie DST Network i np. w ten sposób, natomiast wiem, że jeżeli zostawię to w takim układzie, to nie zobaczymy za dużo na naszym zestawieniu, które chcemy Państwu pokazać. Zobaczmy jak to wygląda dla komunikacji publicznej, czyli adresów wewnątrz sieci. Mamy utworzony nasz wykres. Możemy go teraz dodać, tu mamy TLS, dodajmy sobie nowy widok w tym miejscu. I to był TLS, bodajże ten z ostatniej godziny. Wyświetlimy tylko tabelkę i klikam Save. Przesuniemy sobie w inne miejsce żeby było lepiej widać. I proszę, mieliśmy tam 10, ale widać wystarczyło, bo tylko 5 zestawów nam się pojawiło. Mamy tutaj dokładnie jaki algorytm klucza, mamy też długość tego klucza, więc możemy w ten sposób zweryfikować. Jeżeli chcemy zobaczyć które hosty i kto tutaj akurat wykorzystuje dokładnie ten rodzaj szyfrowania, to przechodzimy dalej do analizy podobnie jak poprzednio.

Dawid:

Dziękuję. Certyfikat. O co chodzi w tej całej wymianie kluczy? Co gwarantuje, że w ogóle ta transmisja szyfrowana się udaje? Skąd wiadomo w jaki sposób ten zaszyfrowany ciąg danych zostaje deszyfrowany po jednej stronie, czy też po drugiej stronie. Dużo można by na ten temat powiedzieć. Generalnie to co warto mieć na uwadze, to zasadność po co nam te certyfikaty. Certyfikat spełni dwie funkcje – szyfrowanie i autentykację. Potwierdza nam to, że łącząc się z danym adresem, rzeczywiście z tym adresem się połączyliśmy. Dajmy na to łącząc się pod adresem HTTPS exatel.pl, chcemy mieć pewność, że połączyliśmy się z witryną exatel.pl i to dla tej witryny został wystawiony certyfikat. Z samym szyfrowaniem to jest tak, że trzeba się zastanowić w jaki sposób klient i serwer mają się dogadywać, w jaki sposób to deszyfrować. Mamy więc ten klucz prywatny, którym szyfrujemy certyfikat i czy przekazać teraz klientowi ten klucz prywatny, po to żeby mógł on deszyfrować sobie ten ruch? W drugą stronę – czy zmusić klienta do tego żeby on miał swój klucz którym będzie szyfrował dane i żeby przekazał nam ten klucz? Podejrzewam, że w momencie kiedy użytkownik zobaczyłby że musi generować jakiś klucz po to, żeby połączyć się ze stroną exatel.pl, to stwierdziłby że niestety, ale nie ma czasu. Więc generalnie te certyfikaty są istotne po to, żeby osiągnąć te dwa cele. Ale po co w ogóle je śledzić? Przecież certyfikat jest podpisywany, są instytucje, które zajmują się tym żeby certyfikat był wiarygodny i rzeczywiście potwierdzał bezpieczeństwo tej witryny. Wtrącę tylko, że certyfikat nie daje bezpieczeństwa samego serwera, bo nie jesteśmy w stanie uchronić serwera przed atakami, jeżeli mamy certyfikat. To nie działa w ten sposób, natomiast to co powinniśmy weryfikować, to kto podpisał ten certyfikat, jaka instytucja, jaka instancja potwierdza że ten certyfikat jest ważny? Dla kogo został wystawiony i kiedy on wygasa? Łatwo sobie wyobrazić, że możemy mieć nieaktywny certyfikat, który jest prawidłowym certyfikatem, wystawionym na prawidłowego odbiorcę, natomiast jest nieważny. I teraz można sprawdzać po kolei na każdym komputerze czy te certyfikaty w magazynie są okej, natomiast jest to założenie utopijne, więc lepiej patrzeć jakie certyfikaty po sieci sobie latają. W jaki sposób możemy to zrobić za pomocą narzędzia Flowmon?

Klaudyna:

To jest bardzo ciekawy temat i bardzo dużo możemy tutaj poobserwować. Chcemy np. zobaczyć czy jakiś z serwerów ma podpisany certyfikat przez Let’s Encrypt i możemy to zrobić. Sprawdźmy najpierw czy gdzieś na pierwszym miejscu pojawi się ten Let’s Encrypt w zestawieniu naszych top. Nie ma. Mamy tutaj bardzo dużo przez Google, DigiCert, GeoTrust, Microsoft, więc mamy tutaj informację przez kogo zostały wystawione/podpisane certyfikaty. Ale jeżeli chcielibyśmy znaleźć jakieś konkretne, np.  właśnie Let’s Encrypt, to wpisujemy TLS w filtrze i mamy w podpowiedziach wszystkie inne elementy, które mogą być wykorzystane i to jest Issuer Common Name. Nie musicie znać dokładnie nazwy, wystarczy że wpiszemy sobie Encrypt i zobaczmy co w ten sposób znajdziemy. Mamy. Co dalej? Możemy skopiować to tak, żeby mieć pewność, że to jest dokładnie to, co nas interesuje i dalej możemy zobaczyć np. jakie usługi są podpisane tym właśnie certyfikatem. Mamy kilka usług podpisanych tym certyfikatem. Co dalej? Możemy zobaczyć konkretną usługę, czyli dopiszmy sobie „and”, wybierzmy pierwszą z brzegu i sprawdźmy do kiedy jest ważna. Ta wygasła w 2017. Możemy też oczywiście mieć przygotowane takie zestawienie (które będziemy częściej wykorzystywać), w którym będziemy mieli wszystkie informacje jakie mogą nas interesować. W związku z tym możemy ustawić sobie taki widok, w którym będziecie mieli Państwo zarówno informacje kto rozmawia z danym serwerem, czyli adres serwera, przez kogo podpisane, jaka usługa. Tu mamy oczywiście wyfiltrowane, więc jeżeli skasowałbym to co mamy w filtrze, to widzielibyśmy różnego rodzaju informacje: od kiedy ważny, do kiedy ważny. Tak naprawdę to możemy wyświetlić sobie wszystkie certyfikaty TLS. I teraz będzie „validity to” jest mniejszy od „now”, czyli skończył się wcześniej niż moment w którym sprawdzamy. Mamy tutaj wszystkie wygasłe certyfikaty, które nam się pojawiły. Oczywiście moglibyśmy dodać tutaj jakieś kolejne elementy w tej tabeli, dostawiając np. organizacje, ale jeżeli sprawdzamy to wewnątrz naszej firmy, to tak naprawdę możemy zweryfikować czy na pewno jako organizacja jest wpisana właśnie nasza firma. Oczywiście dokładnie to możemy ustawić na takim podsumowaniu, czyli adres IP, kto podpisał certyfikat, dla jakiej usługi. Ważność certyfikatu na takim wspólnym widoku (dashboardzie) można też ustawić. Tu są jeszcze wszystkie dodatkowe certyfikaty, które wygasają do końca czerwca, więc możemy sobie ustawić taki widok i widzimy, że do końca czerwca trzeba danym serwerom zaktualizować certyfikaty.

Dawid:

O certyfikatach można bardzo dużo rozmawiać i wiele rzeczy odnośnie tych certyfikatów weryfikować. Flowmon ma taką możliwość i to w jaki sposób go skonfigurujemy zależy od nas i od naszych potrzeb. Zastanawiałem się na początku swojej historii z sieciami i Bittorrentem, co jeszcze może się chować pod tym HTTPS-em? Czego my nie możemy widzieć? Co się tam dzieje? I takim elementem może być malware. Jak sobie z tym radzić? Jest możliwość weryfikacji czegoś takiego jak odcisk palca. Zanim o nim opowiem, to nadmienię kilka punktów istotnych dla tego momentu:

– komunikacja SSL/TLS typu klient-serwer, więc klient odpytuje serwer.

– sposób budowy klienta (czyli tej aplikacji, która nawiązuje połączenie) wymusza to w jaki sposób jest tworzony element HELLO, który wysyła klient. Jak Państwo wrócicie do tych początkowych slajdów, to będzie widać cały ten mechanizm TLS handshake – tam są te elementy.

– Na HELLO od klienta, serwer zawsze odpowiada identycznie i jest to uzależnione od tego w jaki sposób ta aplikacja została zbudowana.

– W przypadku komunikacji Command & Control (C2C), adres serwera często może ulegać zmianie, czy to po adresie IP czy też po domenie, ale sposób w jaki klient rozmawia – czyli ten skompromitowany zasób w sieci z serwerem gdzie jest puppet master i tam nam tymi zasobami zdalnie manipuluje – ten sposób rozmowy jest bardzo charakterystyczny. Jeżeli poznamy odcisk palca, czyli fingerprint tej rozmowy, to weryfikując te fingerprinty, będziemy mogli z dużym prawdopodobieństwem powiedzieć, że mamy malware u nas w sieci.

Fingerprint po stronie klienta, budowany jest na podstawie pięciu elementów, które mogą być wyłowione z nagłówka wysyłanego przez klienta, czyli ten element client HELLO. Tam patrzymy na wersję TLS, na to w jaki sposób protokół jest obsługiwany, czyli długości klucza, jakie są rozszerzenia, jaki jest sposób szyfrowania, wyciągamy wartości dziesiętne jeżeli chodzi o ten pakiet, nakładamy na to MD5 i powstanie pewien hash. W dużym uproszczeniu. Szczegółowe metody w jaki sposób jest to zbudowane są opisane, ale nie ma czasu żeby to w tej chwili w szczegółach opowiedzieć, natomiast odcisk palca tak powstaje. To co jest charakterystyczne, to że odcisk palca jest zawsze taki sam, czyli jeżeli któryś z zasobów rozmawia z siecią TOR, to ten odcisk będzie zawsze taki sam. Jeżeli mamy TrickBota albo Emoteta, to patrząc na fingerprint, on zawsze będzie taki sam. I jeżeli mamy teraz taką wiedzę, to czy dzięki Flowmonowi możemy weryfikować obecność malware’a w naszej sieci?

Klaudyna:

Tak, jak najbardziej. Żeby posiadać ten fingerprint, musimy mieć jakieś urządzenie, które potrafi obliczyć z tego zestawienia – z tego HELLO od klienta do serwera – hash. Tak dostajemy fingerprint. Sonda Flowmon potrafi to zrobić, potrafi wyświetlić Państwu takie hashe. To co jest istotne, to że nie jest to niestety do końca złotym środkiem na malware w HTTPS, ponieważ z jednego hosta to nie jest przedstawienie się konkretnego komputera. To jest przedstawienie się przeglądarki, która zestawia połączenie z jakąś witryną po HTTPS-ie. Dlatego też jeżeli jakiś malware zestawia połączenie, to on też zestawia to w specyficzny sposób i podpisuje się też w jakiś sposób. Ale z jednego laptopa możemy mieć kilka fingerprintów i pokażę Państwu jak to możecie sprawdzić i przetestować. Są dostępne narzędzia w Internecie gdzie możemy to sprawdzić. Tu np. jest mój fingerprint i jest to wyliczone, tak to wygląda. Możemy sobie jeszcze przeanalizować, jakie aplikacje w ten sposób się podpisują. Jak widzicie są to różne aplikacje na różnych systemach operacyjnych. One mogą być takie same dla kilku różnych wersji. Sprawdzimy sobie teraz z mojego laptopa z Firefoxa – całkowicie inaczej ta MD5 będzie wyglądała. W ten sposób natomiast możemy też weryfikować, jeżeli mamy podejrzenie co do jakiegoś adresu IP, co do jakiegoś hosta, co tam się na nim dzieje. W związku z tym, że nasza sonda potrafi wyliczyć takie fingerprinty, możecie Państwo sobie to obejrzeć. Sprawdźmy sobie jakiś jeden. Podlega to oczywiście weryfikacji. Zobaczmy co nam na ten temat powie baza danych. Baza danych mówi że to jakaś wersja Chrome albo jeszcze adware, więc jest to dodatkowa opcja weryfikacji danego hosta, który jest podejrzany i nie mamy pewności czy dzieje się na nim coś nieprawidłowego czy nie, ale z komunikacji HTTPS na pewno można zweryfikować czy jest to podejrzenie zainfekowania tego hosta jakimś malwarem czy nie. Oczywiście możemy ustawić alert, który powiadomi nas, jeżeli zostanie wykryty w naszej sieci któryś z tych fingerprintów. Nie musimy więc tego na stałe monitorować i codziennie wpisywać kolejnych wersji, tylko po prostu ustawiamy alert. Jeżeli zostanie znaleziony taki fingerprint, to chcemy dostać powiadomienie na ten temat.

Dawid:

Działa to więc w przypadku znanych zagrożeń i dostępnych fingerprintów. Chciałem tylko zaznaczyć dla tych Państwa, którzy nie znają platformy Flowmon, że jest to jedno rozwiązanie technologiczne, ale ma kilka modułów. Te moduły mogą być adresowane do różnych działów i departamentów w przedsiębiorstwie, zajmujących się czy to siecią, czy to np. serwerami bądź aplikacjami na tych serwerach, czy też do ludzi związanych z bezpieczeństwem. W związku z tym koszt posiadania tej platformy może być już wtedy inaczej interpretowany, dzielony na poszczególne działy, departamenty, zespoły. Flowmon charakteryzuje się też dużą elastycznością w przypadku implementacji. Nie musi występować duża ingerencja w sieć klienta czy już istniejące środowisko.

Klaudyna:

Jeżeli chodzi o analizę behawioralną, to do tego wystarczą nam dane z urządzeń sieciowych, czyli flowy z routerów i switchy i już możemy mieć wykrywanie bazujące na zachowaniu hostów w sieci. Natomiast jeżeli potrzebujemy lub chcemy mieć takie informacje, które pokazywałam dzisiaj, czyli informacje z certyfikatów, ważność certyfikatów, wersje TLS-a, rodzaj szyfrowania, to do tego potrzebujemy już sondy. Ona może stać w jednym miejscu, np. gdzieś blisko serwerów, czyli w Data Center, potrzebuje kopii ruchu żeby widzieć to zestawienie sesji szyfrowanej i móc takie informacje wyciągnąć z ruchu sieciowego. W związku z tym potrzebujemy do tego dwóch sprzętów – kolektora, który będzie tym głównym elementem i do tego sonda, która będzie takie pomiary wykonywała. Poza tym mamy również moduły związane z analizą aplikacji warstwy 7., czyli analiza wydajności aplikacji, analiza wykrywania ataków wolumetrycznych i możecie mieć Państwo także nagrywanie na życzenie. Czyli w momencie kiedy taka anomalia z systemu do behawiorystyki zostanie wykryta, to automatycznie zostanie też uruchomione nagrywanie pakietów, więc dostaniecie też jako dowód tego co się działo  pick-up w którym będzie można odtworzyć to co zostało przesłane, przeanalizować jakie informacje w pakietach zostały wysłane, wyciągnięte w ten sposób.

Dawid:

Jak widać potencjał jest spory, możliwości duże. Jest to bardzo obszerny temat i o wielu rzeczach jedynie wspomnieliśmy, żeby pokazać jak to można wykorzystać. Było wiele skrótów myślowych i wiele uproszczeń. Jeżeli ktoś chce pociągnąć temat dalej, to oczywiście zapraszamy do kontaktu.