Was ist ein Denial-of-Service-Angriff?

Ein Denial-of-Service-Angriff (DoS) soll einen Dienst für berechtigte Nutzer unbenutzbar machen oder seine Qualität erheblich verschlechtern. Dafür erschöpft der Angreifer Bandbreite, Verbindungen, Rechenleistung, Speicher oder eine knappe Anwendungsressource. Nicht jede Überlastung ist ein Angriff: Fehlkonfigurationen, Softwarefehler und legitime Lastspitzen können ähnlich aussehen.

Was unterscheidet DoS und DDoS?

Bei einem DoS stammt die schädliche Last im Wesentlichen aus einer Quelle oder einem kontrollierten Pfad. Ein Distributed Denial of Service (DDoS) verteilt sie auf viele Systeme, etwa kompromittierte Geräte eines Botnetzes. Verteilte Angriffe sind schwerer durch einzelne IP-Sperren abzuwehren und können mehr Bandbreite erzeugen. Auch ein einzelner Client kann jedoch durch besonders teure Anfragen eine Anwendung wirksam überlasten.

Welche Arten von Angriffen gibt es?

Mehrstufige Kampagnen kombinieren Kategorien oder wechseln die Methode, sobald eine Abwehr greift. Eine hohe Request-Zahl allein beschreibt den Angriff daher nicht ausreichend.

Was sind Reflection und Amplification?

Bei einem Reflection-Angriff fälscht der Angreifer die Quelladresse des Opfers und sendet Anfragen an fremde, öffentlich erreichbare UDP-Dienste. Diese antworten dem Opfer. Ist die Antwort deutlich größer als die Anfrage, entsteht zusätzlich Amplification. Offene oder falsch konfigurierte DNS-, NTP- und andere UDP-Dienste wurden dafür wiederholt missbraucht. Betreiber verhindern ihre Beteiligung durch sichere Konfiguration; Provider können gefälschte Quelladressen durch Ingress- und Egress-Filterung erschweren.

Wie erkennt man einen DoS-Angriff?

Warnzeichen sind ungewöhnliche Bandbreite, stark steigende Verbindungs- oder Request-Zahlen, erschöpfte Worker und Pools, hohe Latenz, Timeouts sowie viele Fehlercodes. Für die Einordnung müssen Netzwerk-Telemetrie, Load-Balancer-, CDN-, Server- und Anwendungsmetriken zusammengeführt werden. Herkunft, Zielpfad, Header, Antwortkosten und zeitliches Muster helfen, einen Angriff von einem erfolgreichen Marketingereignis oder internen Fehler zu unterscheiden.

Wie lassen sich Dienste schützen?

• Kapazität und Architektur: Redundante Anbindungen, verteilte Bereitstellung, Caching und kontrolliertes Load Balancing.
• Vorgelagerte Abwehr: CDN, Anycast oder DDoS-Scrubbing können Last aufnehmen, bevor die eigene Leitung voll ist.
• Begrenzungen: Rate Limiting, Quotas, Timeouts, Größenlimits und begrenzte Parallelität pro kostenintensivem Vorgang.
• Anwendungsschutz: Teure Endpunkte optimieren, Ergebnisse cachen, asynchron verarbeiten und anonyme von authentifizierter Nutzung trennen.
• Resilienz: Kritische Funktionen priorisieren, Abhängigkeiten absichern und kontrolliert degradieren statt vollständig auszufallen.

Eine Web Application Firewall kann bekannte Muster auf Anwendungsebene filtern, schützt aber keine bereits ausgelastete Internetanbindung und ersetzt keine belastbare Architektur.

Codebeispiel: Arbeit pro Request begrenzen

Verwundbar: Der Client kann eine beliebig große Ergebnismenge und teure Beziehungen anfordern.

$orders = Order::with($request->input('include', []))
    ->limit($request->integer('limit'))
    ->get();

Sicherer:

$limit = max(1, min($request->integer('limit', 25), 100));

$orders = $request->user()->orders()
    ->select(['id', 'status', 'total', 'created_at'])
    ->cursorPaginate($limit);

Zusätzlich gehören Query-Timeouts, Größenlimits, begrenzte Parallelität und Rate Limiting auf den Endpunkt. Kein einzelnes Anwendungslimit schützt gegen volumetrische Angriffe, es verhindert aber unnötige Ressourcenverstärkung im Backend.

Wie reagiert man im Ernstfall?

1. Incident-Prozess aktivieren, Angriff und gewöhnliche Betriebsstörung parallel untersuchen.
2. Provider, CDN oder Schutzdienst mit vorbereiteten Kontakten und aktuellen Zielinformationen einbinden.
3. Gezielte Filter, Limits oder Challenges einsetzen und Auswirkungen auf legitime Nutzer beobachten.
4. Kritische Funktionen priorisieren und Statuskommunikation über unabhängige Kanäle bereitstellen.
5. Nach dem Angriff Zeitlinie, Kosten, Umgehungen und Kapazitätsgrenzen auswerten.

Darf die Belastbarkeit getestet werden?

Last- und Resilienztests sind sinnvoll, benötigen aber eine ausdrückliche Freigabe, abgestimmte Grenzwerte, Monitoring, Abbruchkriterien und die Zustimmung betroffener Hosting- oder Cloudanbieter. Ein gewöhnlicher Penetrationstest umfasst destruktive DoS-Tests meist nicht. Produktionsnahe Tests sollten zunächst kontrollierte Lastprofile und einzelne Engpässe prüfen, statt ungezielt maximale Last zu erzeugen.