Marek spojrzał na ekran stojącego przed nim laptopa. Przygotowywał się do kolejnego zlecenia ataku cybernetycznego. Tym razem celem miała być witryna giganta branży e-commerce w Polsce. Zleceniodawca chciał by wskazany sklep przestał działać w okresie przedświątecznym. Mógł to być przedstawiciel konkurencji próbujący podbić wyniki własnego przedsiębiorstwa, lub losowy niezadowolony klient. Nie miało to większego znaczenia – dla cyberprzestępców nie liczy się powód tylko zlecenie.
Doświadczenie Marka podpowiadało mu, że najprostsze wektory ataków nie zadziałają. Takie ataki kosztują po kilka dolarów za godzinę – gdyby były skuteczne, zlecenie nie dotarłoby do niego. Wiedział przy tym, że najważniejszym elementem ataku sieciowego jest rozpoznanie, dlatego zaczął od podstaw. Z użyciem botnetu przeskanował serwer ofiary pod kątem udostępnianych usług. Zdobycie informacji zwrotnej nie zajęło mu więcej niż pół godziny. Zgodnie z oczekiwaniami jedyną udostępnioną usługą było HTTP. Jednak to, że serwer nie odpowiada aktywnie na pakiety, nie znaczy że one do niego nie docierają. Przygotował więc prosty skrypt zalewający serwer ofiary pakietami UDP i wykorzystał mały botnet aby sprawdzić czy zauważy zmianę w działaniu usługi.
Po drugiej stronie kabla operatorzy centrum bezpieczeństwa sieciowego aktywnie monitorowali poziomy ruchu sieciowego kierowanego do klientów, którym udostępniali łącze. System TAMA, który wspierał ich operacje, natychmiast poinformował ich o wzroście natężenia ruchu sieciowego, a ci przekazali te informacje do właściciela serwera. Zauważyli również, że atak pochodzi ze znanego botnetu i składa się z bezwartościowych pakietów, dlatego zgodnie z ustaleniami z klientem, rozpoczęli mitygację. Cały ruch kierowany do atakowanej usługi przekierowany został do dodatkowego serwera po stronie operatora, który skutecznie odfiltrował cały ruch pochodzący z sieci botnet. GlaDDoS (bo tak nazywa się ten dodatkowy serwer) został zaprojektowany do oddzielania pakietów pochodzących z ataków DDoS, od regularnego ruchu internetowego i skutecznie blokował atak, gwarantując jednocześnie ciągłość działania usługi.
Opis ochrony wolumetrycznej
Aby przeanalizować co tu się dokładnie stało, należy zrozumieć podstawowe koncepty usługi Anty DDoS oferowanej przez EXATEL. Jest to kompleksowa usługa złożona z filarów cyberbezpieczeństwa, którymi są ludzie (zespoły SOC), technologia (system TAMA) i procesy (obsługa incydentów przez zespoły SOC).
Poniższy diagram prezentuje komponenty systemu TAMA wspierające obsługę ataków wolumetrycznych.
Analiza ruchu rozpoczyna się już w punkcie wejścia do sieci operatora. Router PE zbiera dane statystyczne dotyczące przepływających przez niego pakietów i przekazuje je do komponentu Aperture
Aperture zbiera przychodzące dane w formie szeregów czasowych, grupując je jednocześnie na podstawie celu i charakterystyki pakietów (na przykład ilość pakietów o określonych wcześniej rozmiarach); informacje szczegółowe nie są zbierane, dzięki czemu zachowana jest pełna prywatność. Przygotowane przez Aperture dane przesyłane są jednocześnie do bazy danych i komponentu Detektor.
Detektor natychmiast analizuje otrzymane informacje pod kątem wystąpienia anomalii w ilości i rodzaju przesyłanych danych. Zna parametry chronionych usług, dzięki czemu może podejmować bardziej świadome decyzje odnośnie detekcji (co w praktyce sprowadza się do dokładnej konfiguracji warunków detekcji, dla różnych usług). Naruszenia wykryte przez detektor zapisywane są w bazie danych w postaci alarmów, o których natychmiast informowani są operatorzy SOC. Detektor ciągle aktualizuje informacje o wygenerowanych alarmach, informując o zmianie natężenia lub zakończeniu wykrytego ataku.
Komponent Chell stanowi interfejs użytkownika, gdzie zespół SOC i klienci analizują zebrane dane. Rysuje on wykresy opisujące zmiany przepływu ruchu sieciowego w czasie i udostępnia informacje dodatkowe o jego charakterystyce. Pozwala to specjalistom ds. cyberbezpieczeństwa zrozumieć co tak naprawdę dzieje się w sieci i szybko zdecydować o najodpowiedniejszym mechanizmie mitygacji.
Podczas mitygacji ataku wolumetrycznego, cały ruch sieciowy przekierowywany jest do komponentu GlaDDoS (czerwona linia na diagramie), który dokładnie analizuje każdy przepływający przez niego pakiet i decyduje czy jest on częścią prawidłowego ruchu, czy ataku. Pakiety zakwalifikowane jako część ataku są porzucane i nigdy nie docierają do usługi. Analiza przeprowadzana przez GlaDDoS jest bardzo dokładna (przez co zużywa bardzo dużo zasobów sprzętowych), dlatego prowadzona jest wyłącznie dla wybranych usług w podanym czasie. Taki model pozwala skutecznie bronić wiele usług jednocześnie przy zachowaniu niskich kosztów eksploatacji. Komponent GlaDDoS umiejscowiony jest w punkcie wejścia do sieci operatorskiej, dzięki czemu nieprawidłowe pakiety są usuwane tak szybko, jak to możliwe i nie zwiększają obciążenia sieci.
Router CE jest punktem wejścia do sieci klienta. Dzięki filtracji GlaDDoS podczas trwania mitygacji, dociera do niego jedynie prawidłowy ruch klientów usługi.
Interpretacja
W opisywanym przykładzie atakujący wysłał sporą ilość pakietów UDP na serwer HTTP. Detektor z łatwością zidentyfikował taki ruch jako nieprawidłowy przez wzgląd na nagły wzrost objętości i zastosowanie nieprawidłowego protokołu. Detekcja często jest skonfigurowana, do automatycznego rozpoczęcia mitygacji w tak oczywistych przypadkach.
Operatorzy SOC zostali powiadomieni o detekcji wraz z informacją, czy uruchomiona została automatyczna mitygacja. W odpowiedzi na powiadomienie, tymczasowo zablokowali cały ruch UDP i ICMP kierowany do usługi (w uzgodnieniu z właścicielem usługi) mimo, że atak pochodził ze znanego botnetu. Podjęli taką decyzję spodziewając się kolejnych wektorów ataków na podstawie swojego doświadczenia. Należy zaznaczyć, że obecne rozwiązania technologiczne nie są w stanie podejmować tak wielowymiarowych decyzji, dlatego specjaliści ds. cyberbezpieczeństwa są czynnikiem niezbędnym dla skutecznej ochrony.
Atakujący szybko zauważył, że jego działania nie przyniosły żadnego rezultatu. Przez chwilę zastanawiał się czy nie powtórzyć próby z użyciem czystego botnetu, którego IP nie są jeszcze powszechnie znane, ale szybko odrzucił ten pomysł. Nie chciał ich ujawnić przez tak pochopne akcje. Zamiast tego zdecydował się powtórzyć próbę – tym razem odbijając atak od słabo zabezpieczanego serwera DNS. Po raz kolejny nie udało mu się zaobserwować żadnych efektów jego działań. Jedno wiedział na pewno – ataki z użyciem protokołu UDP nie będą skuteczne. Cyberprzestępca powtórzył swoje działania z wykorzystaniem protokołu ICMP i potwierdził, że próba wykorzystania go będzie równie nieskuteczna jak w przypadku protokołu UDP.
Operatorzy SOC obserwujący rozwój sytuacji, na bieżąco analizowali statystyki zbierane przez system TAMA. Natychmiast zauważyli nowe wektory ataku, jednak wiedzieli, że GlaDDoS z łatwością sobie z tym poradzi. Skutecznie przewidzieli również zaobserwowany chwilę później wzrost ilości pakietów w protokole TCP, a następnie wysyp zapytań HTTP. Byli spokojni nawet w sytuacji, gdy atakujący spróbowali zalać usługę klienta pakietami, z adresów spoza znanych botnetów – anormalna charakterystyka ruchu została skutecznie odfiltrowana przez narzędzie GlaDDoS. Teraz cierpliwie oczekiwali na ataki wykorzystujące podatności serwerów HTTP.
Interpretacja
Zadziałały tutaj mechanizmy GlaDDoS analizujące wolumeny ruchu kierowane do usługi. Ataki DDoS typu flood, charakteryzują się bardzo dużą ilością pakietów, które nie są możliwe do wygenerowania przy zwykłym korzystaniu z usługi. GlaDDoS wykrywa przypadki gwałtownego wzrostu natężenia ruchu i skutecznie je blokuje, przepuszczając jednocześnie pakiety użytkowników, które nie przekraczają ustalonych limitów. Ochrona usługi oparta jest tutaj na konfiguracji mitygacji, która dostosowana jest do parametrów usługi. Zespoły SOC zarządzające usługą, pozostają w stałym kontakcie z klientem, dzięki czemu możliwe jest dostosowanie parametrów na podstawie faktycznych danych, lub dostosowanie ich jeśli zmieni się charakter usługi. Opisany przykład doskonale obrazuje znaczenie współpracy ludzi, technologii i procesów w ochronie anty-DDoS. Nieprawidłowość w każdym z tych filarów może tworzyć furtkę dla cyberprzestępców. Nieprawidłowa konfiguracja parametrów usługi mogłaby doprowadzić do sytuacji, gdzie część prawidłowego ruchu jest interpretowana jako atak, zwiększając tym samym jego skuteczność.
Marek złożył ręce na piersi. Jego wzrok skierowany był na terminal wyświetlany na ekranie, ale on go nie widział głęboko pogrążony w myślach. Wiedziałem, że ataki poza TCP nie podziałają, ale żeby zablokować zalewanie zapytaniami HTTP. – myślał – Zbyt szybko wykorzystałem botnet i tylko go spaliłem. Muszę bardziej uważać, żeby nie ujawnić innych kontrolowanych adresów. Mógłbym spróbować zeskalować zalew, ale jeśli ruch jest monitorowany to kosztowałoby to kilka dodatkowych botnetów. Na tym etapie najlepszym rozwiązaniem jest zrezygnować z wolumetrii i zaatakować samą usługę. – skonkludował.
Interpretacja
Wiele różnych sieci i usług posiada własną implementacje ochrony przed atakami wolumetrycznymi, dlatego naturalnym jest, że atakujący domyśli się nie tylko istnienia takiej ochrony, ale też jej generalnej struktury. Samo istnienie ochrony wolumetrycznej ogranicza możliwości wykorzystania nieznanych botnetów, ponieważ ich adresy mogą zostać ujawnione i z łatwością blokowane w przyszłości.
Operatorzy SOC z zadowoleniem patrzyli na statystyki wskazujące na pojawienie się ataków usługowych. Spodziewali się tego i skonfigurowali narzędzie Egida aby agresywniej wykrywało ataki na tę konkretną usługę. Z powodzeniem udało im się wykryć kombinacje ataków slow loris i zmiany szyfrowania TLS kierowane do chronionej usługi. Nietypowe wydało im się, że źródło ataku ograniczało się do zaledwie kilku adresów IP. Szybko zrozumieli, że aktualnym celem atakującego nie jest zniszczenie usługi, a jedynie wykrycie jej słabości przy oszczędnym zarządzaniu dostępnymi botnetami. Ciekawe jak długo będzie nas tak testował…. – zastanawiał się na głos operator. Niech testuje – odpowiedział mu drugi – nawet jeśli wymyśli coś, czego nie możemy zmitygować, to dzięki niemu będziemy mogli. Obserwujcie to tylko trochę dokładniej.
Opis ochrony liniowej
Ataki kierowane na usługi, zdecydowanie różnią się od ataków wolumetrycznych. Przede wszystkim nie da się ich wykryć przez anomalie w statystykach ruchu sieciowego. Oznacza to, że moduły ochrony wolumetrycznej nie wykryją nieprawidłowości i nie będą w stanie wykryć ataku. Sam komponent GlaDDoS jest zaprojektowany do błyskawicznego rozdzielania ruchu z ataku wolumetrycznego od prawidłowego. Filtr takich ataków musi przetwarzać miliony pakietów na sekundę, co byłoby niemożliwe przy dokładnej analizie ich zawartości w warstwie aplikacji. Z tego też powodu ochrona anty-DDoS oferowana przez EXATEL, implementuje osobny moduł ochrony liniowej, który poddaje ruch oczyszczony z ataków wolumetrycznych dodatkowej analizie. Poniższy diagram prezentuje realizację ochrony usługowej w TAMA.
Egida jest komponentem ochrony liniowej, skonfigurowanym dla dokładnego rodzaju usługi. W przeciwieństwie do GlaDDoS umiejscowiona jest ona na krawędzi sieci, po stronie klienta. Konfiguracja Egidy jest w pełni świadoma rodzaju i implementacji chronionej usługi, co pozwala jej chronić usługę przed atakami wykorzystującymi jej słabości. Dodatkowo Egida zbiera dokładne dane statystyczne dotyczące ruchu związanego z realizacją usługi (podobnie jak w przypadku GlaDDoS zachowana jest pełna prywatność). Egida nie jest uruchamiana wybiórczo i działa zawsze. Audyt podjętych przez nią działań wraz ze statystykami ruchu zapisywany jest w bazie danych.
Egida jest zaprojektowana do obsługi bezdotykowej po wstępnej konfiguracji. SOC analizuje jedynie informacje o podjętych przez nią decyzjach i statystyki ruchu, aby monitorować poprawność działania komponentu i dostosować konfigurację w przypadku zmian lub odchyleń.
Interpretacja
Ataki slow loris i zmiany szyfrowania TLS nie zostaną odfiltrowane przez GlaDDoS, ponieważ stanowią prawidłowy ruch. Naruszeniem nie jest tutaj sztuczne tworzenie dużych wolumenów, a wykorzystanie specyficznych problemów w implementacji usługi (zarządzanie wątkami w przypadku slow loris i oddolna kontrola dla renegocjacji TLS). W tym przypadku zadziałał moduł ochrony drugiego stopnia, który działa na ruchu o znacznie mniejszych wolumenach niż ten obsługiwany przez GlaDDoS.
Przebieg ataku Marka pokazuje, że do prawidłowej obsługi ataku niezbędne są dwa, wzajemnie uzupełniające się komponenty. GlaDDoS radzi sobie z dużymi wolumenami ruchu i gwarantuje odfiltrowanie pakietów-śmieci, które nie mają wartości dla usługi ani jej klienta. Tak odfiltrowany ruch, poddawany jest dokładniejszej analizie, która wykrywa finezyjne ataki wykorzystujące podatności konkretnych usług.
GlaDDoS nie może realizować ochrony usługowej, ponieważ nie poradziłby sobie z dużymi wolumenami ruchu; Egida nie może realizować ochrony na ruchu nieodfiltrowanym przez GlaDDoS, ponieważ przez swoją dokładność, obsługuje znacznie mniej pakietów. Żaden z tych komponentów nie będzie działał poprawnie, bez wsparcia specjalistów zarządzających ich konfiguracją. Nawet najlepszy specjalista może popełnić błąd, przed którymi ustrzegają ich dostosowywane na bieżąco procesy. Marek miał dzisiaj nieszczęście trafić na ochronę anty-ddos, która łączy ze sobą wszystkie te elementy tworząc TAMĘ, która dokładnie kontroluje przepływ danych.
W tym samym czasie Marek gasił kolejnego papierosa, obserwując na ekranie perfekcyjne działanie usługi, którą próbował zniszczyć. Sprawdził wiele różnych możliwości, ale nie udało mu się osiągnąć celu zlecenia. To nie tak, że sprawdziłem wszystkie opcje – pomyślał zamykając laptopa – może jutro pokombinuję z ruchem zaszyfrowanym….
