Nullrouting erklärt: Null Route, RTBH und der Unterschied zur Filterung
Was Nullrouting technisch ist, wie eine Null Route über BGP in Sekunden durch ganze Netze wandert, warum Netzbetreiber sie setzen, was sie für den Betroffenen bedeutet und woran Sie erkennen, ob Ihr eigener Anbieter so arbeitet.
Nullrouting ist eine Route, die Pakete verwirft, statt sie weiterzuleiten. Wird die IP-Adresse eines Servers nullgeroutet, verschwindet dieser Server aus dem Internet: Der Angriffsverkehr kommt nicht mehr an, der Verkehr Ihrer Nutzer aber ebenso wenig. Der Server selbst läuft weiter, die Dienste lauschen, die Datenbank antwortet, der Cron-Job startet pünktlich. Nur erreicht niemand mehr etwas davon. Die englischen Begriffe für dasselbe Verfahren sind null route und blackhole, im Betriebsjargon heißt es "die Adresse ist geblackholet".
Dieser Beitrag erklärt das Verfahren vollständig: was eine Null Route auf einem Linux-System ist und was dieselbe Route auf dem Router eines Netzbetreibers bedeutet, wie Remotely Triggered Black Hole Filtering eine solche Route über BGP in Sekunden durch ganze Netze schiebt, warum Netzbetreiber das tun, was es für den Betroffenen heißt und woran Sie erkennen, ob Ihr eigener Anbieter so arbeitet. Der wichtigste Abschnitt ist die Abgrenzung zur Filterung, denn dort liegt der Unterschied, der über Ihre Verfügbarkeit entscheidet.
Vorweg die Einordnung, die den ganzen Text trägt, in zwei Sätzen, die beide wahr sind. Nullrouting ist keine Abwehr, sondern eine kontrollierte Kapitulation: Der Angriff hat sein Ziel erreicht, der Dienst ist weg, nur eben geordnet und ohne Schaden für die Nachbarn. Und trotzdem ist diese Entscheidung aus Sicht eines Netzbetreibers rational, in bestimmten Situationen sogar die einzig verantwortbare. Wer nur eine der beiden Hälften kennt, trifft schlechte Entscheidungen: entweder ärgert er sich über eine Maßnahme, die ihn gerettet hat, oder er kauft einen "DDoS-Schutz", der in Wahrheit ein Abschaltmechanismus ist.
Was Nullrouting technisch ist
Eine Null Route ist ein Eintrag in der Routingtabelle, dessen nächster Schritt kein Ausgang ist, sondern das Nichts. Jede andere Route beantwortet die Frage "über welche Schnittstelle und an welchen nächsten Knoten geht dieses Paket". Eine Null Route beantwortet sie mit "gar nicht". Das Paket wird verworfen, der Vorgang ist abgeschlossen, es entsteht kein weiterer Aufwand.
Genau darin liegt der Reiz für den Netzbetreiber. Eine Firewall-Regel muss ein Paket lesen, gegen eine Liste halten und bewerten. Ein Routing-Eintrag wird ohnehin für jedes Paket nachgeschlagen, das ist der normale Weiterleitungsvorgang, und er läuft in spezialisierter Hardware. Verwerfen per Route kostet deshalb praktisch nichts und skaliert bis zur vollen Leitungsgeschwindigkeit, während jede Regel, die den Paketinhalt bewertet, Rechenzeit mal Paketrate kostet.
Null Route, Blackhole und Discard sind dasselbe
Drei Wörter, ein Verfahren, unterschiedliche Herkunft. Null Route kommt von der virtuellen Schnittstelle Null0, die es auf Routern eines verbreiteten Herstellers gibt und die alles verschluckt, was man ihr gibt. Blackhole ist der Begriff aus der Betreiberwelt und steht in den einschlägigen Standards. Discard ist das Wort, das andere Routerbetriebssysteme in der Konfiguration verwenden. Im Deutschen hat sich "Nullrouting" durchgesetzt, seltener auch "Schwarzes Loch". Wer mit dem Support seines Anbieters spricht, sollte alle drei Wörter kennen, denn welches im Ticket auftaucht, hängt allein davon ab, mit welcher Technik der Mitarbeiter groß geworden ist.
Die Null Route auf einem Linux-System
Linux kennt das Verfahren seit Langem und unterscheidet dabei vier Verhaltensweisen. Der Unterschied liegt nicht darin, ob das Paket verworfen wird, sondern darin, ob der Absender davon erfährt:
| Routentyp | Befehl | Was mit dem Paket geschieht | Was der lokale Absender zurückbekommt |
|---|---|---|---|
blackhole |
ip route add blackhole 203.0.113.42 |
stillschweigend verworfen, keine Rückmeldung | Fehlercode EINVAL |
unreachable |
ip route add unreachable 203.0.113.42 |
verworfen, ICMP host unreachable zurück | Fehlercode EHOSTUNREACH |
prohibit |
ip route add prohibit 203.0.113.42 |
verworfen, ICMP communication administratively prohibited zurück | Fehlercode EACCES |
throw |
ip route add throw 203.0.113.42 |
Suche in dieser Tabelle abgebrochen, nächste Regel entscheidet | ohne Policy-Routing ICMP net unreachable |
Die stille Variante ist die, um die es hier geht. Angelegt, angesehen und wieder entfernt wird sie so:
ip route add blackhole 203.0.113.42
ip route add blackhole 198.51.100.0/24
ip route show | grep blackhole
ip route del blackhole 203.0.113.42
Zwei Dinge sind daran wichtig und werden regelmäßig missverstanden. Erstens gilt eine solche Route für das Ziel eines Pakets, nicht für dessen Absender. Auf Ihrem eigenen Server wirkt sie deshalb gegen den Rückweg: Der Server nimmt das eingehende Paket noch an, kann aber nichts mehr zurückschicken, der Verbindungsaufbau kommt nie zustande und die Gegenstelle läuft in eine Zeitüberschreitung. Das ist eine brauchbare, sehr billige Sperre gegen eine bekannte einzelne Quelle. Zweitens ändert eine Null Route auf Ihrem Server nichts daran, dass die Pakete Ihre Leitung bereits belegt haben. Gegen einen volumetrischen Angriff hilft sie also genauso wenig wie jede andere Einstellung auf dem Server, und warum das so ist, steht ausführlich in Was ist ein DDoS-Angriff.
Dieselbe Route auf dem Router des Anbieters
Auf der Betreiberseite sieht derselbe Eintrag nur anders geschrieben aus. Auf einem verbreiteten Router-Betriebssystem lautet er:
ip route 203.0.113.42 255.255.255.255 Null0
Auf einem anderen großen Router-Betriebssystem heißt die Aktion discard:
set routing-options static route 203.0.113.42/32 discard
Der Unterschied zur Route auf Ihrem Server ist nicht technischer, sondern räumlicher Natur, und dieser Unterschied ist der ganze Punkt. Der Eintrag steht nicht am Ende der Leitung, sondern an ihrem Anfang. Pakete zu Ihrer Adresse werden verworfen, bevor sie die Leitung zu Ihrem Server belegen. Damit wirkt die Maßnahme gegen jede Angriffsgröße, denn sie verschiebt den Ort des Verwerfens dorthin, wo mehr Kapazität steht. Der Preis dafür ist, dass an dieser Stelle niemand mehr unterscheidet, wer da gerade kommt.
Remotely Triggered Black Hole Filtering: wie eine Null Route durch ein ganzes Netz wandert
Ein einzelner Router nützt wenig, wenn der Angriffsverkehr über zwanzig Grenzrouter gleichzeitig einströmt. Remotely Triggered Black Hole Filtering, kurz RTBH, löst genau das: Es ist ein Verfahren, mit dem eine einzige BGP-Ankündigung dieselbe Null Route auf allen Routern eines Netzes gleichzeitig erzeugt. Beschrieben ist es in RFC 5635, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", einer informationellen Veröffentlichung der IETF vom August 2009, die auf der älteren RFC 3882 aufbaut.
Der Ablauf in vier Schritten
Das Verfahren ist weniger kompliziert, als sein Name klingt, und besteht aus einer Vorbereitung und einem Auslöser.
- Vorbereitung, einmalig: Auf jedem Grenzrouter des Netzes wird eine statische Route für eine Verwurfsadresse eingetragen, die ins Leere zeigt. RFC 5635 empfiehlt dafür eine Adresse aus dem Dokumentationsnetz, typischerweise
192.0.2.1, weil diese Adresse nie echten Verkehr trägt. Auf jedem Router steht alsoip route 192.0.2.1 255.255.255.255 Null0. - Auslöser: Ein einzelner Router, der Trigger, kündigt im internen BGP die angegriffene Adresse als eigenständige Route an, üblicherweise als
/32, und setzt als nächsten Schritt die Verwurfsadresse192.0.2.1ein. Die Ankündigung trägt eine vereinbarte Community und zusätzlichNO_EXPORT, damit sie das Netz nicht verlässt. - Wirkung: Jeder Grenzrouter löst den nächsten Schritt auf, landet bei seiner eigenen statischen Route ins Leere und legt einen Weiterleitungseintrag an, der Pakete zu dieser Adresse verwirft. Es ist keine Konfigurationsänderung nötig, kein Neustart eines Prozesses, keine Übersetzung einer Zugriffsliste.
- Weitergabe nach oben: Soll der Verkehr das eigene Netz gar nicht erst erreichen, wird dieselbe Route an die Vorleister weitergegeben, markiert mit der Blackhole-Community. Der Vorleister verwirft dann an seiner eigenen Netzkante.
RFC 5635 nennt in der Entstehungsgeschichte des Verfahrens die ursprüngliche Anforderung, und sie beschreibt den Reiz besser als jede Erklärung: Man wollte Verwurfsregeln "auf über 60 Router innerhalb von 60 Sekunden" ausrollen können. Genau das leistet eine BGP-Ankündigung, und zwar ohne jede Rücksicht auf die Größe des Netzes.
Die Blackhole-Community 65535:666
Damit ein Kunde die Null Route bei seinem Vorleister selbst auslösen kann, ohne dass für jede Kombination aus Kunde und Vorleister eine eigene Vereinbarung nötig wäre, gibt es dafür seit Oktober 2016 einen einheitlichen Wert. RFC 7999, "BLACKHOLE Community", definiert die wohlbekannte BGP-Community 0xFFFF029A, in der üblichen Schreibweise 65535:666. Die Zahl 666 ist kein Zufall: Der Standard hält ausdrücklich fest, dass dieser Wert unter Netzbetreibern seit Langem mit Blackholing verbunden wird.
Drei Festlegungen aus diesem Standard erklären das Verhalten, das Sie als Kunde beobachten. Erstens ist die Ankündigung so genau wie möglich: RFC 7999 hält fest, dass die Länge des Präfixes typischerweise /32 bei IPv4 und /128 bei IPv6 beträgt, also genau eine Adresse. Zweitens soll ein Router, der eine so markierte Ankündigung annimmt, ihr NO_ADVERTISE oder NO_EXPORT hinzufügen, damit sie sich nicht weiter im Internet ausbreitet. Und drittens ist das der Grund, warum Blackhole-Sitzungen streng abgesichert sein müssen: Eine /32-Ankündigung, die irrtümlich in die Welt läuft, ist die genaueste Route, die es gibt, zieht deshalb den Verkehr für diese Adresse an sich und vernichtet ihn.
Praktisch heißt das: Viele Netzbetreiber bieten ihren Kunden diese Community aktiv an. Wer sie an einer BGP-Sitzung setzt, legt seine eigene Adresse still, in wenigen Sekunden, ohne Ticket und ohne Rückfrage. Das ist die schnellste Selbstbedienung, die es in der Missbrauchsabwehr gibt, und zugleich die endgültigste.
Ziel-basiert und quell-basiert
Der eben beschriebene Normalfall ist das ziel-basierte Verfahren: Verworfen wird alles, was zu einer bestimmten Adresse will. RFC 5635 ergänzt das um die quell-basierte Variante, die auf Unicast Reverse Path Forwarding aufsetzt. Dabei wird nicht die Adresse des Opfers angekündigt, sondern die des Angreifers. Die Prüfung des Rückwegs findet für jedes eintreffende Paket die Verwurfsroute und wirft es weg, das Opfer bleibt für alle anderen erreichbar.
Das klingt nach der besseren Lösung und ist in der Praxis trotzdem selten. Es setzt voraus, dass die Rückwegprüfung auf allen Grenzroutern aktiv ist, es wirkt nicht gegen gefälschte Absenderadressen, und bei einem verteilten Angriff mit Zehntausenden Quellen ist die Liste zu lang. Deshalb bleibt es in der Regel beim ziel-basierten Verfahren, und dessen Wirkung beschreibt RFC 5635 mit bemerkenswerter Offenheit: Der Schaden für das Ziel sei damit "vollständig", denn alle Pakete zu diesem Ziel würden verworfen, Angriffsverkehr und legitimer Verkehr. Der Standard, der das Verfahren beschreibt, sagt also selbst, dass es den Ausfall nicht verhindert, sondern herstellt.
Warum Netzbetreiber nullrouten, und warum das nachvollziehbar ist
An dieser Stelle lohnt der Perspektivwechsel, weil die Entscheidung von außen nach Gleichgültigkeit aussieht und von innen nach Arithmetik. Ein Rechenzentrumsnetz besteht nicht aus Einzelleitungen je Kunde, sondern aus wenigen großen, die sich viele teilen. Genau daraus folgt alles Weitere.
Die Rechnung, die zu der Entscheidung führt
Nehmen Sie eine Anbindung mit 100 Gbit/s, an der einige hundert Server hängen. Auf eine einzige Adresse dahinter läuft ein Angriff mit 200 Gbit/s. Die Leitung kann nicht 200 Gbit/s transportieren, also füllt sich die Warteschlange davor und läuft über. Eine überlaufende Warteschlange wählt nicht aus, sie verwirft, was gerade ankommt. Damit verlieren alle Server hinter dieser Leitung Pakete, nicht nur der angegriffene. Ein Angriff auf einen Kunden wird so zum Ausfall für hunderte.
Wird die angegriffene Adresse nullgeroutet, und zwar oben bei den Vorleistern, endet der Angriffsverkehr dort, wo er eintritt. Die 100-Gbit/s-Leitung ist wieder frei, alle anderen Dienste laufen weiter, ein Kunde ist offline. Die Entscheidung lautet also nicht "filtern oder nullrouten", sondern in diesem Moment "ein Ausfall oder hunderte". So gestellt beantwortet sich die Frage von selbst, und jeder, der schon einmal auf der anderen Seite eines solchen Vorfalls gesessen hat, hätte gleich entschieden.
Die zweite Rechnung: Kapazität kostet Geld, eine Route kostet nichts
Der zweite Grund ist wirtschaftlich und wird selten offen benannt. Filtern setzt voraus, dass man mehr Kapazität vorhält, als der Angriff mitbringt. Diese Kapazität besteht aus Anbindungen, aus Geräten, die Pakete im Leitungstempo bewerten, und aus Menschen, die das betreiben. Sie wird dauerhaft bezahlt und steht die meiste Zeit ungenutzt herum, denn Angriffe sind selten und kurz.
Eine Null Route dagegen kostet eine Zeile Konfiguration und keine Hardware. Sie verhindert außerdem Kosten, die sonst anfallen würden: Transitverkehr wird in der Regel nach dem 95. Perzentil abgerechnet, und Angriffsverkehr, der ins eigene Netz gelassen wird, ist abrechenbarer Verkehr. Wer also DDoS-Schutz ausschließlich über Nullrouting umsetzt, hat keine Kapazitätskosten, keine Gerätekosten und keine Verkehrskosten. Das ist der Grund, warum sehr günstige Angebote sehr oft genau so aufgebaut sind, und es ist keine Unterstellung, sondern eine Folge der Preisgestaltung.
Halten wir fest, ohne jemanden zu verurteilen: Nullrouting ist für den Netzbetreiber eine gute Maßnahme, weil sie sein Netz schützt, sofort wirkt, unbegrenzt skaliert und nichts kostet. Für den betroffenen Kunden ist sie deshalb trotzdem kein Schutz, denn sie erreicht nicht, was er von einem Schutz erwartet. Beide Sätze widersprechen sich nicht, sie beschreiben nur verschiedene Interessen.
Was Nullrouting für den Betroffenen bedeutet
Der Server läuft, nur erreicht ihn niemand
Das Verwirrende an einer Null Route ist, dass auf dem Server selbst alles in Ordnung aussieht. Es gibt keinen Absturz, keine Fehlermeldung, keine auffällige Last. Über die Konsole im Kundenbereich sehen Sie einen völlig gesunden Server: Die Dienste lauschen, systemctl meldet alles als aktiv, ein Aufruf über 127.0.0.1 antwortet in Millisekunden. Von außen ist derselbe Server tot.
Noch einmal deutlicher: Ein Angriff, der den Server erreicht, sieht man an steigenden Paketzählern. Bei einer Null Route stehen diese Zähler still. Die Netzwerkschnittstelle ist ungewöhnlich ruhig, ruhiger als im Normalbetrieb. Diese Stille ist das eigentliche Erkennungsmerkmal, und sie ist der zuverlässigste Einzelhinweis, den Sie bekommen können.
Ausgehend gilt es ebenfalls, wenn auch mit einer Einschränkung. Ist die Null Route nur innerhalb des Anbieternetzes gesetzt, kann Ihr Server unter Umständen noch Ziele außerhalb erreichen. Ist sie dagegen bis zu den Vorleistern angekündigt, scheitert auch jede ausgehende Verbindung, denn die Antwort geht an Ihre Adresse und wird unterwegs verworfen. Paketaktualisierungen laufen dann in Zeitüberschreitungen, externe Schnittstellen antworten nicht, Sicherungen auf ein entferntes Ziel brechen ab. Der Server ist also nicht nur unerreichbar, sondern häufig auch handlungsunfähig.
Typische Dauer und automatische Aufhebung
Eine Null Route wird fast nie von Hand zurückgenommen, sondern läuft nach einem festen Zeitfenster automatisch ab. In der Praxis reicht die Spanne von wenigen Minuten bis zu 24 Stunden, oft mit der Regel, dass ein erneuter Angriff das Fenster von vorn beginnen lässt. Einige Netze verlängern automatisch, solange sie weiter Angriffsverkehr auf die Adresse sehen.
Daraus folgt die unangenehmste Eigenschaft des Verfahrens, und sie ist der Kern des Problems: Die Dauer des Ausfalls hat nichts mehr mit der Dauer des Angriffs zu tun. Ein Angriff dauert typischerweise Sekunden bis wenige Minuten, in der Messung großer Betreiber sind sehr kurze Angriffe die Regel. Eine Null Route über zwei Stunden macht aus einem Angriff von 40 Sekunden einen Ausfall von zwei Stunden. Der Angreifer hat dann nicht nur gewonnen, er hat den Gewinn um den Faktor 180 gehebelt, und zwar mit Hilfe des Abwehrmechanismus.
Warum der Angreifer genau das erreichen wollte
Ein Angreifer misst sein Ergebnis. Er verbindet sich mit Ihrem Dienst, er sieht Ihren Eintrag in der Serverliste, er liest Ihre Statusseite. Wenn Ihre Adresse nullgeroutet wird, sieht er exakt das, wofür er bezahlt hat, und er sieht es mit weniger Aufwand als erwartet, denn er musste den Angriff nicht einmal aufrechterhalten. Das Ergebnis ist eine Einladung zur Wiederholung, und sie wird angenommen: Wiederkehrende Angriffe jeden Abend zur selben Zeit sind das häufigste Muster bei Projekten, die einmal auf diese Weise stillgelegt wurden.
Die Definition, die daraus folgt, ist unromantisch, aber belastbar. Denial of Service ist über die Wirkung definiert, nicht über die Ursache. Ein Dienst, der für Nutzer nicht erreichbar ist, ist verweigert, unabhängig davon, ob das Paket vom Angreifer oder vom Grenzrouter des eigenen Anbieters gestoppt wurde. Nullrouting stellt die Wirkung eines erfolgreichen Angriffs her. Es tut das kontrolliert und aus guten Gründen, aber es tut es.
Nullrouting und Filterung: der Unterschied, auf den es ankommt
Das ist das Herzstück, und der Unterschied lässt sich in einem Satz sagen: Filterung unterscheidet zwischen Angriffsverkehr und echten Nutzern und lässt Letztere durch, Nullrouting unterscheidet nicht. Alles Weitere folgt daraus.
Die folgende Tabelle misst beide Verfahren an denselben Kriterien. Sie ist bewusst nicht einseitig aufgebaut, denn Nullrouting gewinnt in mehreren Zeilen, und zwar zu Recht:
| Kriterium | Nullrouting (RTBH) | Filterung im Netz |
|---|---|---|
| Entscheidungsgrundlage | allein die Zieladresse, alles oder nichts | jedes Paket einzeln, nach Muster und Rate |
| Feinheit | eine ganze IP-Adresse (/32 beziehungsweise /128) |
Adresse, Protokoll, Port, Paketlänge, Flags, Rate je Quelle |
| Reaktionszeit | Sekunden, eine BGP-Ankündigung genügt | keine, weil die Filterstufe dauerhaft im Pfad steht |
| Wirkung auf den Angriffsverkehr | vollständig verworfen, weit vor dem Server | verworfen, sobald das Muster erkannt ist |
| Wirkung auf echte Nutzer | ebenfalls vollständig verworfen, der Dienst ist offline | kommen durch, der Dienst bleibt erreichbar |
| Was der Angreifer erreicht | sein Ziel, vollständig | nichts außer eigenen Kosten |
| Ende des Ausfalls | wenn die Route zurückgenommen wird, nicht wenn der Angriff endet | es entsteht kein Ausfall, der enden müsste |
| Kosten beim Betreiber | praktisch null, eine Zeile Konfiguration | dauerhaft vorgehaltene Kapazität, Geräte und Betrieb |
| Skalierung nach oben | unbegrenzt, weil der Vorleister verwirft | begrenzt durch die vorgehaltene Filterkapazität |
| Skalierung nach unten | keine, die kleinste Einheit ist die ganze Adresse | beliebig fein, bis auf einen einzelnen Port |
| Nachjustieren im laufenden Angriff | nicht möglich, es gibt nur an oder aus | möglich, Regeln lassen sich verschärfen oder lockern |
Eine Route kennt ein Kriterium, ein Filter kennt zwölf
Der Grund für die Zeile "Feinheit" ist keine Willensfrage, sondern eine Eigenschaft des Werkzeugs. Eine Route trifft ihre Entscheidung ausschließlich anhand der Zieladresse, mehr Merkmale kennt sie nicht. Sie kann nicht wissen, ob das Paket zum Spielport oder zum Abfrageport will, ob es 64 oder 1.400 Byte groß ist und ob dieselbe Quelle gerade das zehnte oder das zehntausendste Paket schickt.
Wie viel mehr eine Filterregel kann, steht in RFC 8955, "Dissemination of Flow Specification Rules" vom Dezember 2020, dem Standard, der Filterregeln über BGP verteilt. Er definiert zwölf Merkmale, nach denen ein Paket eingeordnet werden darf: Zielpräfix, Quellpräfix, IP-Protokoll, Port, Zielport, Quellport, ICMP-Typ, ICMP-Code, TCP-Flags, Paketlänge, DSCP-Feld und Fragmentierung. Dazu kommt eine Aktion, die nicht nur verwerfen kann, sondern auch begrenzen: Eine Rate von 0 bedeutet verwerfen, jeder andere Wert bedeutet durchlassen bis zu dieser Grenze.
Damit ist der Unterschied greifbar. Gegen einen Abfrage-Flood auf Port 27015 lautet die Filterantwort: "höchstens zehn Abfragen pro Sekunde je Quelladresse, der Rest wird verworfen, der Spielport bleibt unangetastet". Die Nullrouting-Antwort auf dieselbe Frage lautet: "diese Adresse existiert nicht mehr". Beide Antworten beenden den Angriff. Nur eine davon beendet ihn, ohne den Dienst mitzunehmen.
Und selbst als Notmaßnahme wirkt Nullrouting schlechter als gedacht
Es gibt eine Untersuchung, die das Verfahren nicht theoretisch, sondern an echten Ereignissen gemessen hat: "Down the Black Hole: Dismantling Operational Practices of BGP Blackholing at IXPs", veröffentlicht auf der ACM Internet Measurement Conference 2019, Seiten 435 bis 448. Die Autoren haben an einem der größten europäischen Internetknoten über drei Monate lang jedes RTBH-Ereignis mit den tatsächlich gemessenen Verkehrsdaten abgeglichen. Drei Ergebnisse sind für Betroffene relevant.
- Nur 27 Prozent aller RTBH-Ereignisse wiesen überhaupt Verkehr in den 72 Stunden davor und eine Verkehrsauffälligkeit in den letzten zehn Minuten vor dem Ereignis auf. Bei der Mehrheit war also weder eine Auffälligkeit noch überhaupt Verkehr messbar. Ein erheblicher Teil der Null Routes wird gesetzt, ohne dass zu diesem Zeitpunkt etwas passiert.
- Die mittlere Verwurfsquote bei
/32-Präfixen lag bei 50 Prozent, obwohl gerade diese Präfixe 99 Prozent des Verkehrs abdeckten, der hätte verworfen werden sollen. Das Verfahren erreicht sein eigenes Ziel also im Mittel nur zur Hälfte, weil nicht jeder Weg ins Netz die Ankündigung übernimmt. - Die Autoren beschreiben außerdem das Phänomen der "RTBH-Zombies": Null Routes, die in den Routingtabellen stehen bleiben, obwohl im Datenpfad längst nichts mehr passiert, was sie rechtfertigen würde.
Die Schlussfolgerung daraus ist nüchtern: Nullrouting ist nicht nur grob, es ist im Durchschnitt auch nicht so wirksam, wie die Einfachheit des Verfahrens vermuten lässt. Als letzte Stufe hat es trotzdem seinen Platz. Als erste Antwort auf jeden Angriff ist es die schlechteste verfügbare Wahl, die noch funktioniert.
Wie Sie herausfinden, ob Ihr Anbieter nullroutet
Die Frage lässt sich beantworten, und zwar auf drei Wegen: durch Messung im Vorfall, durch Lesen der Vertragsbedingungen und durch eine präzise gestellte Frage an den Support. Alle drei zusammen ergeben ein eindeutiges Bild.
Der Selbsttest in vier Schritten
Der Test setzt voraus, dass Sie einen netzunabhängigen Zugang zum Server haben, also eine Konsole im Kundenbereich. Über SSH kommen Sie bei einer gesetzten Null Route nicht mehr hinein, und das ist kein Fehler, sondern bereits das erste Ergebnis.
ip -br addr
ss -lntup
curl -o /dev/null -s -w '%{http_code} %{time_total}\n' http://127.0.0.1/
IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets); sleep 5; B=$(cat /sys/class/net/$IF/statistics/rx_packets)
echo "$(( (B-A)/5 )) Pakete pro Sekunde eingehend auf $IF"
Der entscheidende Wert ist der letzte. Lassen Sie parallel von einem anderen Anschluss aus einen Dauerping auf Ihre Adresse laufen und beobachten Sie dabei die eingehende Paketrate. Steigt sie nicht, erreicht Sie kein einziges dieser Pakete, und dann wird es vor Ihrem Server verworfen. Steigt sie stark, ohne dass der Dienst antwortet, läuft ein Angriff, der den Server erreicht, und das ist eine völlig andere Diagnose mit völlig anderen Maßnahmen, beschrieben in DDoS-Angriff erkennen.
Von außen, also von einem beliebigen anderen Rechner, gehören drei Befehle dazu:
ping -c 5 203.0.113.42
traceroute -n 203.0.113.42
mtr -rwzc 20 203.0.113.42
Lesen Sie den Pfad von hinten. Antwortet der vorletzte Knoten innerhalb des Anbieternetzes normal und bricht die Spur genau danach mit Sternchen ab, wird im Netz des Anbieters verworfen. Läuft die Spur dagegen bis zum Gateway direkt vor Ihrem Server und schweigt erst der Server selbst, sitzt die Ursache bei Ihnen: eine eigene Firewall-Regel, ein abgestürzter Dienst oder eine gesättigte Leitung.
Die Symptome und was sie bedeuten
| Beobachtung | Wahrscheinliche Ursache | Nächster Schritt |
|---|---|---|
Dienst antwortet über 127.0.0.1 sofort, von außen gar nicht, eingehende Paketrate nahe null |
Nullrouting vor dem Server | Ticket mit der Frage nach Schwellenwert und Aufhebungszeitpunkt |
| Dienst antwortet lokal, von außen nicht, eingehende Paketrate sehr hoch | Angriff erreicht den Server, keine Null Route | Paketrate, Bandbreite und mittlere Paketgröße messen und melden |
traceroute endet im Netz des Anbieters, der Knoten davor antwortet sauber |
Verwurf am Grenzrouter des Anbieters | Spur mit Zeitstempel sichern, sie ist der Nachweis |
traceroute erreicht das Gateway vor dem Server, erst der Server schweigt |
eigene Firewall, eigener Dienst oder gesättigte Leitung | nft list ruleset und ss -lntup prüfen |
| ICMP administratively prohibited kommt zurück | bewusste Sperre mit Rückmeldung, kein stiller Blackhole | meist eine Missbrauchssperre, Ticket lesen |
| Der Server erreicht auch ausgehend nichts mehr, obwohl er läuft | Null Route bis zu den Vorleistern angekündigt | abwarten, Aufhebungszeitpunkt erfragen, nichts umbauen |
| Die Adresse ist plötzlich wieder erreichbar, ohne dass Sie etwas getan haben | automatische Aufhebung nach Ablauf des Zeitfensters | Dauer notieren, das ist die gelebte Praxis Ihres Vertrags |
| Derselbe Ausfall wiederholt sich zur selben Uhrzeit | gezielter, wiederkehrender Angriff auf ein lohnendes Ziel | Uhrzeiten dokumentieren, das ist das Kriterium für eine dedizierte Schutz-IP |
Was in den Vertragsbedingungen steht
Der zweite Weg ist Lesen, und er kostet zehn Minuten. Suchen Sie in den allgemeinen Geschäftsbedingungen, der Leistungsbeschreibung und der Nutzungsrichtlinie nach diesen Begriffen: Nullrouting, Null-Route, Blackhole, Blackholing, Sperrung der IP-Adresse, Trennung vom Netz, Schutz der Netzinfrastruktur, Abwehrmaßnahmen. Findet sich eine Klausel, die dem Anbieter erlaubt, Ihre Adresse "zum Schutz der Netzinfrastruktur vorübergehend vom Netz zu trennen", dann ist das die vertragliche Grundlage für Nullrouting, auch wenn das Wort selbst nirgends steht.
Zwei weitere Formulierungen sind aufschlussreich. Wird ein DDoS-Schutz "bis zu X Gbit/s" beworben, sollten Sie fragen, was oberhalb von X passiert, denn genau dort liegt die interessante Antwort. Und steht irgendwo, dass bei "übermäßigem Verkehr" Kosten weiterverrechnet werden, beschreibt das ein Modell, in dem Angriffsverkehr ins Netz gelassen und abgerechnet wird, statt vorher zu enden.
Die richtige Frage an den Support
Der dritte Weg ist eine einzige, präzise Frage, gestellt am besten vor dem Vertragsabschluss und in dieser Form:
Was geschieht bei einem Angriff mit mehr als 10 Gbit/s auf meine IP-Adresse: Wird der Verkehr gefiltert und die Adresse bleibt erreichbar, oder wird die Adresse nullgeroutet? Falls nullgeroutet: ab welchem Schwellenwert, für wie lange, und wird die Route automatisch aufgehoben?
Die Frage ist deshalb gut, weil sie vier Angaben gleichzeitig verlangt, die sich nicht in einem Werbesatz unterbringen lassen: ob, ab wann, wie lange und wie wieder zurück. Eine klare Antwort ist ein gutes Zeichen, unabhängig davon, wie sie ausfällt: Auch "wir routen ab 5 Gbit/s für 60 Minuten null" ist eine Antwort, mit der Sie planen können. Eine ausweichende Antwort ist ebenfalls eine Antwort, nur eine andere. Formulierungen wie "wir ergreifen geeignete Maßnahmen" oder "unser Netz ist DDoS-geschützt" beantworten keine der vier Fragen.
Was Sie tun können, wenn Sie gerade nullgeroutet sind
Kurz vorweg: Sie können die Route nicht selbst zurücknehmen, sie steht nicht auf Ihrem Server. Was Sie tun können, ist trotzdem mehr als Warten, und die Reihenfolge ist wichtig.
- Über die Konsole im Kundenbereich zugreifen, nicht über SSH. Die Konsole läuft unabhängig von der Netzwerkanbindung und ist in dieser Lage Ihr einziger Weg auf das System.
- Den Befund sichern. Eingehende Paketrate, eine Spur von außen mit Zeitstempel und die Uhrzeit, ab der es weg war. Das sind die drei Angaben, die aus einer Vermutung einen Nachweis machen, und sie sind später weg.
- Nichts umbauen. Firewall-Regeln, Dienstneustarts und Kernel-Einstellungen ändern nichts an einer Route außerhalb Ihres Servers. Ein Neustart löscht nur Ihre eigenen Zähler.
- Die IP-Adresse nicht vorschnell wechseln. Solange die alte Adresse im DNS steht, schicken Sie Ihre Nutzer weiter in das Loch, und ein Angreifer, der die neue Adresse innerhalb von Minuten aus Ihrem eigenen Eintrag ablesen kann, folgt einfach. Ein Adresswechsel ist sinnvoll, nachdem der Vorfall vorbei ist, geplant und zusammen mit den DNS-Einträgen.
- Ein Ticket mit Zahlen öffnen. Zeitpunkt mit Zeitzone, betroffene Adresse, Zielport, gemessene Paketrate, Bandbreite, mittlere Paketgröße. Dazu die vier Fragen aus dem vorigen Abschnitt, vor allem: Wann wird die Route aufgehoben?
- Abhängigkeiten retten, die nicht an dieser Adresse hängen müssen. Ein zweiter Nameserver in einem anderen Netz hält die Zone am Leben. Ein zweiter MX mit niedrigerer Priorität nimmt Post an, statt sie zurückzuweisen. Eine Statusseite außerhalb des eigenen Netzes erklärt Ihren Nutzern, was los ist.
- Keine Gegenmaßnahmen gegen die Quellen. Rückangriffe und Belastungstests über fremde Dienste sind Straftaten, in Österreich nach § 126b StGB und in Deutschland nach § 303b StGB, und bei Verstärkungsangriffen träfen sie ohnehin unbeteiligte Dritte.
- Danach die richtige Frage stellen. Ein Vorfall, der mit einer Null Route endet, ist keine Konfigurationsfrage, sondern eine Vertragsfrage. Die Antwort liegt nicht in Ihrer
nftables-Datei, sondern in der Filterkapazität desjenigen, der Ihre Leitung betreibt. Den vollständigen Ablauf für einen laufenden, schweren Angriff beschreibt Schwerer DDoS-Angriff: was tun.
Wann Nullrouting doch die richtige Wahl ist
Dieser Abschnitt gehört dazu, weil ein Text, der ein Verfahren nur schlechtmacht, unehrlich wäre. Es gibt vier Lagen, in denen eine Null Route die sachlich richtige Entscheidung ist.
Oberhalb der Filterkapazität. Jedes Netz hat eine endliche Kapazität, das gilt ausnahmslos. Übersteigt ein Angriff die vorgehaltene Filterleistung, lautet die Wahl nicht mehr "filtern oder nullrouten", sondern "ein Kunde offline oder alle Kunden offline". Dann ist die Null Route richtig, und zwar sofort. Der entscheidende Unterschied zwischen Anbietern ist deshalb nicht, ob es eine solche Schwelle gibt, sondern wo sie liegt und ob sie die letzte Stufe ist oder die erste Antwort.
Gegen eine überschaubare Zahl bekannter Quellen. Das quell-basierte Verfahren aus RFC 5635 verwirft nach Absender statt nach Ziel. Das Opfer bleibt erreichbar, der Angreifer nicht. Es braucht aktive Rückwegprüfung und wirkt nicht gegen gefälschte Absender, aber wo beides passt, ist es die bessere Null Route.
Auf dem eigenen Server gegen einen bekannten Einzelstörer. ip route add blackhole 203.0.113.42 ist deutlich billiger als eine lange Firewall-Kette, weil der Routingnachschlag ohnehin für jedes Paket stattfindet. Für eine Handvoll Adressen, die dauerhaft stören, ist das ein ordentliches Werkzeug, solange Sie wissen, dass es nur den Rückweg trifft.
Für eine Adresse, die ohnehin nicht mehr gebraucht wird. Ein abgeschalteter Dienst, eine ausgemusterte Adresse, ein Missbrauchsfall: Hier gibt es keine legitimen Nutzer, die man mitverliert, und damit auch keinen Einwand.
Was Nullrouting dagegen nicht sein darf, lässt sich ebenso klar benennen. Es darf nicht die Standardantwort auf jeden Angriff sein. Die Schwelle darf nicht so niedrig liegen, dass ein Angriff, den jede ordentliche Filterung nebenbei erledigt, den Dienst stilllegt. Das Zeitfenster darf nicht um Größenordnungen länger sein als der Angriff. Der Kunde muss erfahren, dass es passiert ist, und wann es endet. Und es darf nicht als "DDoS-Schutz" verkauft werden, denn geschützt wird dabei das Netz, nicht der Dienst des Kunden.
Was KernelHost stattdessen macht
Zweistufige Filterung statt Abschaltung
Bei KernelHost ist Nullrouting nicht die Antwort auf einen Angriff. Der angegriffene Verkehr wird gefiltert, die IP-Adresse bleibt im Netz, und verworfen werden nur die schädlichen Pakete. Der Schutz ist zweistufig aufgebaut und dauerhaft aktiv, ohne dass Sie ihn bestellen, einschalten oder konfigurieren müssen:
- Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen. Das ist die Kapazität, die darüber entscheidet, wo die weiter oben beschriebene Schwelle liegt.
- Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und Paket für Paket verworfen, während der Verkehr Ihrer Nutzer weiterläuft.
Zwei Eigenschaften sind im Ernstfall entscheidend. Der Schutz läuft permanent und ist ab der Bereitstellung des Servers aktiv, er muss einen Angriff also nicht erst erkennen, um zu wirken. Und er ist in jedem Serverpaket ohne Aufpreis enthalten, vom KVM-Rootserver bis zum Dedicated Server. Welche Dienste und Protokolle eigene Filterprofile haben, listet Gameserver-DDoS-Schutz in Echtzeit, die Einordnung für Spieleprojekte steht in Game-DDoS-Schutz mit Echtzeit-Filterung.
Advanced DDoS Protection für dauerhaft beschossene Projekte
Manche Projekte werden nicht gelegentlich getroffen, sondern gezielt und über Wochen, jeden Abend zur selben Zeit und mit wechselnden Mustern. Genau das sind die Projekte, die anderswo als Erste nullgeroutet werden. Dafür gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:
- Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
- Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich, ohne Ticket: Der Nutzport bekommt andere Regeln als der Abfrageport, und genau diese Unterscheidung ist das, was eine Route nie treffen kann.
- Änderungen greifen in Echtzeit, Sie können also mitten im laufenden Angriff nachjustieren, statt auf ein Wartungsfenster zu warten.
- Schutzprofil passend zum jeweiligen Dienst, ebenso für modifizierte und selbst geschriebene Anwendungen auf beliebigen TCP- oder UDP-Ports.
Die Advanced DDoS Protection richtet sich an KernelHost-Kunden und setzt einen Server bei KernelHost voraus. Wenn Ihr Projekt derzeit woanders läuft und dort regelmäßig stillgelegt wird, ist der Umzug hierher der Weg, nicht eine Fernbetreuung Ihrer bisherigen Adresse. Was Sie unabhängig davon auf dem Server selbst absichern können, steht in Server vor DDoS-Angriffen schützen.
Die beiden Stufen im Vergleich
| Merkmal | Inkludierter DDoS-Dauerschutz | Advanced DDoS Protection |
|---|---|---|
| Preis | in jedem Serverpaket enthalten, ohne Aufpreis | ab 50,00 € im Monat, PrePaid |
| Filterkapazität | 17 Tbps globales Scrubbing plus Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main | dieselbe zweistufige Filterung |
| Aktiv ab | Bereitstellung des Servers | Bereitstellung der Schutz-IP |
| IP-Adresse | die IP-Adresse Ihres Servers | zusätzliche dedizierte Schutz-IP |
| Regelwerk | automatische Profile, keine Konfiguration nötig | eigene Regeln je Port und Protokoll im Kundenbereich |
| Änderungen | laufen automatisch mit | greifen in Echtzeit, auch während eines Angriffs |
| Nullrouting als Reaktion auf einen Angriff | nein | nein |
| Laufzeit | an das Serverpaket gebunden | PrePaid, keine Mindestlaufzeit, keine Kündigungsfrist, keine Einrichtungsgebühr |
Häufige Missverständnisse zum Nullrouting
"Nullrouting schützt meinen Server": Es schützt das Netz, in dem Ihr Server steht, und das ist etwas anderes. Für Ihren Dienst ist das Ergebnis ununterscheidbar von einem erfolgreichen Angriff.
"Wenn die Adresse nullgeroutet wird, ist der Angriff vorbei": Meistens umgekehrt. Der Angriff endet nach Sekunden bis Minuten, die Route bleibt für das gesamte vereinbarte Zeitfenster stehen. Der größere Teil des Ausfalls entsteht nach dem Angriff.
"Eine neue IP-Adresse löst das Problem": Nur bis die neue Adresse öffentlich ist, und das ist sie bei einem Spieleserver in dem Moment, in dem sich der erste Spieler verbindet. Ein Adresswechsel ist Zeitgewinn, keine Lösung.
"Nullrouting ist dasselbe wie eine Firewall-Regel": Beide verwerfen Pakete, aber an entgegengesetzten Enden. Die Firewall entscheidet je Paket am Ende der Leitung und kennt Ports, Protokolle und Raten. Die Null Route entscheidet je Adresse am Anfang der Leitung und kennt nur die Adresse.
"Ich hätte es gemerkt, wenn mein Anbieter nullroutet": Eine Null Route über 20 Minuten um vier Uhr morgens sieht in Ihrer Überwachung wie ein kurzer Ausfall aus. Ohne Messung der eingehenden Paketrate ist sie von einem Dienstabsturz nicht zu unterscheiden.
"Mein Anbieter macht das aus Bequemlichkeit": In der Regel nicht. Er trifft eine Abwägung zwischen einem Ausfall und vielen, und die fällt in dem Moment eindeutig aus. Die berechtigte Frage ist nicht, ob er das darf, sondern ab welcher Angriffsgröße er dazu gezwungen ist, und das ist eine Frage der Filterkapazität, die er vorhält.
Kurz zusammengefasst
- Nullrouting ist eine Route auf
discardbeziehungsweisenull0: Pakete an diese Zieladresse werden verworfen, statt weitergeleitet zu werden. Auf Linux heißt der Befehlip route add blackhole 203.0.113.42, auf Routern lautet dieselbe AnweisungNull0oderdiscard. - Remotely Triggered Black Hole Filtering nach RFC 5635 verteilt diese Route per BGP über ein ganzes Netz und, mit der Community
65535:666aus RFC 7999, bis zu den Vorleistern. Es wirkt in Sekunden, weil eine einzige Ankündigung genügt. - Netzbetreiber setzen es ein, weil ein Angriff auf einen Kunden die gemeinsame Leitung sättigt und alle anderen mitnimmt. Nullrouting opfert einen, um hunderte zu retten. Diese Entscheidung ist rational und in ihrer Lage richtig.
- Für den Betroffenen bedeutet es: Der Server läuft weiter, ist aber aus dem Internet nicht erreichbar, häufig auch nicht in ausgehender Richtung. Typische Zeitfenster reichen von Minuten bis 24 Stunden mit automatischer Aufhebung.
- RFC 5635 sagt selbst, dass der Schaden für das Ziel damit "vollständig" ist, weil Angriffsverkehr und legitimer Verkehr gleichermaßen verworfen werden. Nullrouting verhindert den Ausfall nicht, es stellt ihn her.
- Filterung unterscheidet zwischen Angriffsverkehr und echten Nutzern, Nullrouting unterscheidet nicht. Eine Route kennt genau ein Merkmal, die Zieladresse. Eine Filterregel nach RFC 8955 kennt zwölf, darunter Protokoll, Port, Paketlänge und Rate.
- Die Untersuchung "Down the Black Hole" (ACM IMC 2019) fand an einem großen europäischen Internetknoten, dass nur 27 Prozent der RTBH-Ereignisse mit einer messbaren Verkehrsauffälligkeit einhergingen und dass
/32-Ankündigungen im Mittel nur 50 Prozent des betroffenen Verkehrs tatsächlich verwarfen. - Ob Ihr Anbieter nullroutet, erkennen Sie an drei Dingen: Der Dienst antwortet lokal, von außen kommt nichts an, und die eingehende Paketrate bleibt nahe null. Dazu die Spur von außen, die im Anbieternetz endet, und eine Frage an den Support nach Schwellenwert, Dauer und automatischer Aufhebung.
- Nullrouting bleibt als letzte Stufe richtig, sobald die Angriffsgröße die Filterkapazität übersteigt. Der Unterschied zwischen Anbietern ist deshalb nicht, ob es eine Schwelle gibt, sondern wo sie liegt.
- Bei KernelHost ist Nullrouting nicht die Antwort auf einen Angriff: Die IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Der zweistufige Dauerschutz mit 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk und Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main ist in jedem Serverpaket ohne Aufpreis enthalten und ab Bereitstellung aktiv. Die Advanced DDoS Protection ergänzt ihn ab 50,00 € im Monat um eine dedizierte Schutz-IP und selbst verwaltbare Regeln je Port.
Läuft Ihr Projekt bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem einen Ausfall, bei dem der Server lokal einwandfrei antwortet, eröffnen Sie ein Support-Ticket mit Zeitpunkt, Adresse, Zielport und gemessener Paketrate, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.
Häufige Fragen
Was ist Nullrouting?
Was ist der Unterschied zwischen Nullrouting und DDoS-Filterung?
Was ist Remotely Triggered Black Hole Filtering (RTBH)?
Was bedeutet die BGP-Community 65535:666?
Warum nullrouten Anbieter überhaupt?
Wie lange dauert ein Nullrouting?
Woran erkenne ich, dass meine IP-Adresse nullgeroutet wurde?
Was kann ich tun, wenn mein Server gerade nullgeroutet ist?
Hilft ein Wechsel der IP-Adresse gegen Nullrouting?
Wie lege ich unter Linux selbst eine Null Route an?
Ist Nullrouting jemals die richtige Maßnahme?
Wird mein Server bei KernelHost während eines Angriffs nullgeroutet?
Was kostet DDoS-Schutz bei KernelHost und wann brauche ich Advanced DDoS Protection?
2026 KernelHost GmbH. Alle Rechte vorbehalten. Diese Anleitung ist urheberrechtlich geschützt. Eine Veröffentlichung auf anderen Webseiten, auch auszugsweise oder in bearbeiteter Form, ist ohne unsere schriftliche Zustimmung nicht gestattet. Zitate mit Quellenangabe und Link sind ausdrücklich willkommen.

