Layer 4 vs Layer 7 ataki DDoS - na czym polega różnica i dlaczego to ważne

Jeśli kiedykolwiek zajmowałeś się ochroną DDoS dla swojego serwera Minecraft, na pewno natknąłeś się na terminy "Layer 4" i "Layer 7". Niektóre ochrony deklarują filtrację na L4, inne chwalą się analizą L7. Brzmi ładnie, ale co konkretnie za tym stoi?

Rozbierzmy to bez akademickiego nudziarstwa. Co to za warstwy, jakie ataki na jakim poziomie działają i dlaczego do normalnej ochrony potrzebne są oba.

Co to jest model OSI (krótko i konkretnie)

OSI (Open Systems Interconnection) to teoretyczny model, który dzieli komunikację sieciową na 7 warstw. Wymyślono go w latach 80. do standaryzacji i wciąż jest używany jako wspólny język, kiedy ludzie omawiają sieci.

Oto wszystkie 7 warstw, od dolnej do górnej:

1. Physical - kable, światłowody, fale radiowe. Fizyczne przesyłanie bitów.
2. Data Link - ramki Ethernet, adresy MAC. Przesyłanie danych między sąsiednimi węzłami.
3. Network - adresy IP, routing. Jak pakiet znajduje drogę z punktu A do punktu B.
4. Transport - TCP i UDP. Jak dane są niezawodnie (albo szybko) dostarczane między aplikacjami.
5. Session - zarządzanie sesjami. W praktyce prawie nie występuje jako osobna warstwa.
6. Presentation - kodowanie, szyfrowanie. TLS mieszka mniej więcej tutaj.
7. Application - HTTP, DNS, protokół Minecrafta. To, z czym pracują końcowe aplikacje.

W praktyce z tych 7 warstw dla ataków DDoS i ochrony ważne są trzy: Layer 3 (Network), Layer 4 (Transport) i Layer 7 (Application). Warstwy 3 i 4 zazwyczaj grupuje się razem jako "L3/L4" albo po prostu "L4", bo ataki na tych poziomach są podobne z natury - pracują z surowymi pakietami.

Ataki L3/L4: brutalna siła

Ataki na warstwach 3 i 4 to klasyczny DDoS w jego najprostszej formie. Pomysł jest elementarny: zalać kanał lub zasoby serwera ogromną ilością ruchu. Tutaj nie potrzeba sprytu - potrzeba objętości.

SYN Flood

Jeden z najstarszych i wciąż jeden z najpowszechniejszych ataków. Działa tak: kiedy łączysz się z serwerem po TCP, odbywa się trójetapowy handshake - SYN, SYN-ACK, ACK. Przy SYN flood atakujący wysyła tysiące pakietów SYN, ale nigdy nie kończy handshake'a. Serwer przydziela pamięć pod każde półotwarte połączenie i w pewnym momencie po prostu się zadławia.

Dla serwerów Minecraft SYN flood jest szczególnie nieprzyjemny, bo każde nowe połączenie gracza zaczyna się od TCP handshake. Kiedy tablica półotwartych połączeń jest przepełniona, prawdziwi gracze po prostu nie mogą się połączyć - serwer nie jest w stanie obsłużyć ich SYN.

UDP Flood

UDP to protokół bez nawiązania połączenia. Nie ma handshake'a, nie ma potwierdzeń. Wysłał pakiet - i tyle. To czyni UDP idealnym narzędziem do ataków objętościowych: atakujący generuje gigabajty ruchu UDP na sekundę, zapychając kanał przychodzący serwera.

Minecraft używa TCP dla głównego ruchu rozgrywki, ale wiele serwerów również nasłuchuje UDP (query port, Voice Chat, pluginy). Nawet jeśli twój serwer nie używa UDP, atak i tak zapcha kanał - pakiety przecież przychodzą na interfejs sieciowy, a pasmo jest wydawane zanim twój firewall je odrzuci.

Więcej o różnicy między protokołami - w artykule o atakach TCP vs UDP.

Ataki amplification

To sprytna wariacja UDP flood. Atakujący wysyła małe zapytanie do pośredniczącego serwera (DNS, NTP, memcached), podstawiając adres IP ofiary jako adres nadawcy. Pośredniczący serwer odpowiada ofierze odpowiedzią, która jest dziesiątki razy większa od wyjściowego zapytania.

DNS amplification daje współczynnik wzmocnienia około 50x. Memcached - do 51000x. To znaczy, że atakujący z kanałem 100 Mbit może generować atak 5 Gbit przez DNS albo dosłownie terabity przez memcached.

ICMP Flood i inne

ICMP flood (znany też jako Ping flood), TCP RST flood, ACK flood - to wszystko wariacje jednego tematu. Zalać serwer lub kanał pakietami określonego typu. Różnią się szczegółami implementacji, ale sens jest ten sam: objętość, objętość, objętość.

Wspólne cechy ataków L3/L4

• Objętościowe. Mierzone w Gbps (gigabity na sekundę) lub Mpps (miliony pakietów na sekundę).
• Tępe (w dobrym sensie). Nie trzeba nic wiedzieć o aplikacji - po prostu lać ruch.
• Względnie łatwo wykrywalne. Anomalny skok ruchu jest widoczny na wykresach.
• Atakują infrastrukturę. Cel to kanał, sprzęt sieciowy, stos TCP na serwerze.

Ataki L7: sprytna wojna

Layer 7 to warstwa aplikacji. Tutaj mieszkają HTTP, DNS, i - co ważne dla nas - protokół Minecrafta. Ataki L7 zasadniczo różnią się od L4: zamiast brutalnej siły używają sprytu.

HTTP Flood

Klasyczny atak L7 dla serwerów www. Atakujący wysyła tysiące w pełni poprawnych zapytań HTTP. Z punktu widzenia sieci to legalny ruch - prawidłowe połączenia TCP, poprawne nagłówki HTTP. Ale każde zapytanie zmusza serwer do pracy: czytania z bazy, renderowania strony, wydawania CPU.

Dla Minecrafta to mniej aktualne (panel web i API zazwyczaj nie są pod takim naciskiem), ale jeśli masz Dynmap, Plan lub inny panel web na tym samym serwerze - HTTP flood może go przeciążyć.

Slowloris

Piękny atak, nazwany na cześć powolnego lori. Pomysł: otworzyć mnóstwo połączeń HTTP i wysyłać dane bardzo wolno, nie dając serwerowi zamknąć połączenia. Każde połączenie zajmuje slot na serwerze i w pewnym momencie prawdziwi użytkownicy nie mogą się połączyć, bo wszystkie sloty są zajęte przez powolne "zombie"-połączenia.

To atak z minimalnym ruchem. Dosłownie kilobity na sekundę. Ale efekt jest niszczący - serwer staje się niedostępny.

Bot Joins - bot-joiny w Minecrafcie

I tutaj zaczyna się najciekawsze dla właścicieli serwerów Minecraft. Bot join to atak L7, specyficzny dla protokołu Minecrafta. Atakujący uruchamia tysiące fałszywych klientów, które łączą się z serwerem, przechodzą handshake, czasem nawet się autoryzują - i zużywają zasoby serwera.

Każdy bot-join zmusza serwer do:

• Przyjęcia połączenia TCP
• Obsługi handshake'a Minecrafta
• Sprawdzenia nicku w systemie autoryzacji
• Ewentualnie załadowania chunków wokół spawnu
• Przydzielenia pamięci pod gracza

Kiedy botów są tysiące, serwer idzie w stupor. TPS spada do zera, prawdziwi gracze lagują lub wylatują. Przy tym na poziomie L4 wszystko wygląda normalnie - to przecież zwykłe połączenia TCP na port 25565.

Crafted Packets - niepoprawne pakiety

Jeszcze jeden rodzaj ataku L7: wysyłanie specjalnie skonstruowanych pakietów, które formalnie odpowiadają protokołowi Minecrafta, ale zawierają nieoczekiwane dane. Na przykład za długie stringi, wartości ujemne w polach, gdzie oczekiwane są dodatnie, lub pakiety w niewłaściwej kolejności.

Cel - wywołać exception w kodzie serwera, sprowokować wyciek pamięci lub po prostu zmusić serwer do wydawania CPU na obsługę śmieci. Niektóre exploity tego typu mogą w ogóle crashnąć serwer z jednego pakietu - jeśli w kodzie jest nieobsłużony błąd.

Ataki specyficzne dla protokołu

Protokół Minecrafta ma swoje specyfiki, które atakujący aktywnie eksploatują:

• Status ping flood - masowe zapytania statusu serwera (motd, online). Każde zapytanie jest legalne, ale masowo przeciąża.
• Login flood - wielokrotne próby wejścia, które zmuszają serwer do odwoływania się do Mojang API w celu weryfikacji.
• Chunk exploit - manipulacje zapytaniami o chunki, które zmuszają serwer do generowania i wysyłania ogromnych ilości danych.

Wspólne cechy ataków L7

• Niski ruch. Mogą działać na megabitach albo nawet kilobitach na sekundę.
• Mimikra. Wyglądają jak legalny ruch. Każde pojedyncze zapytanie jest nieodróżnialne od prawdziwego.
• Trudno wykrywalne. Nie można po prostu popatrzeć na objętość ruchu - trzeba analizować zawartość.
• Atakują logikę aplikacji. Cel to CPU, pamięć, specyficzne słabości w kodzie.
• Wymagają znajomości protokołu. Atakujący musi rozumieć, jak działa docelowa aplikacja.

Czym różni się ochrona na każdym poziomie

Skoro ataki są różne, logiczne jest, że i ochrona musi być różna. I tak jest naprawdę - ochrona L4 i L7 używa fundamentalnie różnych podejść.

Ochrona L3/L4

Na tym poziomie wszystko o szybkość. Pakiety trzeba analizować i odrzucać zanim dojdą do aplikacji. Główne narzędzia:

XDP/eBPF. Filtracja na poziomie sterownika sieciowego, jeszcze zanim pakiet trafi do stosu TCP/IP jądra. To najszybszy sposób filtracji - działa z prędkością liniową, miliony pakietów na sekundę. MineGuard używa właśnie tej technologii do filtracji L4.

SYN cookies. Mechanizm, który pozwala obsługiwać pakiety SYN bez przydzielania pamięci. Zamiast zapamiętywać każde półotwarte połączenie, serwer koduje informację w sequence number. Jeśli klient jest prawdziwy i wyśle ACK - połączenie zostanie ustanowione. Jeśli nie - żadne zasoby nie są wydawane.

Rate limiting. Ograniczenie liczby pakietów z jednego IP lub podsieci. Prosta, ale skuteczna metoda - jeśli jeden IP wysyła 100 000 pakietów na sekundę, to wyraźnie nie jest legalny gracz.

Blackhole / null-route. Krok ostateczny: cały ruch na atakowany IP jest wysyłany "donikąd". Atak się kończy, ale i serwer staje się niedostępny. Używane przez dostawców, kiedy atak zagraża innym klientom.

Traffic scrubbing. Ruch jest przekierowywany przez centrum oczyszczania, gdzie złe pakiety są odsiewane, a dobre przepuszczane do serwera. To drogie, ale pozwala obsługiwać ataki w setki gigabitów.

Ochrona L7

Tu potrzeba całkiem innego podejścia. Nie można po prostu liczyć pakietów - trzeba rozumieć, co jest w środku.

Walidacja protokołu. Sprawdzanie, że każdy pakiet odpowiada protokołowi Minecrafta. Prawidłowa struktura, poprawne wartości pól, prawidłowa sekwencja pakietów. Niepoprawne pakiety są odrzucane natychmiast.

Analiza behawioralna. Prawdziwy gracz zachowuje się w określony sposób: ma opóźnienia między działaniami, rusza myszką nie po linii prostej, jego połączenie ma charakterystyczny wzorzec. Bot łączy się natychmiast, wysyła pakiety z maszynową precyzją, nie ma normalnego opóźnienia między działaniami. Dobra ochrona L7 rozpoznaje tę różnicę.

Challenge-response. Zanim przepuścić klienta do serwera, ochrona zadaje mu "pytanie" - coś, co prawdziwy klient obsłuży automatycznie, a prosty bot nie da rady. Dla Minecrafta to może być modyfikacja handshake'a lub sprawdzenie określonych danych przy łączeniu.

Bot detection. Kombinacja heurystyk do określania, czy połączenie jest botem: szybkość wysyłania pakietów, wersja klienta, zachowanie przy łączeniu, reputacja IP.

Connection throttling. Ograniczenie szybkości połączeń z analizą kontekstu. Nie po prostu "nie więcej niż N połączeń na sekundę", tylko "nie więcej niż N połączeń na sekundę od klientów z podejrzanym zachowaniem".

Czemu potrzebne są oba poziomy ochrony

To kluczowy moment, który wielu pomija. Ochrona tylko na L4 lub tylko na L7 to jak zamykać drzwi wejściowe, ale zostawiać okna na oścież.

Tylko ochrona L4

Świetnie poradzisz sobie z SYN flood i UDP flood. Amplifikacja? Nie problem. Ale kiedy do twojego serwera łączy się 5000 botów przez w pełni legalne połączenia TCP - ochrona L4 nawet ich nie zauważy. Każdy bot przeszedł handshake, wysłał poprawne SYN, dostał SYN-ACK, odpowiedział ACK. Wszystko czysto na warstwie transportu. A serwer leży, bo 5000 fałszywych klientów Minecrafta zjadło całą pamięć.

Tylko ochrona L7

Będziesz blokować bot-joiny i niepoprawne pakiety. Ale kiedy na ciebie leje 50 Gbps UDP flood, twoja ochrona L7 nawet nie zobaczy tego ruchu - on zapcha kanał zanim dotrze do twojej aplikacji. Analiza L7 działa z danymi wewnątrz pakietów, ale jeśli pakiety w ogóle nie dochodzą z powodu zapchanego kanału - nie ma czego analizować.

Prawidłowe podejście: ochrona wielowarstwowa

Ruch najpierw przechodzi przez filtr L3/L4, który odcina ataki objętościowe, śmieciowy ruch, pakiety z podrobionych IP. To, co przeszło przez pierwszy filtr, trafia na analizator L7, który sprawdza zawartość - poprawność protokołu, zachowanie klienta, rate limiting na poziomie aplikacji.

To jak lotnisko: najpierw sprawdzają paszport (L4 - czy masz w ogóle prawo tu wejść), potem sprawdzają bagaż (L7 - co dokładnie niesiesz). Jeśli zdjąć którąś z kontroli, bezpieczeństwo się wali.

Prawdziwe przykłady z gamingu

Przykład 1: Klasyczny UDP flood

Klasyczny scenariusz. Konkurencyjny serwer zamawia DDoS na projekt Minecraft. Atak to czysty UDP flood na 30-40 Gbps. Hoster serwera widzi przeciążenie kanału i stawia null-route na IP. Serwer idzie offline na godzinę-dwie, dopóki właściciel nie dogaduje się z hosterem. Rozwiązanie: ochrona L4 przez proxy z wystarczającą przepustowością. Ruch przechodzi przez filtr, śmieci UDP są odsiewane, legalny ruch TCP Minecrafta przechodzi do serwera.

Przykład 2: Atak bot join

Serwer z dobrą ochroną L4. UDP i SYN flood są filtrowane. Ale atakujący przełącza się na bot-joiny: 3000 fałszywych klientów Minecrafta łączy się jednocześnie. Każdy przechodzi TCP handshake (filtr L4 przepuszcza - połączenie jest legalne), wysyła Minecraft handshake packet, zaczyna proces autoryzacji. Serwer próbuje obsłużyć 3000 jednoczesnych loginów, TPS spada do 1-2, gracze lagują i wylatują. Rozwiązanie: filtr L7, który analizuje handshake Minecrafta, rozpoznaje boty po zachowaniu i blokuje je zanim obciążą serwer.

Przykład 3: Atak kombinowany

Najbardziej nieprzyjemny wariant. Atakujący jednocześnie uruchamia UDP flood na 20 Gbps (żeby obciążyć filtr L4), SYN flood (żeby zapełnić tablicę połączeń) i bot-joiny (żeby obciążyć serwer na poziomie aplikacji). Każdy atak z osobna może nie być krytyczny, ale razem tworzą nacisk na wszystkich poziomach. Bez ochrony wielowarstwowej chociaż jeden wektor się przebije.

Przykład 4: Crafted packet exploit

Atakujący znajduje specyficzną podatność w pluginie na serwerze. Wysyła jeden (!) specjalnie skonstruowany pakiet, który wywołuje nieskończoną pętlę w handlerze. Serwer się crashuje. Tu nie potrzeba ani gigabitów, ani tysięcy botów - wystarczy jeden pakiet, ale prawidłowo złożony. Ochrona L4 go przepuści (to zwykły pakiet TCP z danymi). Tylko walidacja L7 protokołu może złapać takie - sprawdzenie, że zawartość pakietu jest poprawna i bezpieczna.

Na co patrzeć przy wyborze ochrony

Kiedy wybierasz ochronę DDoS dla serwera gamingowego, zadaj kilka pytań:

Jaka objętość filtracji L4? Mierzona w Gbps i Mpps. Dla małego serwera 10-20 Gbps wystarcza. Dla poważnego projektu potrzeba 100+ Gbps. Patrz nie tylko na pojemność szczytową, ale i na gwarantowaną.

Czy jest analiza L7? Konkretnie dla protokołu Minecrafta. Ogólny WAF (Web Application Firewall) do tego nie pasuje - potrzebna jest ochrona, która rozumie protokół Minecrafta.

Jakie opóźnienie? Filtracja dodaje latency. Dla gier to krytyczne. Dobra ochrona dodaje 1-5 ms. Zła - 20-50 ms. Różnica jest ogromna dla PvP.

Jak są obsługiwane false positives? Jeśli ochrona blokuje prawdziwych graczy - to gorzej niż w ogóle nie mieć ochrony. Zapytaj o false positive rate.

Czy jest ochrona przed atakami kombinowanymi? Jak system radzi sobie, kiedy ataki L4 i L7 idą jednocześnie?

Podsumowanie

Layer 4 i Layer 7 to nie dwa warianty tego samego. To różne kategorie ataków, które działają na różnych zasadach i wymagają różnych metod ochrony.

Ataki L3/L4 to brutalna siła. Gigabity ruchu, miliony pakietów. Ochrona działa na poziomie sieci: filtracja pakietów, rate limiting, XDP/eBPF.

Ataki L7 to broń punktowa. Mało ruchu, ale każde zapytanie uderza w logikę aplikacji. Ochrona działa na poziomie protokołu: walidacja, analiza behawioralna, challenge-response.

Do normalnej ochrony serwera Minecraft potrzebne są oba poziomy. Nie "albo-albo", tylko "i-i". L4 odcina śmieci, L7 filtruje to, co przeszło przez pierwszą warstwę i próbuje atakować na poziomie aplikacji.

Jeśli twoja obecna ochrona działa tylko na jednym z poziomów - jesteś chroniony tylko w połowie. I atakujący o tym wiedzą.