Co to jest zapora stanowa?
Zapora stanowa śledzi sesje i wie, czy pakiet należy do nawiązanego połączenia. Dlatego odrzuca ruch DDoS bez reguły pod każdy wektor.
Ostatnia aktualizacja:
Zapora stanowa (stateful firewall) to filtr, który pamięta kontekst. Zamiast oceniać każdy pakiet w oderwaniu od reszty, utrzymuje tablicę aktywnych sesji i przy każdym pakiecie sprawdza, czy pasuje on do połączenia, które faktycznie zostało nawiązane. To pozornie drobna różnica, ale zmienia całą logikę obrony: decyzja przestaje zależeć od tego, jak pakiet wygląda, a zaczyna od tego, czy ktoś się go spodziewał.
Stanowo kontra bezstanowo
Filtr bezstanowy ma do dyspozycji tylko to, co widzi w pojedynczym pakiecie: adresy, porty, protokół, flagi. Reguła typu "przepuść ruch na port 443" jest prosta i szybka, ale nie odróżnia odpowiedzi na Twoje zapytanie od pakietu, który przyszedł znikąd. Zapora stanowa zna historię: wie, że wcześniej wyszło zapytanie, na które ta odpowiedź pasuje, albo że nie wyszło nic takiego.
Dla bezpieczeństwa ma to konkretne przełożenie. Filtr bezstanowy trzeba wyposażyć w regułę pod każdy znany wektor ataku, a więc zawsze jest o krok za atakującym. Zapora stanowa odrzuca cały ruch spoza kontekstu z definicji, jeszcze zanim ktokolwiek nazwie nowy wektor.
Dlaczego to działa akurat przeciwko DDoS
Ogromna część ruchu DDoS to pakiety, które nie należą do żadnej rozmowy. Pakiet ACK bez wcześniejszego SYN, odpowiedź DNS albo NTP, o którą nikt nie pytał, fragment bez nagłówka, ruch ze sfałszowanego adresu źródłowego: wszystko to nie ma szans dopasować się do wpisu w tablicy sesji. Odrzucenie takiego pakietu nie wymaga rozpoznania ataku ani napisania sygnatury, wynika wprost z zasady działania.
Najlepiej widać to przy ruchu odbitym. Odpowiedzi odbite od CDN czy publicznych resolwerów mają całkowicie prawdziwe adresy źródłowe, więc czarna lista IP albo ich nie złapie, albo zablokuje przy okazji usługi, z których korzystają Twoi użytkownicy. Stan sesji daje trzecie wyjście: źródło zostaje osiągalne, a odpada wyłącznie pakiet, którego nikt nie zamawiał.
Koszt: tablica stanów jest zasobem
Śledzenie sesji kosztuje pamięć, a tablica stanów sama bywa celem. Klasyczny SYN flood wypełnia ją półotwartymi połączeniami i to właśnie ona pada jako pierwsza. Dlatego dobrze zbudowana zapora stanowa łączy connection tracking z mechanizmami, które nie tworzą stanu na pakiet nieuwierzytelniony: SYN cookies odkładają utworzenie wpisu do momentu powrotu poprawnego ACK, a SYN proxy kończy handshake we własnym imieniu. Rozmiar tablicy i tempo wygasania wpisów są parametrami, które trzeba dobrać do skali ruchu, a nie zostawić na wartościach domyślnych.
Gdzie taka zapora powinna stać
Zapora stanowa przed pojedynczym serwerem chroni ten serwer, dopóki łącze do niego ma zapas. Przy ataku wolumetrycznym wąskim gardłem staje się uplink, a wtedy nie ma znaczenia, jak dobry filtr stoi za nim. Dlatego operatorzy przenoszą filtrowanie stanowe na brzeg sieci, wyżej niż port klienta, tam gdzie jest jeszcze pojemność, żeby wchłonąć ruch ataku i odrzucić go, zanim zacznie konkurować z ruchem prawdziwych użytkowników.
Najczęstsze pytania
Czy zapora stanowa poradzi sobie z atakami w warstwie 7?
Częściowo. Atak aplikacyjny prowadzony przez poprawnie nawiązane sesje HTTPS z definicji pasuje do tablicy stanów, więc sam stan sesji go nie zatrzyma. Potrzebna jest dodatkowo filtracja w warstwie 7, która patrzy na treść żądania, a nie tylko na nagłówek pakietu. Stan sesji zdejmuje natomiast całą warstwę 3 i 4, czyli zdecydowaną większość wolumenu.
Czy śledzenie sesji zwiększa opóźnienia?
W praktyce nie w sposób mierzalny dla użytkownika, o ile filtr jest zwymiarowany pod ruch, który obsługuje. Sprawdzenie wpisu w tablicy to operacja rzędu nanosekund. Problemem bywa nie samo opóźnienie, lecz przepełnienie tablicy, i to jej rozmiar oraz polityka wygasania wpisów decydują o zachowaniu pod obciążeniem.