Jak działa ochrona DDoS: wyjaśniamy prostymi słowami

Uruchamiasz serwer Minecraft, zbierasz audytorium, wszystko idzie dobrze. A potem pewnego ranka serwer po prostu przestaje odpowiadać. Gracze narzekają na timeouty. Konsola zawieszona. Hosting pisze o "anormalnym ruchu". Atakują cię.

Pierwsze pytanie, które się pojawia: "Jak się przed tym bronić?" Drugie: "A jak ta ochrona w ogóle działa?"

Na drugie pytanie odpowiemy dzisiaj. Bez skomplikowanej terminologii, z analogiami z życia i konkretnymi przykładami.

Co się dzieje podczas ataku DDoS

Na początek rozkminimy sam atak. DDoS to kiedy tysiące (albo miliony) źródeł jednocześnie wysyła ruch na twój serwer. Cel prosty: przeciążyć łącze, procesor albo pamięć tak, żeby prawdziwi gracze nie mogli się połączyć.

Wyobraź sobie restaurację na 50 miejsc. Zwykle przychodzi 30-40 gości, wszystkim starczy stolików. A teraz wyobraź sobie, że ktoś wynajął 5000 osób, żeby jednocześnie przyszły do wejścia i zajęły całą przestrzeń. Prawdziwi goście fizycznie nie mogą wejść. Restauracja działa, kucharze gotują, ale do środka nikt nie trafi.

DDoS działa dokładnie tak samo. Twój serwer żyje, Minecraft włączony, ale łącze zapchane śmieciowym ruchem.

Krok pierwszy: przekierowanie DNS - chowamy prawdziwy adres

Pierwsze, co robi każda ochrona DDoS - chowa prawdziwy adres IP twojego serwera. Jeśli atakujący zna twój prawdziwy IP, może słać ruch bezpośrednio, omijając każdą ochronę.

Jak to działa? Zmieniasz rekordy DNS swojej domeny (na przykład play.myserver.com) tak, żeby wskazywały nie na twój serwer, tylko na sieć ochrony. Dla Minecrafta to zwykle rekord SRV, który kieruje graczy na węzeł ochronny.

Analogia: zamiast podawać ludziom swój domowy adres, podajesz adres agencji ochroniarskiej. Wszystkie listy przychodzą najpierw tam, sprawdzają je, i tylko prawdziwą korespondencję przekazują do ciebie.

Gracz wpisuje: play.myserver.com
DNS odpowiada: "idź na 104.167.24.XX" (adres ochrony)
Gracz łączy się z węzłem ochronnym
Ochrona sprawdza i przekazuje na prawdziwy serwer

Ważne: jeśli ktoś już zna twój prawdziwy IP - samo przekierowanie DNS nie pomoże. Dlatego po podłączeniu ochrony często zalecają zmianę IP serwera.

Krok drugi: scrubbing - oddzielamy czysty ruch od śmiecia

Kiedy cały ruch idzie przez węzeł ochronny, zaczyna się najciekawsze - scrubbing (z angielskiego scrubbing - "czyszczenie").

Wyobraź sobie wydobycie złota. Poszukiwacz bierze miskę z piaskiem i przemywa ją wodą. Piasek i brud spłukują się, a grudki złota zostają. Scrubbing działa na tej samej zasadzie: śmieciowy ruch się odsiewa, a pakiety od prawdziwych graczy idą dalej.

W praktyce wygląda to tak:

Ruch przychodzący: 50 Gbps
  |
  [Filtr L3/L4] - odsiewa 95% śmiecia
  |
  Ruch pośredni: 2.5 Gbps
  |
  [Filtr L7] - sprawdza protokół
  |
  Czysty ruch: 200 Mbps -> twój serwer

Z 50 gigabitów na sekundę ataku do twojego serwera dociera tylko 200 megabitów legalnego ruchu. Reszta jest odrzucana na różnych poziomach filtrowania.

Filtrowanie L3/L4: pierwsza linia obrony

L3 i L4 to warstwy modelu sieciowego. L3 (warstwa sieciowa) to adresy IP. L4 (warstwa transportowa) to porty TCP/UDP i połączenia.

Filtrowanie na tych warstwach jest najszybsze. Działa z nagłówkami pakietów i nie zagląda do środka. Co się tu sprawdza:

Ograniczenie prędkości (rate limiting). Jeden adres IP nie może wysyłać 10 000 pakietów na sekundę do gry w Minecrafta. Jeśli wysyła - znaczy, że to nie gracz. Blokujemy.

Walidacja protokołu. Minecraft działa po TCP. Jeśli na port 25565 przychodzą pakiety UDP - to na pewno nie gracz. Odrzucamy.

Sprawdzenie TCP-handshake. Normalne połączenie TCP zaczyna się od trójstronnego handshake'u: SYN - SYN-ACK - ACK. Wiele ataków (SYN flood) wysyła tylko pakiety SYN i nie kończy handshake'u. Filtr używa SYN cookies albo SYN proxy, żeby sprawdzić: czy klient naprawdę zamierza nawiązać połączenie?

Czarne listy. Znane adresy botnetów, centra danych, z których nigdy nie łączą się prawdziwi gracze - to wszystko blokowane na wejściu.

Analogia: to jak ochroniarz przy wejściu do klubu, który sprawdza, czy masz bilet (TCP handshake), czy nie jesteś na czarnej liście, i czy nie próbujesz przejść przez ścianę zamiast drzwi (niepoprawny protokół).

Filtrowanie L7: głęboka weryfikacja

L7 - warstwa aplikacji. Tu filtr już zagląda do wnętrza pakietów i sprawdza, czy ruch wygląda jak prawdziwa gra w Minecrafta.

Klient Minecraft komunikuje się z serwerem po określonym protokole. Przy podłączaniu wysyła pakiet handshake z wersją protokołu, adresem serwera i portem. Potem idzie żądanie login z imieniem gracza. Wszystko to ma ścisły format.

Co sprawdza filtr L7:

Format pakietów. Pakiety Minecrafta mają określoną strukturę: długość, ID pakietu, dane. Jeśli pakiet nie pasuje do formatu - jest podrobiony.

Kolejność pakietów. Prawdziwy klient najpierw wysyła handshake, potem login start, potem czeka na odpowiedź serwera. Bot może wysyłać pakiety w złej kolejności albo zbyt szybko.

Wersja protokołu. Jeśli twój serwer jest na 1.21, a pakiet deklaruje wersję 1.7 z podejrzaną strukturą - to powód do sprawdzenia.

Analiza behawioralna. Prawdziwy gracz po podłączeniu zaczyna się ruszać, wysyła pakiety z określoną częstotliwością. Bot może się podłączyć i milczeć, albo odwrotnie - spamować pakietami.

Pakiet od prawdziwego gracza:
[długość: 16][ID: 0x00][wersja: 769][adres: play.myserver.com][port: 25565][stan: 2]
-> Format poprawny, przepuszczamy

Pakiet od bota:
[śmieciowe bajty][losowe dane]
-> Format nieprawidłowy, odrzucamy

Challenge-response: sprawdzamy, czy to człowiek

Niektóre systemy ochrony idą dalej i aktywnie sprawdzają podłączających się. Nazywa się to challenge-response - system rzuca "wyzwanie", a klient musi poprawnie odpowiedzieć.

Dla Minecrafta może to działać tak:

Sprawdzenie handshake'u. Ochronne proxy udaje serwer i prowadzi TCP-handshake samodzielnie. Jeśli klient nie odpowiada poprawnie - połączenie nie jest przekazywane na prawdziwy serwer.

Weryfikacja pingu. Przed wpuszczeniem na serwer system może sprawdzić, czy klient potrafi poprawnie obsłużyć żądania status protokołu Minecraft. Prawdziwy klient potrafi, prymitywny bot - nie.

CAPTCHA. W kontekście webowym (panel zarządzania, mapa serwera) to zwykła captcha. Dla samego Minecrafta może to być etap pośredni: gracza podłącza się do lobby, gdzie trzeba wykonać prostą akcję, zanim trafi na główny serwer.

Architektura reverse proxy dla serwerów gier

Teraz porozmawiajmy o tym, jak to wszystko jest zebrane razem. Główne podejście architektoniczne to reverse proxy.

Co to jest? Reverse proxy to serwer, który stoi między internetem a twoim prawdziwym serwerem. Wszystkie połączenia idą przez niego. Dla graczy jest przezroczysty - nawet nie wiedzą, że łączą się nie bezpośrednio.

Gracz -> [Internet] -> [Ochronne proxy] -> [Twój serwer]
                           |
                           +-- Filtrowanie
                           +-- Weryfikacja protokołu
                           +-- Rate limiting

Dla Minecrafta reverse proxy działa na poziomie TCP. Przyjmuje połączenie od gracza, sprawdza pierwsze pakiety, i jeśli wszystko gra - otwiera połączenie do prawdziwego serwera i zaczyna przekazywać dane w obie strony.

Kluczowa zaleta: twój prawdziwy serwer w ogóle nie widzi ruchu atakującego. Pracuje spokojnie, obsługując tylko zwalidowane połączenia. Obciążenie od ataku spada na węzeł ochronny, który jest specjalnie zaprojektowany do tego.

Tunele GRE: kiedy potrzebny własny IP

Czasami reverse proxy nie pasuje. Na przykład masz skomplikowaną konfigurację sieciową, kilka serwerów za jednym IP, albo potrzebujesz pełnej kontroli nad ruchem. Wtedy używa się tuneli GRE.

GRE (Generic Routing Encapsulation) to "tunel" między węzłem ochronnym a twoim serwerem. Działa tak: węzeł ochronny przyjmuje cały ruch, filtruje go, a potem zawija czysty ruch w pakiety GRE i wysyła do ciebie. Twój serwer rozpakowuje pakiety GRE i widzi oryginalne adresy IP graczy.

Analogia: wyobraź sobie opancerzony konwój. Listy (pakiety) pakują do zabezpieczonego kontenera (enkapsulacja GRE), wiozą bezpieczną trasą (tunel), a na miejscu wyjmują i rozdają odbiorcom.

Internet -> [Węzeł ochronny] --(tunel GRE)--> [Twój serwer]
               |                                      |
           Filtrowanie                          Dekapsulacja
           na miejscu                           + obsługa

Plusem tunelu GRE jest to, że twój serwer dostaje prawdziwe adresy IP graczy (wygodne do banów i geolokalizacji). Minus - dodatkowe koszty i konieczność konfiguracji po obu stronach.

Anycast: jeden adres - wiele serwerów

Duże sieci ochronne używają technologii Anycast. Pomysł prosty: ten sam adres IP jest ogłaszany z kilku punktów świata przez BGP (protokół routingu internetu).

Kiedy gracz z Niemiec łączy się z twoim serwerem, jego ruch automatycznie trafia na najbliższy węzeł ochronny - na przykład we Frankfurcie. Gracz z Brazylii trafi na węzeł w Sao Paulo. A ruch atakujący z Azji pójdzie na węzeł w Tokio.

Gracz (Berlin) --------> Węzeł Frankfurt -----> Twój serwer
Gracz (Moskwa) --------> Węzeł Amsterdam -----> Twój serwer
Atak (Szanghaj) --------> Węzeł Tokio [BLOCKED]
Atak (różne IP) -----> Rozdziela się po wszystkich węzłach

Daje to dwie zalety:

1. Atak się rozkłada. Zamiast 100 Gbps walących w jeden punkt, rozdzielają się między dziesiątki węzłów. Każdy węzeł dostaje tylko część ataku, z którą radzi sobie łatwo.

2. Mniej opóźnień. Gracze łączą się z najbliższym węzłem, a nie lecą przez pół świata. Ping niższy, gra płynniejsza.

Jak działa MineGuard: ogólny schemat

Teraz zobaczmy, jak to wszystko działa konkretnie w MineGuard.

Kiedy podłączasz serwer do MineGuard, dzieje się tak:

1. Konfiguracja DNS. Twoja domena zaczyna wskazywać na węzły ochronne MineGuard zamiast prawdziwego serwera.

2. Filtrowanie na wejściu. Cały przychodzący ruch przechodzi przez system filtrowania, który pracuje na kilku warstwach jednocześnie.

3. Proxy. Zwalidowany ruch jest przekazywany na twój prawdziwy serwer. Dla graczy proces jest całkowicie przezroczysty - łączą się jak zwykle.

4. Monitoring. System stale analizuje wzorce ruchu i dostosowuje filtry w czasie rzeczywistym.

Architektonicznie węzeł ochronny MineGuard zawiera kilka komponentów:

• Filtr pakietów na poziomie kernela (XDP/eBPF) - odcina najgrubszy śmieć z maksymalną prędkością, jeszcze zanim pakiet trafi do stosu sieciowego
• TCP-proxy - prowadzi handshake i sprawdza ważność połączeń TCP
• Analizator protokołu - rozkłada pakiety Minecrafta i weryfikuje ich strukturę
• Silnik behawioralny - analizuje wzorce połączeń i wykrywa botnety

Co się dzieje, kiedy zaczyna się atak: krok po kroku

Przejdźmy przez konkretny scenariusz. Twój serwer działa normalnie, online 100 graczy. I nagle zaczyna się atak.

Sekunda 0-1. Atakujący uruchamia botnet. 50 000 botów zaczyna wysyłać ruch na IP twojego serwera (które w rzeczywistości - IP węzła ochronnego MineGuard). Ruch przychodzący skacze z 200 Mbps do 40 Gbps.

Sekunda 1-2. Filtr pakietów (XDP) widzi gwałtowny wzrost ruchu. Pakiety z nieprawidłową strukturą, UDP-flood na port TCP, pakiety ze znanych sieci botnetów - wszystko to jest dropowane natychmiast. 90% ataku odcięte w sekundę.

Sekunda 2-5. Bardziej "sprytne" boty, które próbują nawiązać połączenie TCP, przechodzą przez TCP-proxy. SYN cookies odsiewają tych, którzy nie kończą handshake'u. Z pozostałych 4 Gbps ruchu przechodzą tylko prawdziwe połączenia TCP - około 500 Mbps.

Sekunda 5-10. Boty, które nauczyły się robić TCP-handshake, spotykają się z weryfikacją protokołu Minecraft. Muszą wysłać prawidłowy pakiet handshake, prawidłowy pakiet login, odpowiedzieć na żądania serwera. Większość botów tego nie potrafi. Zostaje 50 Mbps, i to już prawie całkowicie prawdziwi gracze.

Sekunda 10+. Analiza behawioralna dobija ostatnich botów. Jeśli bot się podłączył, ale zachowuje się nietypowo (nie rusza się, nie wysyła potrzebnych pakietów, łączy się 100 razy na minutę z jednego IP) - też zostaje odcięty.

Rezultat. Atakujący wydaje pieniądze na botnet, generuje 40 Gbps ruchu, a na twoim serwerze nic się nie dzieje. 100 graczy dalej gra, może z mikroskopijnym wzrostem pingu o parę milisekund. Prawdopodobnie nawet nie zauważą, że był atak.

Dlaczego nie można po prostu zablokować wszystkich podejrzanych IP

Rozpowszechnione przekonanie: "zbanujmy po prostu wszystkie złe IP". Problem w tym, że:

1. Botnety używają prawdziwych urządzeń. To zainfekowane komputery i routery zwykłych ludzi. Ich adresy IP to zwykli domowi dostawcy. Jeśli zablokujesz całą podsieć, ucierpią prawdziwi gracze z tego samego miasta.

2. Adresy IP się zmieniają. Botnet z 50 000 maszyn może używać setek tysięcy różnych adresów IP. Zablokujesz jedne - pojawią się inne.

3. Atakujący się adaptują. Nowoczesne botnety próbują różnych metod ataku i automatycznie przełączają się, jeśli jedna metoda nie działa.

Dlatego skuteczna ochrona pracuje nie tylko z listami IP, ale i analizuje zachowanie ruchu w czasie rzeczywistym.

Ograniczenia ochrony DDoS: o czym warto wiedzieć

Żadna ochrona nie jest idealna. Oto uczciwa lista ograniczeń:

Dodaje opóźnienie. Proxy między graczem a serwerem - to dodatkowy hop. Zwykle to 1-5 ms, ale dla niektórych graczy to ważne.

Nie chroni przed atakami od wewnątrz. Jeśli atakujący już jest na twoim serwerze (exploit w pluginie, zhakowany panel) - zewnętrzna ochrona DDoS nie pomoże.

Wyciek IP. Jeśli twój prawdziwy IP stał się znany (zapomniałeś go schować, świeci się w logach, ktoś znalazł przez Shodana) - atakujący może bić bezpośrednio, omijając ochronę.

Fałszywe alarmy. Agresywne filtry mogą czasami blokować legalnych graczy. Dobra ochrona pozwala dostrajać czułość.

Podsumowanie

Ochrona DDoS to nie magiczny przycisk "zrób bezpiecznie". To wielowarstwowy system, który:

• Chowa prawdziwy IP twojego serwera
• Przyjmuje cały ruch na siebie przez przekierowanie DNS
• Filtruje śmieć na warstwach L3/L4 (adresy IP, protokoły, rate limiting)
• Weryfikuje protokół Minecraft na warstwie L7
• Używa challenge-response do weryfikacji klientów
• Przekazuje tylko czysty ruch na twój serwer przez proxy albo tunel GRE
• Używa anycast do rozkładu obciążenia

Każda warstwa odcina swój kawałek śmiecia, i do twojego serwera dociera tylko prawdziwy ruch gry. Właśnie tak działa każda poważna ochrona DDoS - i MineGuard też.