DDoS-Schutz, Firewall und WAF: Was schützt welchen Teil Ihrer Infrastruktur?
Ein voller Uplink, erschöpfte Verbindungstabellen und überlastete Webanwendungen brauchen unterschiedliche Maßnahmen. So planen Sie die Schutzebenen zusammen.
DDoS-Mitigation, Firewall und Web Application Firewall sind keine austauschbaren Produkte. Sie arbeiten an verschiedenen Stellen: vor der Internetanbindung, zwischen Netzen oder direkt an Webanfragen. Wer Schutz einkauft, sollte deshalb zuerst klären, welche Ressource ausfallen kann und welche legitime Nutzung erhalten bleiben muss. Eine hohe Filterkapazität allein beantwortet weder die Frage nach funktionierenden Logins noch nach erreichbaren Gameservern.
Drei Aufgaben, drei Blickwinkel
| Maßnahme | Typische Aufgabe | Separat zu prüfen |
|---|---|---|
| Netzwerk-Mitigation | Angriffsverkehr vor der Kundenanbindung reduzieren | Protokolle, Filterprofil und Verkehrswege |
| Firewall | Erlaubte Zugriffe zwischen Netzen und Diensten festlegen | Durchsatz und Verbindungszustände |
| WAF / Anwendungsschutz | Webanfragen anhand von Regeln bewerten | HTTP-Abdeckung und Grenzen der Anwendung |
Die Bezeichnung eines Produkts sagt noch nicht, wo es eingebaut ist. Eine lokal betriebene WAF sitzt möglicherweise hinter demselben Uplink wie der Webserver. Ein vorgeschalteter Webproxy hat einen anderen Verkehrsweg. Lassen Sie sich die tatsächliche Einbindung erklären, statt nur Funktionslisten zu vergleichen.
Wenn die Leitung voll ist, muss die Abwehr davor greifen
Volumetrische Angriffe beanspruchen Bandbreite; hohe Paketraten können zusätzlich die Paketverarbeitung belasten. Erreicht dieser Verkehr den Kundenanschluss ungefiltert, teilen sich legitime Nutzer und Angriff dieselbe begrenzte Kapazität. Eine Sperrregel auf dem Zielserver gibt diese bereits belegte Übertragungskapazität nicht rückwirkend frei. Deshalb ist der Ort der Filterung entscheidend.
Ein illustratives Beispiel: Ein Unternehmen betreibt hinter einer Internetanbindung sowohl ein Kundenportal als auch einen UDP-Dienst. Ein Webproxy kann den Weg zum Portal verändern. Der direkt erreichbare UDP-Dienst läuft aber nicht automatisch durch diesen Proxy. Für beide Dienste müssen die Eingänge getrennt betrachtet werden. Das ist eine Planungsfrage, kein Nachweis für die Schutzleistung eines bestimmten Produkts.
Eine Firewall bleibt nötig, hat aber eigene Belastungsgrenzen
Eine Firewall setzt die Zugriffspolitik um: Welche Quelle darf welchen Dienst über welches Protokoll erreichen? Zustandsbehaftete Systeme verfolgen außerdem Verbindungen. Das hilft bei der Zugriffskontrolle, benötigt aber Ressourcen. Ein SYN-Flood kann den TCP-Verbindungsaufbau belasten; RFC 4987 beschreibt verschiedene Gegenmaßnahmen und ihre jeweiligen Grenzen. Daraus folgt keine universelle Einstellung, die auf jedem Router, Server oder jeder Firewall gleich gut funktioniert.
Für die Abnahme sind deshalb mehrere Werte relevant: Bandbreite, Paketrate, neue Verbindungen und die Funktion der Anwendung. Ein unauffälliger Bandbreitengraph schließt ein Problem beim Verbindungsaufbau nicht aus. Prüfen Sie auch, ob Filter legitime Clients versehentlich treffen.
Warum L3/L4-Schutz nicht automatisch HTTP-Schutz bedeutet
Bei HTTP-Angriffen können formal gültige Anfragen teure Funktionen wie Suche oder Anmeldung beanspruchen. Die Ursache liegt dann nicht zwingend in einer vollen Leitung. Eine WAF bewertet Webanfragen anhand ihrer Regeln. Ergänzend können anwendungsbezogene Begrenzungen, Caching und eine Überprüfung ressourcenintensiver Funktionen sinnvoll sein. Ob ein Anbieter diese Aufgaben übernimmt, muss ausdrücklich aus dem Leistungsumfang hervorgehen.
Für HTTPS ist außerdem zu klären, an welcher Stelle verschlüsselte Verbindungen enden und welche Komponente die HTTP-Anfragen tatsächlich prüfen kann. Aus einer allgemeinen Netzwerkfilterung sollte man weder eine WAF noch die Prüfung sämtlicher Anwendungsinhalte ableiten. Für einen beliebigen UDP-Dienst ist eine HTTP-WAF ohnehin nicht die passende Protokollebene.
IPv6 und zweite Upstreams gehören in dieselbe Planung
Listen Sie alle öffentlichen Adressen, Präfixe und Eingangswege auf. Ein geschützter IPv4-Pfad beantwortet nicht automatisch die Frage nach IPv6. Bei mehreren Upstreams kann Verkehr außerdem über eine andere Anbindung eintreffen. Dokumentieren Sie daher Normalbetrieb, Ausfallwege und die mit dem Anbieter abgestimmten Routing-Regeln. Zusätzliche Redundanz ist nur dann hilfreich, wenn ihre Schutzwirkung ebenfalls verstanden ist.
Diese Angaben machen ein Angebot vergleichbar
- Dienste und Nutzerabläufe: etwa Login, API-Aufruf, Spielbeitritt oder Wiederverbindung.
- Erreichbarkeit: IPv4/IPv6-Präfixe, Ports, Protokolle, vorhandene Upstreams und Übergabestandort.
- Schutzumfang: Filterort, behandelte Angriffsarten, Grenzen und zusätzlich benötigte Komponenten.
- Abnahme: freigegebener Testumfang, legitimer Referenzverkehr und gemeinsam definierte Erfolgskriterien.
- Betrieb: zuständige Kontakte, Eskalation und Vorgehen bei Änderungen oder Fehlfilterungen.
AS51202 bietet DDoS-geschützten IP Transit mit Standard oder Premium. Für eine erste Anfrage genügen Standort, gewünschte Bandbreite und eine Beschreibung Ihrer Dienste. Auf dieser Grundlage lassen sich Schutzstufe, Routing und Übergabe abstimmen. Eine WAF oder zusätzliche anwendungsspezifische Leistung sollte nur eingeplant werden, wenn sie ausdrücklich vereinbart ist.
DDoS-Schutz und Anbindung bei AS51202 planen