Scrubbing Center

Wyspecjalizowana infrastruktura, do której podczas ataku DDoS przekierowuje się ruch (BGP/DNS), żeby odfiltrować pakiety złośliwe i odesłać do źródła tylko ruch prawidłowy.

Scrubbing center (centrum czyszczenia ruchu) to wyspecjalizowana infrastruktura sieciowa — własna lub w chmurze — do której podczas ataku DDoS przekierowuje się ruch płynący do chronionych zasobów. Cel jest jeden: odfiltrować pakiety złośliwe i odesłać dalej wyłącznie ruch uznany za prawidłowy (tzw. clean traffic). Centrum stoi pomiędzy internetem a siecią docelową niczym bramka kontrolna na wjeździe: bada ruch w warstwie sieciowej, transportowej i aplikacji, oddziela anomalie od zwykłych sesji i odsyła oczyszczone pakiety z powrotem, zwykle tunelem GRE lub dedykowanym łączem.

Jak działa scrubbing center?

Pełny cykl obrony przed DDoS z użyciem centrum czyszczenia ma cztery etapy: wykrycie ataku, przekierowanie ruchu, filtrowanie i odesłanie oczyszczonego ruchu.

  1. Wykrycie (detekcja). Systemy monitoringu przepływów (NetFlow, sFlow, IPFIX) albo inspekcja ruchu w locie zauważają nagły skok wolumenu, nietypowy rozkład protokołów lub znane sygnatury ataku i sygnalizują przekroczenie progu.
  2. Przekierowanie (ang. diversion). Ruch kierowany do atakowanego zakresu adresów zostaje odchylony do centrum — przez ogłoszenie tras BGP, zmianę rekordów DNS albo regułę BGP FlowSpec.
  3. Filtrowanie. W centrum ruch przechodzi kilka warstw kontroli: filtrowanie po wolumenie (progi i sygnatury), sprawdzenie poprawności protokołów, ograniczanie tempa (rate limiting), analizę zachowania i anomalii, reputację adresów IP oraz testy typu „udowodnij, że jesteś człowiekiem” (challenge-response) w warstwie aplikacji. Pakiety złośliwe są odrzucane.
  4. Odesłanie (reinjekcja). Oczyszczony ruch wraca do sieci docelowej osobną drogą — najczęściej tunelem GRE, łączem cross-connect, MPLS/L2VPN albo trasą BGP (clean pipe) — tak, by nie wpadł z powrotem w pętlę przekierowania.

Wszystkie zdarzenia są zapisywane w logach — na potrzeby raportów, analizy po ataku i zgodności z przepisami.

Jak ruch trafia do scrubbing center?

Stosuje się trzy podstawowe metody przekierowania, często łączone ze sobą:

  • Przekierowanie BGP. Dostawca usługi ogłasza zakres adresów klienta ze swojej sieci (ASN) trasą bardziej szczegółową — np. /24 zamiast operatorskiego /22. Internet wybiera trasę bardziej dokładną, więc ruch płynie do centrum zamiast do data center klienta. Chroni całe podsieci i nie zależy od protokołu aplikacji.
  • Przekierowanie DNS. Rekord A lub CNAME usługi wskazuje na adres centrum, więc ruch (zwykle HTTP/HTTPS dla strony lub aplikacji) trafia do czyszczenia już na poziomie nazwy domeny. Wymaga niskiego TTL (czasu ważności wpisu); skuteczność zależy od tego, czy serwery DNS rzeczywiście respektują ten krótki TTL.
  • BGP FlowSpec. Centralny sterownik rozsyła do routerów brzegowych reguły dopasowane do konkretnych przepływów (adres źródła i celu, protokół, porty) wraz z akcją — odrzuć, ogranicz tempo, przekieruj. Pozwala filtrować punktowo, zamiast odcinać cały zakres adresów, co ogranicza szkody uboczne.

Po co tunel GRE przy odsyłaniu ruchu?

Po oczyszczeniu ruch nie może wrócić tą samą trasą BGP, którą wciągnięto go do centrum — zapętliłby się. Tunel GRE pakuje oczyszczone pakiety w nową „kopertę” z zewnętrznym adresem IP, zachowując oryginalne adresy źródła i celu. Router brzegowy klienta zdejmuje tę kopertę i dostarcza pakiet tak, jakby nic się nie wydarzyło. Wadą jest narzut około 24 bajtów na pakiet (dla IPv4), który zmniejsza maksymalny rozmiar pakietu (MTU) na drodze powrotnej. Jeśli ruch ICMP jest zablokowany albo zawiedzie mechanizm Path MTU Discovery, grozi to cichą utratą pakietów. Dlatego w praktyce obniża się MTU interfejsu GRE (np. do ~1400 bajtów) i stosuje tzw. MSS clamping. Alternatywy bez tunelu to cross-connect, MPLS/L2VPN oraz zwrot BGP typu clean pipe. Przy architekturze anycast filtrowanie odbywa się na brzegu sieci, więc odsyłanie ruchu w ogóle odpada.

Tryb always-on a on-demand

Centra czyszczenia uruchamia się na dwa sposoby:

  • Always-on (stale włączony). Cały ruch przez cały czas przechodzi przez centrum, więc obrona rusza natychmiast — nie ma okna na ustalanie nowych tras. Kosztem jest stałe, dodatkowe opóźnienie i wyższy rachunek za przepustowość.
  • On-demand (na żądanie). Ruch płynie normalnie, a przekierowanie do centrum włącza się dopiero po wykryciu ataku. W spokojnym czasie nie ma dodatkowego opóźnienia, ale samo uruchomienie i rozpropagowanie tras trwa zwykle od około 2 do 10 minut — w tym oknie część ataku może dotrzeć do celu.

Scrubbing center a blackholing (RTBH)

Blackholing w wariancie RTBH (Remotely Triggered Black Hole, zdalnie wyzwalana czarna dziura) polega na ogłoszeniu trasy, która kieruje cały ruch do atakowanego adresu w nicość (null0) — pakiety są odrzucane hurtem. To skutecznie odciąża łącze, ale w praktyce realizuje cel atakującego: do hosta przestaje docierać zarówno ruch złośliwy, jak i ten prawdziwy. Scrubbing center działa odwrotnie — zamiast odrzucać wszystko, rozdziela ruch i przepuszcza prawidłowe sesje. RTBH bywa stosowany jako koło ratunkowe lub uzupełnienie, gdy wolumen ataku przekracza pojemność centrum. Pokrewny source-based RTBH odrzuca ruch po adresie źródłowym, a BGP FlowSpec daje filtrowanie dokładniejsze niż klasyczny RTBH.

Scrubbing dedykowany a inline

Określenie „scrubbing inline” bywa używane w dwóch znaczeniach. Jako tryb uruchomienia oznacza always-on — cały ruch zawsze przez centrum. Jako lokalizacja oznacza urządzenie wpięte wprost w ścieżkę ruchu w sieci klienta. Takie urządzenie działa lokalnie, bez odsyłania ruchu na zewnątrz, ale jest ograniczone pojemnością łącza i nie obroni przed atakiem wolumetrycznym, który zapcha łącze do internetu. Wariant zewnętrzny (dedykowane centrum) oddaje czyszczenie infrastrukturze o dużej przepustowości i wciąga ruch dopiero po wykryciu ataku — kosztem czasu na ustalenie tras.

Dlaczego scrubbing center jest ważny dla bezpieczeństwa i monitoringu?

Skuteczność czyszczenia zależy od jakości wykrywania ataku po stronie sieci, a nie tylko od pojemności filtrów. Telemetria przepływów (NetFlow/sFlow/IPFIX) i znajomość normalnego obrazu ruchu (baseline) pozwalają zauważyć anomalię i przekierować ruch, zanim atak zapcha łącze. Dlatego scrubbing współpracuje z monitoringiem sieci, systemami NDR i zespołem SOC. Z punktu widzenia bezpieczeństwa liczą się też:

  • ataki podszywające się pod prawdziwe połączenia (np. SYN/ACK flood) — żeby odróżnić je od prawdziwych sesji TCP, centrum potrzebuje sprytniejszej analizy, której proste filtrowanie na brzegu nie wykona;
  • ataki na warstwę aplikacji (HTTP flood, powolne ataki typu slow-rate) o małym wolumenie, niewidoczne dla progów liczących sam ruch — wychodzą na jaw dopiero w analizie zachowania i testach challenge-response;
  • różne trasy „tam” i „z powrotem” przy przekierowaniu i odsyłaniu ruchu, co może oślepiać urządzenia śledzące stan połączeń i utrudniać korelację zdarzeń w SOC;
  • ruch szyfrowany — zajrzenie do treści HTTPS wymaga rozszyfrowania TLS w centrum, czyli przeniesienia tam wrażliwych kluczy i poszerzenia obszaru, któremu trzeba ufać;
  • logi i raporty z centrum jako źródło danych do analizy po ataku, dostrajania progów i dokumentacji zgodności.

Dowiedz się więcej