„Mamo, nie teraz, właśnie odpalam botnet” – czyli jak bronić się przed DDoS-em na produkcji (i nie dostać bana od hostingu)

Autorem wystąpienia jest Konrad Tarnawski, specjalista od cyberbezpieczeństwa w Lotniczym Pogotowiu Ratunkowym (gdzie czuwa m.in. nad systemem dysponowania karetek SWD), który po godzinach działa na politechnice i dłubie w układach IoT.

Od żarówki IoT po paraliż Nginx-a

Konrad już na wstępie sprowadza temat na ziemię, zauważając, że za większością ataków na serwery gier, komunikatory głosowe czy mniejsze biznesy stoją dzieciaki w wieku 12–16 lat szukające rozgłosu lub zemsty. Ekspert twierdzi, że próg wejścia praktycznie dziś nie istnieje – gotowe botnety pokroju Mirai leżą na GitHubie za darmo, a płatne stresery (DDoS-as-a-Service) można wynająć za cenę kebaba, weryfikując ich moc na publicznych miernikach ruchu zwanych Dstatami. Armię do uderzeń buduje się z najtańszego sprzętu IoT – nawet ze zwykłych żarówek Wi-Fi z procesorami ARM, w których producenci całkowicie zignorowali bezpieczeństwo.

Prelegent dzieli zagrożenia na ataki wolumetryczne, protokołowe oraz aplikacyjne (L7), wskazując, jak niskim kosztem można wygenerować potężne uderzenie dzięki amplifikacji. Wykorzystując IP spoofing, atakujący wysyła drobne zapytania do otwartych serwerów DNS, NTP czy archaicznej usługi Chargen, które odsyłają wielokrotnie większe pakiety prosto na naszą infrastrukturę. Specjalista wskazuje też na podstępną pułapkę protokołu ICMP – jeśli wytniemy port UDP, ale nie zablokujemy komunikatów Destination Unreachable, nasz serwer sam zacznie odsyłać kilkusetbajtowe pakiety pod sfałszowany adres, nieświadomie wzmacniając atak.

Równie dotkliwe bywają ataki wyczerpujące zasoby aplikacji bez wielkiego wolumenu danych. Nieskonfigurowanego Nginxa (z domyślnym limitem 768 połączeń) błyskawicznie położy klasyczny Slowloris, a świeższa podatność HTTP/2 HPACK Bomb pozwala za pomocą spreparowanych nagłówków doprowadzić do błyskawicznego wycieku RAM-u i błędu Out of Memory (OOM). Prawdziwym absurdem dla admina jest jednak rykoszet po ataku SYN Flood – gdy serwer odpowiada pakietami SYN-ACK pod sfałszowane adresy, automatyczne systemy u dostawców pokroju Hetznera czy OVH potrafią uznać naszą maszynę za agresora. Efekt to zgłoszenie Abuse i blokada serwera mimo bycia ofiarą, co bywa też wykorzystywane celowo do wymuszania haraczy.

Jak się przed tym bronić bez gigantycznego budżetu? Ekspert twierdzi, że śmieciowy ruch trzeba wycinać jak najniżej w stosie sieciowym. W iptables (lub nftables) kluczowe jest filtrowanie już w tablicach raw i mangle na etapie PREROUTING, zanim ruch obciąży tablicę śledzenia połączeń (conntrack). Wycięcie nieprawidłowych flag TCP, narzucenie limitów na adres IP (hashlimit) oraz zablokowanie nieużywanych portów (pamiętając, że numeracja zaczyna się od portu 0) pozwala za darmo odfiltrować gigabity śmieci. Przy większej skali naturalnym krokiem są programy eBPF / XDP działające w jądrze lub na karcie sieciowej oraz BGP Flowspec dla posiadaczy własnego ASN-u. Na warstwie aplikacyjnej świetnie sprawdza się z kolei stary dobry port knocking zaszyty w kliencie aplikacji, a na koniec zostaje ścieżka prawna (art. 268a, 269a i 269b KK), z której służby coraz skuteczniej korzystają.

Wpadaj po więcej wiedzy na żywo!

Powyższe notatki to esencja prelekcji wygłoszonej na meetupie SysOps/DevOps Polska, której pełne nagranie znajdziesz na naszym kanale YouTube: https://www.youtube.com/watch?v=qDlC62h445g.

Nagranie to jednak tylko wstęp, bo najlepsze rzeczy dzieją się na sali. Podczas meetupów po prelekcji zawsze możesz podejść do prowadzącego, dopytać o konkretne regułki firewalla czy skonsultować nietypowy przypadek z własnej infrastruktury przy pizzy i dobrym napoju. Przejrzyj swoje limity w Nginxie oraz reguły conntrack już dziś i zapisz się na kolejne meetupy SysOps/DevOps Polska w swoim mieście: https://www.sysopspolska.pl/eventy/