Ochrona Anty-DDoS dla ISP i hostingu

Zapora stanowa (stateful firewall), a taką jest nasz silnik SkyGuard, nie ocenia każdego pakietu w oderwaniu od reszty, tylko utrzymuje tablicę aktywnych sesji i wie, czy dany pakiet należy do połączenia, które faktycznie się nawiązało. Większość ruchu DDoS to pakiety spoza kontekstu: ACK bez wcześniejszego SYN, odpowiedzi DNS lub NTP, o które nikt nie pytał, fragmenty bez nagłówka, ruch ze sfałszowanych adresów źródłowych. Filtr bezstanowy musi dla nich mieć osobną regułę, a zapora stanowa odrzuca je z definicji, bo nie pasują do żadnej znanej sesji. Dlatego skuteczność nie zależy od tego, czy zdążyliśmy dopisać regułę pod konkretny wektor ataku.

Dostępne są dwa tryby: always-on i on-demand. W always-on filtr stoi na stałe w ścieżce ruchu i pracuje przez całą dobę. W on-demand sam decydujesz, które prefiksy obejmujemy ochroną i kiedy ją włączamy. Istotne jest to, co dzieje się pod spodem: nie mamy urządzenia, które budzi się po alarmie z detekcji. SkyGuard, nasz własny silnik filtrujący, działa nieprzerwanie i weryfikuje każdy przechodzący pakiet, więc mitygacja nie ma etapu rozruchu i zaczyna się przy pierwszym pakiecie ataku.

Trasę zmienia i nie ma co tego owijać w bawełnę: chroniony ruch musi iść przez naszą sieć, bo tam stoi filtr. Różnica polega na tym, dokąd go prowadzimy. Nie oddajemy go obcemu dostawcy ani nie wyprowadzamy do centrum scrubbingowego w innym kraju, tylko czyścimy we własnej infrastrukturze w Polsce, a wpinamy się tam, gdzie już jesteś: cross-connectem w Equinix WA, Centrum LIM, DataHouse albo Korbanku, VLAN-em w THINX, TPIX, POZIX, we WRIX, w 1-IX albo 1PL, albo tunelem GRE. Trasa zostaje krajowa i krótka, a samo filtrowanie nie dokłada już przeskoków. Przy wycenie możemy wspólnie sprawdzić na traceroute, jak ta trasa wygląda z Twojej sieci.

Warstwy 3 i 4 to floody SYN, ACK, RST i FIN, amplifikacja i reflection UDP (DNS, NTP, memcached, SSDP, CLDAP), ataki fragmentacyjne, floody o wysokim pps oraz ruch ze sfałszowanych źródeł. Do tego dochodzi filtracja w warstwie 7, gdzie patrzymy na treść żądania, a nie tylko na nagłówek pakietu, więc odrzucamy zapytania udające ruch użytkownika, ale bez sensu dla chronionej usługi. Zakres filtracji L7 ustalamy przy uruchomieniu, bo zależy od protokołów, które prowadzisz.

Tak, i to jest jeden z powodów, dla których filtrujemy stanowo. W ataku odbitym atakujący podszywa się pod adres Twojego abonenta i wysyła zapytania do węzłów CDN, otwartych resolwerów DNS, serwerów NTP, memcached, CLDAP czy SSDP. Odpowiedzi lecą do Ciebie z prawdziwych, zaufanych adresów, więc czarna lista IP albo ich nie złapie, albo zablokuje przy okazji prawdziwy ruch z CDN do abonentów. Zapora stanowa rozstrzyga to inaczej: nikt z Twojej sieci nie wysłał zapytania, do którego pasowałaby ta odpowiedź, więc pakiet odpada, a te same sieci CDN pozostają dla abonentów w pełni dostępne.

Radzimy sobie z nimi dobrze, ponieważ nasza ochrona nie opiera się na progach per adres IP, a to właśnie one są słabym punktem przy carpet bombingu. W tym ataku zalew rozkłada się cienką warstwą na setki adresów w prefiksie, więc żaden pojedynczy adres nie wygląda podejrzanie i klasyczna detekcja milczy, choć suma nasyca uplink. My sprawdzamy każdy pakiet wobec stanu sesji na całym prefiksie naraz, a rozłożenie ataku na więcej adresów nie sprawia, że pakiety zaczynają należeć do prawdziwych połączeń. Nie musimy przy tym wrzucać do blackhole'a setek adresów ani przekierowywać całego prefiksu.

Tak, i przy CGNAT ma szczególne znaczenie, bo za jednym adresem publicznym stoją setki abonentów. Atak na taki adres to awaria dla nich wszystkich naraz, a blackhole u operatora nadrzędnego oznacza dokładnie to samo. My filtrujemy ruch przed Twoim portem i nie odcinamy adresu, więc pula CGNAT dalej obsługuje ruch abonentów, podczas gdy ruch ataku jest odrzucany.

Najprościej jest wziąć ochronę razem z naszym Chronionym IP Tranzytem, bo wtedy filtrujemy ruch, który i tak przez nas idzie. Możliwe są też scenariusze mieszane, gdzie prowadzimy tylko część ruchu albo tylko wskazane prefiksy w trybie on-demand. Napisz, jak wygląda Twoja obecna topologia i którzy operatorzy Cię obsługują, a powiemy wprost, co da się zrobić bez przebudowy sieci.

Nie. Nie jesteśmy filtracją zbudowaną na RTBH ani FlowSpec. RTBH oznacza wrzucenie atakowanego adresu do blackhole'a, czyli odcięcie go razem z całym ruchem legalnym, co w praktyce daje atakującemu dokładnie ten skutek, o który mu chodziło. FlowSpec rozsyła przez BGP zgrubne reguły, które trafiają w cały prefiks, port albo protokół. My pracujemy na poziomie pojedynczej sesji i pojedynczego pakietu: atakowany adres pozostaje osiągalny, a odrzucane jest tylko to, co nie należy do nawiązanego połączenia.

Dla sieci, w których jeden atakowany adres psuje usługę wielu klientom naraz: operatorów ISP, hostingów i serwerów dedykowanych, kolokacji, hostingu gier, platform e-commerce i SaaS oraz operatorów VoIP. W takich sieciach nie da się chronić pojedynczej usługi, bo atak nasyca łącze albo tablice stanów zanim dotrze do celu. Filtrowanie musi się odbyć wyżej, na brzegu sieci operatorskiej.

Nie jest to warunek konieczny. Jeśli masz własny ASN i przestrzeń adresową, ogłaszamy Twoje prefiksy przez BGP i ochrona obejmuje cały prefiks, a nie pojedyncze usługi. Jeśli nie masz własnych zasobów, możemy udostępnić adresację w ramach usługi. W obu przypadkach stosujemy filtrowanie tras i walidację RPKI.

Napisz do nas z profilem ruchu, listą usług do ochrony i docelową lokalizacją. Przygotujemy profil filtrowania dopasowany do Twoich protokołów, uzgodnimy progi i wyceną obejmiemy port oraz zakontraktowane pasmo. Sama konfiguracja to zwykle kwestia dni roboczych, a nie tygodni, o ile port lub cross-connect jest już dostępny.