Auf dieser Seite
Das Wichtigste
- Der echte BruchpunktVolumetrische Angriffe brechen zuerst Kapazität. Applikative Angriffe erschöpfen Dienstlogik oder eine Ressource hinter dem Netz.
- Andere VerteidigungDie Antwort kann geschützter IP-Transit, Scrubbing, sauberer Tunnel, Reverse Proxy, Protokollfilterung oder mehrere Schichten sein.
- Häufiges RisikoWer beide Kategorien verwechselt, baut Schutz, der zu spät, zu schwer oder schädlich für legitime Nutzer ist.
Definition des Problems: zwei Angriffe auf unterschiedliche Schwächen
Ein volumetrischer DDoS-Angriff versucht vor allem, die Leitung zu füllen. Er nutzt massiven, verteilten und manchmal verstärkten Traffic, um Transit, Portkapazität, Mitigationsqueues oder Paketverarbeitung zu sättigen. Der Origin-Server könnte technisch noch antworten, erhält aber keinen nutzbaren Traffic mehr: Der Link ist voll, Latenz steigt, legitime Pakete gehen verloren und Zwischengeräte arbeiten in einem gefährlichen Bereich.
Ein applikativer DDoS-Angriff zielt stattdessen auf Dienstlogik. Er kann weniger Bandbreite verwenden, aber wertvolle Ressourcen verbrauchen: HTTP-Verbindungen, teure Suchen, Login-Endpunkte, API-Aufrufe, Game-Handshakes, FiveM-Informationsabfragen, Minecraft-Bots, TLS, Proxykapazität oder Sessions. Er ähnelt manchmal legitimem Traffic, was hartes Blockieren riskanter macht.
Schwierig wird es, weil beide Formen zusammen auftreten können. Ein Angriff beginnt mit Volumen und wechselt dann zu Protokollmissbrauch. Ein Gaming-Dienst kann einen offensichtlichen UDP-Flood erhalten und gleichzeitig Bots sehen, die Spieler imitieren. Deshalb reicht die Aussage “wir haben viele Tbps” nicht aus: Es muss klar sein, welche Schicht welchen Teil schützt.
- Volumetrisch
- Ziel: Netzwerkkapazität, Ports, Transit, Buffer oder PPS sättigen, bevor die Anwendung reagieren kann.
- Applikativ
- Ziel: Dienstlogik, API, Login, Spielprotokoll, HTTP/TLS-Schicht oder Geschäftsressource erschöpfen.
- Hybrid
- Ziel: Netzrauschen und Applikationsmissbrauch kombinieren, um schlechte Reaktionen oder False Positives zu erzwingen.
Warum das vor der Anbieterwahl wichtig ist
Das Thema volumetric vs application muss mit einem konkreten Netzwerkrisiko verbunden werden.
Wenn das Problem dagegen applikativ ist, kann große Netzkapazität den Port am Leben halten, während der Dienst unbenutzbar bleibt. Eine API antwortet vielleicht, verbrennt aber CPU. Ein Gameserver ist erreichbar, blockiert Spieler aber beim Laden. Ein Panel bleibt online, während teure Requests das Backend belasten. Hier zählt Protokollverhalten stärker als Gbps.
Die Unterscheidung beeinflusst auch Latenz, Kosten und Betrieb. Volumetrischer Schutz muss schnell, stabil und nah am Netzwerk sein. Applikativer Schutz muss kontextreicher sein, kann aber Komplexität hinzufügen. Wer beides ohne klare Architektur vermischt, erzeugt False Positives, stört echte Spieler oder macht den Vorfall schwer analysierbar.
| Angriffstyp | Hauptsymptom | Reales Risiko | Priorisierte Antwort |
|---|---|---|---|
| Volumetrischer DDoS | Port-Sättigung, Paketverlust, starker Traffic-Anstieg, Dienst vor der Anwendung unerreichbar. | Link oder Upstream-Kapazität fällt aus, bevor der Server filtern kann. | Geschützter IP-Transit, Upstream-Scrubbing, L3/L4-Filterung, FlowSpec bei Bedarf, sauberer Handoff. |
| Applikativer DDoS | Hohe Applikations-CPU, teure Verbindungen, Ziel-Endpunkt, Ladefehler trotz verfügbarem Link. | Traffic wirkt legitim und verbraucht dennoch Dienstressourcen. | Reverse Proxy, Protokollfilterung, intelligentes Rate Limiting, Applikationsregeln, Verhaltensanalyse. |
| Hybrider DDoS | Wechsel zwischen Volumen, PPS, Zielports und auffälligem Applikationsverhalten. | Eine Schicht wird geschützt, während die andere den Dienst weiter verschlechtert. | Schichtenarchitektur: Netzwerk zuerst, sauberer Handoff, dann spezialisierte Logik wenn nötig. |
Mögliche Lösungen je nach Bruchpunkt
Bei einem volumetrischen Angriff ist die sauberste Antwort, rohen Traffic nicht direkt auf die Kundeninfrastruktur treffen zu lassen. Traffic sollte in eine Mitigationsschicht mit Kapazität, schnellen Regeln und sauberem Ausgangspfad eintreten. Für Operatoren, Hoster oder Unternehmen mit Prefix-Announcement ist geschützter IP-Transit meist das natürliche Modell: BGP, Prefixe, Upstream-Kapazität, Filterung und Lieferung gereinigten Traffics.
Wenn der Kunde Server nicht verschieben möchte, können GRE-, IPIP- oder VXLAN-Tunnel sauberen Traffic zur bestehenden Infrastruktur zurückbringen. Ein Cross-Connect kann im Datacenter sinnvoller sein, wenn die Anforderung stabil und kapazitätsstark ist. Eine Router-VM kann zudem als sauberer Punkt zum Terminieren von Tunneln, Routing, Monitoring und Steuern des Rückwegs dienen.
Bei einem applikativen Angriff muss die Verteidigung näher an den Dienst rücken. Web- oder Gaming-Reverse-Proxy, Anti-Bot-Logik, Handshake-Filterung, Endpoint-Rate-Limiting oder eine spezialisierte Schicht können notwendig sein. Diese Schicht muss aber vor Volumen geschützt werden: Wenn sie allen Rohtraffic erhält, wird sie selbst zum Ziel. Das stärkste Modell kombiniert daher häufig Volumen-Mitigation zuerst und danach Applikationsfilterung, sobald Traffic nutzbar ist.
- Geschützter IP-Transit
- Für Prefixe, Kundennetze, Hoster, Operatoren und exponierte Dienste, die einen sauberen Anti-DDoS-Eingang mit BGP benötigen.
- GRE/IPIP/VXLAN-Tunnel
- Zum Schutz eines bestehenden Servers oder Netzes ohne schwere Migration, mit Lieferung gefilterten Traffics.
- Cross-Connect
- Für stabile und kapazitätsstarke Übergabe im Datacenter, wenn das physische Design es erlaubt.
- Spezialisierter Reverse Proxy
- Für Web, FiveM, Minecraft oder Umgebungen, in denen Applikationsverhalten verstanden werden muss.
Konkretes Beispiel: exponierter Hoster und beliebter Gameserver
Stellen wir uns einen Hoster vor, der VPS oder Dedicated Server an Gaming-Communities verkauft. Bei einem volumetrischen Angriff ist nicht die Kundenmaschine das Hauptproblem, sondern die Upstream-Kapazität. Der Port füllt sich, Netzwerkqueues degradieren und Spieler sehen Timeouts. Die erste sinnvolle Antwort ist, Traffic in geschützten Transit zu bringen, den Flood zu filtern und nutzbaren Traffic zum Hosternetz zurückzuliefern.
Nun ein stark sichtbarer FiveM-Server. Der Link ist geschützt, aber manche Spieler bleiben beim Laden hängen, weil Bots konkrete Protokollschritte missbrauchen. Das Problem ist nicht mehr nur Volumen. Eine spezialisierte Schicht kann Verhalten analysieren, False Positives reduzieren und legitimen Traffic erhalten. Reverse Proxy oder Gaming-Logik ist gerade deshalb nützlich, weil die Netzwerkschicht den Eingang bereits schützt.
In beiden Fällen braucht der Kunde keine generischen Aussagen. Er muss wissen, wo der Angriff absorbiert wird, wie sauberer Traffic zurückkommt, was in Logs sichtbar ist und welche Aktionen während des Incidents möglich sind. Diese Lesbarkeit trennt Schutz auf dem Papier von wirklich betreibbarer Mitigation.
Häufige Fehler vermeiden
- Nur ein Tbps-Versprechen kaufen, ohne Handoff, Latenz, Ports, PPS und Produktionsverhalten zu prüfen.
- Glauben, ein WAF oder applikativer Reverse Proxy könne einen Dienst retten, wenn der Netzwerklink bereits gesättigt ist.
- Glauben, volumetrischer Schutz reiche gegen Bots, die ein Protokoll imitieren oder einen bestimmten Endpoint missbrauchen.
- Den Rückweg vergessen: zu kleiner Tunnel, ungetestete MTU, missverstandenes asymmetrisches Routing oder stateful Firewall am falschen Ort.
- Während eines Angriffs zu breit blockieren und mehr False Positives erzeugen als der Angriff selbst.
- Keinen Notfallplan vorbereiten: Wer announced den Prefix, ändert DNS, prüft Logs und bestätigt die Normalisierung?
FAQ: volumetrischer und applikativer DDoS
Was ist der Hauptunterschied zwischen volumetrischem und applikativem DDoS?
Volumetrische Angriffe sättigen Netzkapazität oder PPS. Applikative Angriffe verbrauchen Dienstressourcen wie Endpoint, Login, API, Proxy, Protokoll oder Geschäftslogik.
Reicht volumetrischer Schutz für einen Gameserver?
Nicht immer. Er ist gegen Floods und Sättigung nötig, aber ein exponierter Gameserver kann zusätzlich eine spezialisierte Schicht benötigen, wenn der Angriff Spieler imitiert.
Schützt ein Reverse Proxy gegen volumetrische Angriffe?
Er hilft bei Applikationslogik, sollte aber nicht allein Rohvolumen erhalten. Große Angriffe brauchen zuerst Upstream-Netzwerkmitigation.
Ist geschützter IP-Transit ohne Kunden-BGP nützlich?
Ja, je nach Modell. Kunden können geschützte IP, Tunnel oder Router-VM nutzen. Für Operatoren und Hoster gibt BGP mehr Kontrolle.
Wie wählt man die richtige Schicht?
Man prüft reale Symptome: gesättigter Link, hohe PPS, Zielport, Applikations-CPU, Logs, Protokolltyp und mögliche saubere Delivery.
