Przejdź do treści
Ochrona DDoS · Peeryx · 15 Tbps+
Wszystkie poradniki

Ochrona DDoS L3, L4 i L7: co naprawdę jest filtrowane?

Nazwa Anti-DDoS nie określa, jakie ataki są filtrowane na konkretnych usługach. Strona, serwer gry i chroniony tranzyt wymagają innych testów. Oceniaj rzeczywistą drogę ruchu i udokumentowane funkcje, zamiast polegać wyłącznie na dużej łącznej przepustowości.

← Wszystkie poradnikiCubixServ

Zanim zaczniesz

Sporządź listę publicznych IP, portów, protokołów i serwerów źródłowych. Ustal miejsca filtracji i przekazywania. Zachowaj normalne pomiary i warunki usługi do porównania podczas awarii. Przed zmianą dostępu przygotuj przerwę, kopię i powrót do poprzednich ustawień.

L3 dotyczy ruchu sieciowego

Na poziomie sieci analizuje się pakiety IP i wzorce wolumetryczne. Strumień może przeciążyć łącze, zanim obsłuży go aplikacja; wtedy ważna jest filtracja wcześniej w sieci. Łączna przepustowość nie jest przepustowością serwera: podawane przez CubixServ 15 Tbps dotyczą zbiorczej sieci ochronnej, a nie Twojego portu ani gwarancji przeciw każdemu możliwemu rodzajowi ataku.

Atak może próbować wypełnić łącze, wyczerpać stan połączenia lub pochłonąć pracę aplikacji. Kilka efektów może wystąpić jednocześnie. Zidentyfikuj zagrożone zasoby i dotknięty nimi ruch przed wybraniem filtrowania nadrzędnego, kontroli połączeń lub reguł aplikacji.

L4 rozróżnia TCP i UDP

Warstwa transportowa obejmuje inne zachowania połączeń TCP i ruchu UDP. Porty, stany i tempo mogą podlegać regułom. Profil dla strony nie musi pasować do gry. Potwierdź przydzielony port gry i oddziel administrację. Pomyślny test TCP nie dowodzi działania UDP na całej trasie; sprawdzaj protokół faktycznie używany przez aplikację i jej graczy.

Sprawdź także dozwolony czysty ruch, objęte protokoły, chronione adresy i warunki interwencji. Ochrona może obejmować limity zasięgu lub środki powstrzymujące. Roszczenie nieograniczone nie zastępuje warunków technicznych i umowy.

L7 wymaga znajomości aplikacji

Pozornie poprawne żądanie może powodować kosztowną pracę. Proxy HTTP może kontrolować HTTP, ale nie rozumie automatycznie wszystkich protokołów gier. Zapytaj o konkretne endpointy i funkcje. Pobieranie FiveM i połączenie gry wymagają osobnej oceny: zabezpieczony fragment HTTP nie dowodzi ochrony każdej operacji przed atakiem aplikacyjnym ani rozpoznawania wszystkich wzorców określanych jako L7.

FiveM demonstruje różnicę: punkt wejścia HTTP, pobieranie i rozgrywka wymagają spójnej architektury. Chroniona witryna internetowa może pozostać dostępna, gdy gra się nie powiedzie. Możliwości L7 powinny opisywać swój rzeczywisty zakres, a nie twierdzić, że obejmują każde zastosowanie.

Serwer źródłowy jest częścią ochrony

Chroniony adres nie wystarcza, jeżeli niechronione źródło nadal można osiągnąć bezpośrednio. Sprawdź DNS, pliki, administrację i pozostałe porty. Ogranicz źródła dopiero po ustaleniu wszystkich dozwolonych tras. Zbyt szerokie reguły zaufania pozwalają omijać kontrolę, zbyt wąskie blokują prawdziwych użytkowników. Administracja potrzebuje własnego bezpiecznego dostępu, oddzielonego od publicznego ruchu gry i jego profilu filtrowania.

Ograniczanie pochodzenia wymaga zrozumienia legalnych źródeł i usług. Przed filtrowaniem zweryfikuj trasy, ruch powrotny, głos, pliki i administrację. Zbyt szeroka lista dozwolonych ujawnia pochodzenie; zbyt wąski może spowodować awarię. Nie kopiuj ogólnej reguły bez zrozumienia architektury.

Mierz sieć i aplikację razem

Podczas incydentu porównuj ruch, odrzucone pakiety, udane połączenia oraz obciążenie. Zablokowany główny wątek czy baza danych mogą zatrzymać grę przy normalnej sieci. Dodatkowa filtracja nie naprawia kosztownych skryptów. Sam timeout nie dowodzi ataku: zestaw utratę pakietów, trasy, błędy i odstępstwa od normy z różnych źródeł, dotyczące tych samych godzin i tej samej usługi.

Żądaj zdarzeń ze znacznikiem czasu i wyjaśnienia dotyczącego filtrowania w przypadku niepowodzenia prawidłowych połączeń. Rozróżnij fałszywe alarmy, objazdy i obciążenie aplikacji. Nieskoordynowany test obciążenia może pogorszyć samą usługę; uzgodnij aktywną weryfikację z dostawcą i dokładne limity.

Żądaj sprawdzalnych warunków

Potwierdź zakres, przydzielone pasmo, dozwolone usługi, przekazywanie i wsparcie. Ustal, czy potrzebne są konkretne IP, tunel lub zmiana źródła. Testuj cały przebieg z uprawnionymi użytkownikami przed i po wdrożeniu. Dostępna strona nie sprawdza wszystkich gier; obciążające testy i symulacje ataków wymagają wyraźnie uzgodnionego, dozwolonego zakresu, aby nie dotknąć innych klientów oraz operatorów.

Następnie porównaj dostępne plany i ceny dla żądanego zakresu. Przydatny wybór łączy w sobie pojemność sieci, obsługę uwzględniającą protokoły i możliwość diagnozowania incydentów. Żaden system ochrony nie eliminuje konieczności utrzymywania oprogramowania, kont i tworzenia kopii zapasowych.

Co zrobić w Twojej sytuacji

SytuacjaNastępny krok
Gra wykorzystująca UDPPotwierdź port, protokół i profil. Odpowiedź HTTP nie jest pełną kontrolą.
Kosztowne żądania HTTPOceń aplikację, limity i proxy razem. Rezerwa sieciowa nie usuwa pracy dla każdego żądania.
Zewnętrzny serwer źródłowyOpisz dozwolone źródła i drogę powrotną przed ograniczeniem bezpośredniego dostępu.

Oficjalne źródła

Te źródła opisują wymienione protokoły i ustawienia. Sprawdź dokumentację właściwą dla używanej wersji.

  1. RFC Editor / IETF/rfc/rfc4732
  2. NGINX/en/docs/stream/ngx_stream_proxy_module.html
  3. Cfx.re/docs/server-manual/proxy-setup/