TAMA – operatorski system ochrony przed atakami DDoS

DDoS to jedna z technik ataku nastawiona nie na kradzież danych, tylko na czystą destrukcję zasobów, a w najlepszym razie na przykrycie atakiem DDoS innego ataku, żeby rozproszyć obronę.

W porównaniu z finezją tańca exploitów po stosie atak DDoS, zalewający atakowany adres dużą liczbą pakietów (atak wolumetryczny), przypomina atak trolla. Operator telekomunikacyjny zobaczy ten atak jako pierwszy w logach routerów. Dla ataku wolumetrycznego operator jest pierwszą i ostatnią linią obrony: jeśli atak wysyci łącze fizyczne od operatora do atakowanego klienta, klientowi pozostaje tylko zadzwonić do operatora, bo nawet maila do niego nie wyśle, chyba że ma dwa łącza. Dalsze kroki obrony realizuje operator w ramach zarządzania ruchem sieciowym. Możliwości jest kilka.

Pierwsza to analiza portu źródłowego i docelowego. Jeśli atak wykorzystuje technikę wzmocnionego odbicia (reflected amplification), numer portu źródłowego lub docelowego we wszystkich pakietach pochodzących z ataku jest taki sam. Atakowana usługa nie musi mieć tego portu otwartego, więc taki atak odbiłby firewall. Ale na zapchane łącze takie odbicie nie pomoże. Czasem pomaga analiza rozmiaru pakietów, ale w niektórych atakach rozmiar odpowiedzi zależy od zasobów i konfiguracji serwera używanego w ataku.

Druga możliwość to analiza adresów źródłowych. Jeśli atak wykorzystuje fałszowany (spoofowany) adres źródłowy, zazwyczaj ten adres jest losowany jako 32-bitowa liczba całkowita, która wskazuje na pochodzenie z różnych zakątków internetu. Można to ładnie zwizualizować przy użyciu tzw. krzywej Hilberta.

Trzecia możliwość to otwarta ksenofobia. Jeśli naszą stronę odwiedzali dotąd użytkownicy z cyberprzestrzeni RP, można zastosować geofiltr do przycięcia ataku.

Czwarta możliwość to zastosowanie blacklisty lub whitelisty. Jeśli wiemy, kto powinien do nas napisać, to niech on pisze, a reszta nie. Blacklista dla portów to właściwie odpowiednik prostego firewalla, tylko przed łączem klienta, a nie za i ta różnica jest zasadnicza.

Jeśli nic innego nie pomaga, to piątą możliwością jest policing: jeśli ruchu jest za dużo, przytnijmy go, żeby klient dostał tylko tyle, ile jest w stanie obsłużyć. Oczywiście nie ma gwarancji, że przy okazji nie przytniemy legalnych użytkowników.

Z problemem łącz zapchanych wolumetrycznym atakiem DDoS musi się zatem zmierzyć operator. Ponieważ Polska technologią stoi (ha!), z problemem zmierzyły się przynajmniej dwie firmy, które doprowadziły produkt do wdrożenia: Atende z redGuardianem i Exatel z Tamą. Ponieważ redGuardian doczekał się bogatej literatury, był m.in. prezentowany na PLNOG, chciałbym opisać pokrótce rozwiązanie TAMA.

W rozwiązaniu TAMA zastosowaliśmy większość opisanych powyżej technik.

Filtrowanie pakietów w projekcie TAMA oparte jest na filozofii zero copy i wielowątkowym przetwarzaniu. Wyeliminowanie operacji kopiowania oznacza, że z bufora danych wykonujemy tylko odczyt, a to przyspiesza przetwarzanie na tyle, że kilka wątków, współpracujących na precyzyjnie współdzielonych zasobach, jest w stanie obsłużyć duże łącze: testy prowadziliśmy do przepustowości 100 Gbit. Dzięki temu udało nam się filtrowanie ruchu, które ma prędkość hardware przy elastyczności software.

Poza filtrowaniem realizujemy też pomiary ruchu na routerach, które przekazują informacje w protokole Netflow i zarządzanie ruchem przez protokół BGP, którym wstrzykujemy do routerów zmianę ścieżki ruchu, co umożliwia ochronę atakowanego obiektu. Ciekawym wyzwaniem było oszacowanie ciągłej metryki, jaką jest poziom ruchu w badanym łączu na podstawie punktowych (w czasie) informacji o konkretnych przepływach, jakich dostarcza protokół Netflow.

Reszta rozwiązania typowa: interfejs webowy, system rozproszony, konstrukcja modularna, która bardzo ułatwia osiągnięcie HA (high availability), load balancing, redundancja baz (NoSQL). Oprócz przygody inżynieryjnej i niewątpliwej radości tworzenia mamy na koniec krótkiego w sumie projektu całkiem sprawnie działający antyDDoS. Wygrzewamy system już od kilku miesięcy i chętnie wrócimy za rok z wnioskami. 

W realizacji projektu wspierało nas Narodowe Centrum Badań i Rozwoju; działające w partnerstwie z Ministerstwem Cyfryzacji, które obsługiwało konkurs Cyber Sec Ident, poświęcony wytwarzaniu innowacyjnych narzędzi do ochrony cyberprzestrzeni. Kolejnym partnerem był duży ośrodek akademicki, który zrealizował ciekawy moduł funkcjonalny, zasługujący na oddzielne opisanie.

Atak z mętnej wody albo niefrasobliwość operatora

Skąd się bierze możliwość spoofowania (fałszowania) adresu źródłowego? Operatorzy sieci nie mają obowiązku sprawdzania, czy pakiet wychodzący z ich sieci ma adres źródłowy pochodzący z tej sieci, czyli z prefiksów, które ich sieć rozgłasza przez BGP, ani czy pakiet wchodzący do sieci miał prawo trafić z tego AS, z którego trafił. Jest to dobra praktyka określona w BCP 38 i RFC 3013, ale nie ma takiego obowiązku. Dodajmy też, że operator zazwyczaj zarabia na ruchu, który klient generuje, w zależności od modelu biznesowego sprzedaży usługi. Zmniejszanie strumienia pakietów potencjalnie redukuje biznes. I czy to jest zmartwienie operatora, że jego klient puszcza przez CHARGEN gigabajty danych na drugi koniec świata? Oczywiście taka praktyka jest naganna, ale jak się komuś biznes nie dopina, to i brzytwy się chwyci.

Adresy źródłowe pakietów inicjujących atak wzmocnionego odbicia są prawdziwe, inicjowanie ataku pakietami sfałszowanymi nie ma sensu ekonomicznego, bo i tak trzeba zapłacić za ten ruch, chyba że ma się do dyspozycji botnet i atakuje z botów. Wtedy za ruch płacą uprzejmie właściciele botów.

Idealnie jest, jeśli atak typu wzmocnionego odbicia można przeprowadzić od operatora, który nie sprawdza zgodności adresu źródłowego. Pakiet inicjujący atak, wraz z adresem źródłowym z warstwy 3, może zostawić ślad w logach atakowanego serwera i jeśli atakowany wykaże się odpowiednią determinacją, to wśród administratorów wszystkich serwerów, użytych do wzmocnionego odbicia znajdzie w końcu administratora, który na jego prośbę zanurkuje w logi. Jeśli w tych logach zobaczymy adres sfałszowany, wtedy ślad się urywa. No, chyba że operator owego admina rejestruje ruch i z logów wykopie się informację, z jakiego AS przyszedł ruch inicjujący atak. Ale tego typu analiza jest mozolna i wymaga dobrej woli administratorów albo posiadania odpowiedniej dźwigni (np. jeśli zaatakowany serwer należy do Departamentu Obrony USA).

Ataki wzmocnionego odbicia nie wyczerpują całego zwierzyńca ataków DDoS, równie niszczące mogą być ataki SYN-FLOOD, które mogą też używać adresów sfałszowanych, a ich zalew zmusza atakowany serwer do tworzenia dużej liczby rekordów w stosie TCP/IP czekających na pełne nawiązanie połączenia TCP. Nasz serwer uprzejmie odpowiada pakietem SYN-ACK, ale jeśli adres jest sfałszowany, to wysyła je w próżnię. Notabene – jeśli skierujemy atak SYN-FLOOD na serwery dowolnej usługi TCP i podamy jako źródło sfałszowany adres serwera rzeczywistej ofiary, to serwer ofiary zostanie zaatakowany atakiem SYN-ACK-FLOOD pochodzącym od serwerów usługi.

Botnet jest w stanie wygenerować dużą liczbę zapytań kompletnych i prawidłowych w warstwie 7, które wygenerują obciążenie w infrastrukturze atakowanego, zwiększą koszty świadczenia usługi, a nie przyniosą żadnego efektu ekonomicznego. No, chyba że ktoś zarabia na wyświetlaniu reklam, wtedy atak DDoS na samego siebie może nawet mieć pewien sens ekonomiczny.

Jak skonstruować atak DDoS

W wielu atakach typu reflected, takich jak NTP, DNS czy CLDAP, adres ofiary jest w warstwie 3 pakietu inicjującego. Protokół nie jest niebezpieczny, ale co z tego? Jeśli niefrasobliwi operatorzy dostarczą spoofowany pakiet do wybranych przez atakującego serwerów usługi, serwer grzecznie odpowie, wskutek czego ofiara się zdziwi. Do ataku możemy wybrać sobie jeden taki protokół albo kilka jednocześnie.

Wszystkie protokoły, które adres odbiorcy biorą z warstwy 7, należą do kategorii insecure by design. W celu wykrycia podatności protokołów, analizujemy ich RFC i implementacje albo jeśli nie są upublicznione, testujemy je doświadczalnie, używając serwera implementującego dany protokół. Wystarczy podmienić adres w warstwie 3 oryginalnego pakietu zapytania kierowanego z naszej sieci, a potem sprawdzić, komu odpowie serwer usługi. Nawet jeśli spójność komunikatu jest sprawdzana, to nie może to dotyczyć warstwy 3, bo każdy NAT byłby dla takiego pakietu barierą nie do pokonania. Następnie sprawdzamy za pomocą Shodana, ile jest serwerów usługi, która pracuje na tym porcie. Jeśli protokół jest podatny, a w sieci jest wiele serwerów, sprawdzamy, jakie typy komunikatów generują największe wzmocnienie. To współczynnik wzmocnienia ataku decyduje o tym, czy atak za pośrednictwem serwerów takiego protokołu jest praktyczny. Decyduje stosunek liczby oktetów pakietu wychodzącego do liczby oktetów pakietu inicjującego atak – przecież nie chodzi nam o to, żeby wysłać do pośredniczącego serwera terabajt danych po to, żeby on przesłał dalej terabajt danych. Co najważniejsze, wszystkiego tego nie musimy analizować sami. Można zamówić atak o określonym wolumenie, wystarczy zapłacić. Wiele takich stron zostało ostatnio zlikwidowanych w Europie, USA i Chinach, ale wiele nadal istnieje.

Czasami daje się ograniczyć zakres strat przez konfigurację serwera usługi, która zredukuje współczynnik wzmocnienia. Są też inne techniki obrony: niektóre protokoły mają sens tylko w sieci LAN i nie powinny być przekazywane przez brzeg tej sieci (trudno dociec, po co miałby być otwarty na świat serwer MS SQL). Niektóre protokoły stanowią malowniczą historyczną zaszłość – przykładowo, kto i w jakim celu miałby używać zdalnie generatora randoma z innej sieci za pośrednictwem protokołu CHARGEN?

Jak widać, technik jest wiele. Dla szczęśliwego posiadacza botnetu atak jest prosty jak konstrukcja cepa i nie wymaga ani ukrywania informacji przez jakieś steganografie, ani dłubania exploitów.

Autorzy dziękują wszystkim pracownikom firmy EXATEL, którzy mieli wkład w powstanie niniejszego tekstu.

Teodor Buchner, Michał Krzywkowski

Już w najbliższy piątek, 13 grudnia, zapraszamy na webinar poświęcony tematyce ataków DDoS, który poprowadzą nasz redaktor naczelny Adam Haertle i Teodor Buchner, pracujący przy projekcie TAMA.

Za publikację tego artykułu otrzymujemy wynagrodzenie.