DoS ist kein Ausfall. Es ist ein Dietrich für „Fail-Open“
Elementrica
Der Server lief. Er antwortete auf Pings, das Monitoring stand auf Grün, die Last war normal. Nur war sein EDR-Agent seit einem halben Jahr tot, weil die MySQL-Binlogs still und leise die Systempartition auf null gefüllt hatten. Aus Sicht des Dashboards war alles in Ordnung. Der Server „lebte“ - nur war ihm sein einziges Auge ausgestochen worden.
Das ist keine Geschichte über Ausfallzeiten. Der Ausfall hat nichts „lahmgelegt“ in dem Sinne, wie wir DoS üblicherweise verstehen. Er hat eine Schutzmaßnahme in einen Zustand versetzt, in dem der Angreifer tun konnte, was er wollte - ohne einen einzigen Alarm.
Und genau das ist der Kern. Eine Denial-of-Service-Schwachstelle ist selten das Ziel an sich. Häufiger ist sie das Werkzeug, mit dem man ein System in einen ungeschützten Zustand zwingt, also Fail-Open. Wenn Sie DoS aus Tests ausklammern, verzichten Sie nicht nur auf „Verfügbarkeit“. Sie lassen eine Frage ungetestet: Was tut Ihre Infrastruktur in dem Moment, in dem ein Baustein umfällt?
Warum alle DoS ausklammern (und warum das verständlich ist)
Ich sage es offen: Auch wir klammern DoS standardmäßig aus dem Umfang aus. In der Produktion will niemand, dass ein Sicherheitsaudit am Freitagnachmittag das Bestellsystem lahmlegt. Das ist vernünftige Vorsicht. Der Kunde schläft ruhig, die Umgebung steht, alle sind zufrieden.
Das Problem ist, was wir dabei mit ausklammern. Wir prüfen nicht, wie sich die Anwendung im Fehlerfall verhält. Dazu kommt eine zweite, bequeme Überzeugung: „Dem Angreifer geht es ohnehin um Daten, nicht um einen lahmgelegten Server.“ Klingt klug. Ist falsch. Ein moderner Angreifer muss keinen raffinierten Exploit bauen, wenn er einfach eine Komponente zum Absturz bringen kann, die im Fehlerfall standardmäßig Verkehr durchlässt, statt ihn zu blockieren.
Fall 1: das CMS, das nach dem Datenbankausfall „vergaß“, dass es installiert war
Wir sind einmal auf ein verbreitetes CMS in einer Konfiguration gestoßen, die bei fehlender Datenbankverbindung annahm, die Installation habe nie stattgefunden. Klingt harmlos, bis man es mit dem Datei-Upload-Mechanismus zusammenbringt.
Wir überhäuften den Server mit Anfragen, bis die Datenbank nicht mehr antwortete. In diesem Moment zeigte uns die Anwendung brav den Installationsassistenten. Danach ging es bergab. Der Assistent zeigte die Zugangsdaten aus der Konfigurationsdatei an, ließ uns unsere eigene, externe Datenbank anbinden und die „Installation“ auf einem laufenden Server abschließen. Das Ergebnis: ein Administratorkonto. Von dort das Hochladen eines Plugins mit einer PHP-Datei, und wir haben Remote Code Execution auf der Maschine.
Ein beispielhafter Angriffsablauf (konzeptionell):
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
Öffentlich zeigt sich derselbe Mechanismus in WordPress (CVE-2020-28037, Versionen vor 5.5.2). Im Fehlerfall konnte is_blog_installed() „nein, ich bin nicht installiert“ zurückgeben, was den Assistenten und den Weg zur RCE öffnete. MITRE stuft das als CWE-754 ein, also unsachgemäße Behandlung einer Ausnahmesituation. Ein hübscher Name für „wir haben nicht geprüft, was passiert, wenn die Datenbank ausfällt“.
Fall 2: das EDR, das eine volle Festplatte getötet hat
Dieser Fall ist kein Pentest, sondern eine Incident-Response-Analyse. Angreifer versuchen selten, ein modernes EDR frontal zu durchbrechen. Viel bequemer ist es, es still zum Stillstand zu bringen, sodass der Administrator keinen einzigen Alarm sieht.
Auf den Ausfall selbst sind wir schon eingangs eingegangen. Ich ergänze ein Detail, das ich damals ausgelassen habe: Der Agent ist nicht einfach so ausgefallen. Er blieb bei einem routinemäßigen Versuch hängen, die Verbindung zur zentralen Konsole zu erneuern, weil auf der vollen Partition kein Platz mehr für temporäre Dateien und Logs war. Der Server war sechs Monate lang blind. Schlimmer noch: Nachdem Platz frei wurde, kam der Prozess nicht von allein wieder hoch. Sie kaufen ein teures EDR, führen ein SIEM ein, streichen Ihr Dashboard grün... und eine einzige unüberwachte Partition entwaffnet Sie.
Das ist nichts Exotisches. Das ist ein klassischer Integrationsfehler.
Unit-Tests lügen, Integrationstests sagen die Wahrheit
Alle diese Fälle haben eines gemeinsam. Jeder Baustein funktioniert für sich korrekt. Erst ihr Zusammenspiel im Fehlerfall erzeugt das Loch.
Ein Unit-Test prüft, ob connect_to_db() einen Fehler zurückgibt, wenn die Datenbank schweigt. Tut sie. Grün. Ein Integrationstest fragt, was das gesamte System tut, wenn diese Funktion genau dann einen Fehler zurückgibt, wenn jemand die Startseite aufruft. Und es zeigt sich: Das System öffnet den Installer.
Es kursiert ein Meme mit Küchenschubladen. Jede lässt sich für sich perfekt herausziehen. Nur blockieren sie sich gegenseitig, und man bekommt keine einzige auf. Unit-Tests bestanden, Integrationstest durchgefallen. In der Sicherheit sieht es genauso aus, nur bekommen Sie statt einer klemmenden Schublade eine offene Tür.
Fail-Open ist überall, nicht nur in CMS
Das Muster „im Fehlerfall durchlassen“ steckt in vielen Verteidigungsschichten. Genau das macht DoS zu einem wirklich bequemen Werkzeug.
Im Januar 2026 wurde bekannt, dass sich die WAF von Cloudflare eine Zeit lang über den Pfad /.well-known/acme-challenge/ umgehen ließ. Die Logik für ACME-Zertifikate deaktivierte die WAF-Inspektion für Anfragen, die auf diesen Pfad passten, um die Zertifikatserneuerung nicht zu blockieren. Man konnte einen schädlichen Payload in eine solche Anfrage packen und direkt den Origin treffen, unter Umgehung des gesamten Perimeterschutzes. Fail-Open wie aus dem Lehrbuch. Cloudflare hat die Lücke bereits im Oktober 2025 geschlossen, aber das Beispiel bleibt.
Dieselbe Logik gilt bei MFA. Viele Unternehmen führen FIDO-Schlüssel ein und lassen „für alle Fälle“ einen schwächeren Fallback: einen SMS-Code oder eine App. Bei einem Adversary-in-the-Middle-Angriff kann der Angreifer dem Browser des Opfers einreden, der FIDO-Server sei nicht erreichbar. Der Browser stuft aus Rücksicht auf den Nutzerkomfort von selbst auf die schwächere Methode herab. Der sicherste Standard sinkt auf das Niveau von SMS-Phishing, weil jemand den Fallback so entworfen hat, dass er ungefragt anspringt.
Einige Fälle und bekannte Muster, bei denen der Ausfall eines Elements den Angreifer hereinlässt:
Was zu tun ist (Rat für CISOs und CTOs)
Dieses ganze Problem hat einen Namen im CWE-Katalog. Es ist CWE-636, „Not Failing Securely“. Das Prinzip ist nicht neu, man muss sich nur daran halten.
- Entwerfen Sie Sicherheitskomponenten so, dass sie im Fehlerfall Verkehr abweisen. Der Standardzustand nach einem Fehler soll „deny“ lauten, nicht „allow“.
- Erweitern Sie den Pentest um einen kontrollierten DoS auf dem Staging. Es geht nicht darum, die Produktion lahmzulegen, sondern darum, einen Fehler gezielt auszulösen (die Datenbank kappen, die Festplatte füllen) und zu prüfen, ob ein Installationsassistent oder ein toter Agent auftaucht.
- Behandeln Sie einen Alarm über eine volle Festplatte auf einer Maschine mit EDR oder SIEM als kritisch. Fehlender Platz schaltet dort Ihre Sichtbarkeit im Netz ab, nicht nur das Schreiben von Logs.
- Wenn Sie FIDO nutzen, erzwingen Sie eine zusätzliche Identitätsprüfung beim Herabstufen auf eine schwächere Methode. Der Fallback darf nicht beim ersten Kommunikationsfehler von selbst anspringen.
- Fragen Sie Ihre Entwickler direkt: Was tut die Autorisierung, wenn genau dieser Microservice 30 Sekunden lang nicht antwortet? Lautet die Antwort „ich weiß nicht“, haben Sie ein Thema für den nächsten Sprint.
Die interessantesten Dinge in der Sicherheit passieren nicht, wenn alles läuft, sondern wenn etwas ausfällt. Wer über diese Zustände nachdenkt, bevor es ein Angreifer für ihn tut, gehört zur Minderheit, die aus gutem Grund ruhig schläft und nicht trotz allem.
Also eine Frage zum Schluss: Wann hat bei Ihnen zuletzt jemand geprüft, nicht ob das System ausfällt, sondern was der Rest Ihrer Schutzmaßnahmen tut, sobald eine davon umfällt?
Bei uns heißt das kontrollierter DoS auf dem Staging. Vereinbaren Sie eine kostenlose Beratung: Wir zeigen Ihnen, wie man einen Ausfall sicher auslöst und prüft, ob Ihre Kontrollen Verkehr standardmäßig blockieren, statt ihn durchzulassen.