K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / playbook-ddos

Playbook C — DDoS i dostępność

Reagowanie na ataki odmowy dostępu (DDoS) — wolumetryczne (L3/L4), protokołowe oraz aplikacyjne (L7). Poziom 1 (cyber klasyczny), priorytet domyślny P1 — SLA reakcji do 24h, ale realnie liczy się reakcja w minutach, bo trwa przestój usługi.

DDoS wygrywa się przed atakiem — architekturą, nie w trakcie ataku panicznymi regułami.

ENISA klasyfikuje ataki na dostępność (availability), w tym DDoS, jako jedno z czołowych zagrożeń, często o motywacji haktywistycznej i skierowane w sektor finansowy oraz administrację PUBLIC CLAIM. DDoS bywa też zasłoną dymną (smokescreen) maskującą równoległe włamanie — nigdy nie traktuj go w izolacji.

Problem — czym jest atak na dostępność

Rozwiązania — architektura odporna

CDN / WAF

Warstwa brzegowa absorbująca ruch, ukrywająca origin. WAF filtruje L7, reguły dla znanych wzorców, ochrona ścieżek krytycznych (logowanie, płatności).

Rate limiting

Limity żądań per IP / sesja / token / endpoint. Progresywne opóźnianie i twarde odcięcie przy przekroczeniu. Osobne, ostrzejsze limity dla kosztownych API.

Bot protection

Wyzwania (JS challenge, proof-of-work, CAPTCHA warunkowo), reputacja IP, fingerprinting, wykrywanie botnetów i narzędzi typu stress-test.

Cache statyki

Agresywne cache'owanie treści statycznej na brzegu — odciąża origin, redukuje powierzchnię wrażliwą na L7.

Osobny status page

Strona statusu na niezależnej infrastrukturze (inny dostawca/CDN), by komunikować dostępność nawet gdy główny serwis leży.

Ścieżka zgłoszeń awaryjnych

Kanał kontaktu do SOC i klientów niezależny od atakowanej usługi (telefon, osobna domena, status page).

Failover DNS

Niski TTL, zdolność szybkiego przełączenia na zapasowego dostawcę scrubbingu / origin. Anycast rozprasza ruch geograficznie.

Monitoring 5xx / latency

Alerty na wzrost błędów 5xx, opóźnień, saturacji łącza i połączeń — wczesna detekcja przed pełnym przestojem.

Geoblokada (kryzysowo)

Blokada regionów tylko jako środek kryzysowy i tymczasowy — może odciąć legalnych klientów, więc nie jako domyślna kontrola.

Plan komunikacji

Gotowe szablony komunikatów (klienci, regulator, media), próg i osoby decyzyjne, zdefiniowane zawczasu.

Zasada: geoblokada i twarde odcięcia to narzędzia kryzysowe, nie stałe. Nadmierne blokowanie w trakcie ataku samo staje się odmową usługi dla legalnych klientów — pogłębiając skutek, który atakujący chciał osiągnąć.

Playbook — 8 kroków reakcji P1

POTWIERDŹTRYB OCHRONYRATE LIMITOGRANICZ APIREAD-ONLYKOMUNIKATMETRYKITEST
Krok 1 — Potwierdź, że to atak (nie awaria). Odróżnij DDoS od skoku legalnego ruchu (promocja, dzień wypłat) i od awarii własnej. Analiza źródeł, geografii, wzorca żądań, korelacja z monitoringiem 5xx/latency. Sprawdź, czy nie jest to smokescreen — przejrzyj alerty EDR/SIEM pod kątem równoległej aktywności.
Krok 2 — Włącz tryb ochrony (under attack). Aktywacja trybu wzmożonej ochrony na CDN/WAF, skierowanie ruchu przez scrubbing, zaostrzenie reguł brzegowych. Ukryj origin, jeśli jeszcze wystawiony.
Krok 3 — Zastosuj rate limiting / challenge. Progresywne limity per IP/sesja/token, wyzwania JS/PoW dla podejrzanego ruchu, blokada reputacyjnie złych źródeł i wzorców botnetu. Chroń w pierwszej kolejności ścieżki krytyczne (logowanie, płatności).
Krok 4 — Ogranicz kosztowne API. Wyłącz/zawęź najdroższe operacje (ciężkie zapytania, eksporty, wyszukiwanie) na czas ataku. Wprowadź kolejkowanie i twardsze limity dla endpointów podatnych na L7.
Krok 5 — Dashboard read-only / tryb awaryjny. Przełącz nieistotne funkcje w tryb tylko-do-odczytu lub degradację kontrolowaną (graceful degradation), by utrzymać rdzeń usługi. Priorytet: dostępność krytycznych funkcji bankowych.
Krok 6 — Komunikat. Aktualizacja status page (na niezależnej infrastrukturze), komunikat do klientów i — jeśli usługa kluczowa — do regulatora. Ton rzeczowy, bez ujawniania szczegółów obrony wykorzystywalnych przez atakującego.
Krok 7 — Zbieraj metryki i dowód. Rejestruj wolumen, wektory, źródła, czas trwania, skuteczność mitigacji. Materiał → Evidence Layer, do zgłoszenia CERT PL / dostawcy scrubbingu i ewentualnie organów ścigania.
Krok 8 — Test obciążeniowy i deeskalacja. Po ustaniu ataku: kontrolowane wycofanie restrykcji, weryfikacja pełnej wydajności, test obciążeniowy potwierdzający powrót do normy. Post-mortem → korekta progów, reguł i architektury → odporność +1.

Flagi prawne i eskalacja

WarunekFlagaObowiązek (ramka / norma)
Zakłócenie usługi kluczowej / ważnejNIS2_RELEVANTWczesne ostrzeżenie do CSIRT w 24h, zgłoszenie 72h, raport końcowy — gdy istotne zakłócenie dostępności
Infrastruktura krytycznaCRITICAL_INFRAObowiązki sektorowe, koordynacja z organem właściwym
DDoS jako zasłona dla włamaniaEskalacja do właściwego playbooka (ransomware / wyciek / podatności) — traktuj jako incydent złożony
Wymuszenie (ransom DDoS)LAW_ENFORCEMENTZawiadomienie CERT PL i organów ścigania; nie płać, dokumentuj żądanie
Sektor finansowy: zakłócenie dostępności usług bankowych może być raportowalne również do organu nadzoru (KNF) w ramach wymogów odpornościowych i operacyjnych — potwierdź progi z Legal/DPO na etapie kroku 6.

Metryki dostępności SYMULACJA

Dane demonstracyjne (demo). Wartości ilustrują format panelu, nie są rzeczywistymi pomiarami środowiska odbiorcy.
< 5 min
Czas do trybu ochrony SYMULACJA
od potwierdzenia ataku
99.95%
Cel dostępności usług krytycznych SYMULACJA
SLA usługi
TTL 60s
DNS failover SYMULACJA
szybkie przełączenie
< 1%
Odsetek 5xx pod atakiem SYMULACJA
próg alarmu

Powiązane strony

Ciągłość / DR

Failover i utrzymanie usług. → Playbook L

Podatności

Gdy DDoS maskuje eksploatację. → Playbook D

Threat Map

Wizualizacja aktywnych ataków. → Threat Map

Response Board

Status wykonania playbooka. → Response Board

Uwaga metodyczna: odwołania do ENISA to publicznie znane sygnały krajobrazu zagrożeń (PUBLIC CLAIM), nie potwierdzone incydenty w środowisku odbiorcy. Ramki NIS2 to treść regulacji (norma). Metryki oznaczone SYMULACJA są przykładowe (demo).