DoS to nie tylko brak dostępności. To wytrych do trybu „fail-open”
Elementrica
Serwer działał. Pingował, monitoring świecił na zielono, obciążenie w normie. Tyle że jego agent EDR był martwy od pół roku, bo binlogi MySQL po cichu zapchały partycję systemową do zera. Z perspektywy dashboardu wszystko grało. Serwer „żył”, tylko jego jedyne oko było wyłupione.
To nie jest historia o przestoju. Awaria niczego nie „położyła” w sensie, w jakim zwykle rozumiemy DoS. Ona przełączyła zabezpieczenie w stan, w którym atakujący mógł robić, co chciał, bez jednego alertu.
I to jest sedno. Podatność Denial of Service rzadko bywa celem samym w sobie. Częściej jest narzędziem, którym wymusza się na systemie przejście w stan niezabezpieczony, czyli fail-open. Jeśli wykluczasz DoS z testów, nie odpuszczasz sobie samej „dostępności”. Zostawiasz nieprzetestowane pytanie, co robi Twoja infrastruktura w chwili, gdy jeden klocek pada.
Dlaczego wszyscy wykluczają DoS (i dlaczego to zrozumiałe)
Powiem wprost: my też domyślnie wykluczamy DoS z zakresu. Na produkcji nikt nie chce, żeby audyt bezpieczeństwa położył system zamówień w piątek po południu. To rozsądna ostrożność. Klient śpi spokojnie, środowisko stoi, wszyscy zadowoleni.
Problem w tym, że przy okazji wykluczamy coś jeszcze. Nie sprawdzamy, jak aplikacja zachowuje się w awarii. A do tego dochodzi drugie, wygodne przekonanie: „atakującemu i tak zależy na danych, nie na zamuleniu serwera”. Brzmi mądrze. Jest błędne. Współczesny napastnik nie musi budować finezyjnego exploita, jeśli może po prostu doprowadzić do awarii komponentu, który w chwili błędu domyślnie przepuszcza ruch, zamiast go blokować.
Przypadek 1: CMS, który po awarii bazy „zapomniał”, że jest zainstalowany
Trafiliśmy kiedyś na popularny CMS w konfiguracji, która przy braku połączenia z bazą uznawała, że instalacja nigdy się nie odbyła. Brzmi niewinnie, dopóki nie zestawisz tego z mechanizmem wgrywania plików.
Zasypaliśmy serwer żądaniami tak, żeby baza przestała odpowiadać. W tym momencie aplikacja grzecznie pokazała nam kreator instalacji. Dalej było z górki. Kreator wyświetlił dane dostępowe z pliku konfiguracyjnego, pozwolił podpiąć naszą własną, zewnętrzną bazę i dokończyć „instalację” na działającym serwerze. Efekt: konto administratora. Stamtąd wgranie wtyczki z plikiem PHP i mamy zdalne wykonanie kodu na maszynie.
Przykładowy przepływ ataku (konceptualnie):
GET /index.php HTTP/1.1 Host: target-cms.com # System próbuje łączyć się z DB -> Timeout/DoS -> is_blog_installed() returns FALSE # Serwer zwraca stronę instalacyjną zamiast błędu 500
Publicznie ten sam mechanizm widać w WordPressie (CVE-2020-28037, wersje przed 5.5.2). Funkcja is_blog_installed() przy błędzie potrafiła zwrócić „nie, nie jestem zainstalowany”, co otwierało kreatora i drogę do RCE. MITRE klasyfikuje to jako CWE-754, czyli nieprawidłową obsługę sytuacji wyjątkowej. Ładna nazwa na „nie sprawdziliśmy, co się stanie, jak padnie baza”.
Przypadek 2: EDR, którego zabił pełny dysk
Ten przypadek to nie pentest, tylko analiza powłamaniowa. Napastnicy rzadko próbują przebić się przez nowoczesny EDR frontalnie. Znacznie wygodniej doprowadzić do tego, żeby po cichu przestał działać, tak żeby administrator nie zobaczył ani jednego alertu.
Do samej awarii wróciliśmy już na wejściu. Dodam szczegół, który wtedy pominąłem: agent nie padł ot tak. Zawiesił się przy rutynowej próbie odświeżenia połączenia z konsolą centralną, bo na zapchanej partycji zabrakło miejsca na pliki tymczasowe i logi. Serwer był ślepy przez sześć miesięcy. Co gorsza, po zwolnieniu miejsca proces nie wstał sam. Kupujesz drogi EDR, wdrażasz SIEM, malujesz sobie dashboard na zielono... i rozbraja cię jedna niepilnowana partycja.
To nie egzotyka. To klasyczny błąd integracji.
Testy jednostkowe kłamią, testy integracyjne mówią prawdę
Wszystkie te przypadki łączy jedno. Każdy klocek z osobna działa poprawnie. Dopiero ich interakcja w stanie awarii tworzy dziurę.
Test jednostkowy sprawdza, czy funkcja connect_to_db() zwraca błąd, gdy baza milczy. Zwraca. Zielono. Test integracyjny pyta, co robi cały system, kiedy ta funkcja zwróci błąd akurat wtedy, gdy ktoś wchodzi na stronę główną. I okazuje się, że system otwiera instalator.
Krąży taki mem z szufladami w kuchni. Każda z osobna wysuwa się idealnie. Tyle że blokują się nawzajem i nie da się otworzyć żadnej. Testy jednostkowe zdane, test integracyjny oblany. W bezpieczeństwie wygląda to identycznie, tylko zamiast zablokowanej szuflady dostajesz otwarte drzwi.
Fail-open jest wszędzie, nie tylko w CMS-ach
Mechanizm „w razie awarii przepuść” siedzi w wielu warstwach obrony. To robi z DoS-u naprawdę wygodne narzędzie.
W styczniu 2026 ujawniono, że przez pewien czas WAF Cloudflare dawał się obejść ścieżką /.well-known/acme-challenge/. Logika obsługi certyfikatów ACME wyłączała inspekcję WAF dla żądań pasujących do tej ścieżki, żeby nie blokować odnawiania certyfikatów. Można było upakować w takie żądanie złośliwy payload i uderzyć prosto w origin, z pominięciem całej ochrony obwodowej. Fail-open jak z podręcznika. Cloudflare załatał lukę jeszcze w październiku 2025, ale przykład został.
Ta sama logika działa przy MFA. Wiele firm wdraża klucze FIDO, zostawiając „na wszelki wypadek” słabszy fallback: kod SMS albo aplikację. W ataku typu adversary-in-the-middle napastnik może wmówić przeglądarce ofiary, że serwer FIDO jest niedostępny. Przeglądarka, dbając o wygodę użytkownika, sama zjeżdża na słabszą metodę. Najbezpieczniejszy standard schodzi do poziomu phishingu na SMS, bo ktoś zaprojektował fallback tak, żeby włączał się bez pytania.
Kilka przypadków i znanych wzorców, w których awaria jednego elementu wpuszcza atakującego do środka:
Co z tym zrobić (rady dla CISO i CTO)
Cały ten problem ma swoją nazwę w katalogu CWE. To CWE-636, „Not Failing Securely”. Zasada nie jest nowa, wystarczy się jej trzymać.
- Projektuj komponenty bezpieczeństwa tak, żeby w razie awarii odrzucały ruch. Domyślny stan po błędzie ma brzmieć „deny”, a nie „allow”.
- Rozszerz pentest o kontrolowany DoS na stagingu. Nie chodzi o kładzenie produkcji, tylko o sztuczne wywołanie błędu (odetnij bazę, zapełnij dysk) i sprawdzenie, czy nie wyskoczy kreator instalacji albo martwy agent.
- Alarm o zapełnieniu dysku na maszynie z EDR lub SIEM traktuj jak krytyczny. Brak miejsca tam wyłącza Twoją widoczność w sieci, nie tylko utrudnia zapis logów.
- Jeśli używasz FIDO, wymuś dodatkową weryfikację tożsamości przy zejściu na słabszą metodę. Fallback nie może włączać się sam przy pierwszym błędzie komunikacji.
- Pytaj deweloperów wprost: co robi autoryzacja, jeśli ten konkretny mikroserwis przestanie odpowiadać na 30 sekund? Jeśli odpowiedź brzmi „nie wiem”, masz temat na najbliższy sprint.
Najciekawsze rzeczy w bezpieczeństwie dzieją się nie wtedy, gdy wszystko działa, tylko wtedy, gdy coś pada. Jeśli myślisz o tych stanach, zanim zrobi to za Ciebie atakujący, jesteś w mniejszości, która śpi spokojnie z powodu, a nie mimo wszystko.
Więc pytanie na koniec: kiedy ostatnio ktoś u Ciebie sprawdził nie to, czy system pada, lecz co robią pozostałe zabezpieczenia w chwili, gdy jedno z nich padnie?
U nas nazywa się to kontrolowanym DoS-em na stagingu. Umów bezpłatną konsultację: pokażemy, jak bezpiecznie wywołać awarię i sprawdzić, czy Twoje zabezpieczenia domyślnie blokują ruch, zamiast go przepuszczać.