18. Oktober 2026
·
7 Min. Lesezeit
Geben Sie Ihre AS-Nummer ein und prüfen Sie, ob Ihre Präfixe während eines DDoS-Angriffs zu einem Scrubbing-Center umgeleitet werden können, was an Ihrem AS-SET nicht stimmt und wer Ihr AS noch in sein eigenes aufgenommen hat. Schritt-für-Schritt-Korrekturen für alle fünf RIRs, zehn Sprachen, ohne Konto.
Wir veröffentlichen ein kostenloses Werkzeug, das einem Netzbetreiber oder Rechenzentrum allein anhand der AS-Nummer zeigt, ob seine Präfixe für die Umleitung zu einem Scrubbing-Center während eines DDoS-Angriffs bereit sind, und es durch jede Korrektur bei seiner Registry führt. Außerdem prüft es die Hygiene des AS-SETs, aus dem Ihre Upstreams die Filter für Ihre Routen bauen. Es läuft in zehn Sprachen und ist quelloffen.
Scrubbing-Center-Readiness-Test öffnen · Quellcode auf GitHub
Wir sind gerade von der PLNOG 2026 in Krakau (15.–16. Oktober) zurück. Nach unserem Vortrag haben wir dem Werkzeug weitere Prüfungen hinzugefügt, angeregt durch Vorträge anderer NOGs, die wir während der Konferenz angesehen haben. Vielen Dank an die Autoren – durch ihre Vorträge ist dieses Wissen öffentlich. Alle Quellen stehen am Ende dieses Beitrags, mit Link zur Präsentation und Namen des Autors.
Ein Problem, das erst während eines Angriffs sichtbar wird
Ist ein Angriff größer als Ihre Leitungen, wird der Verkehr zu einem Scrubbing-Center umgeleitet: Von dort werden /24-Präfixe (IPv6: /48) angekündigt, die aus Ihren größeren Blöcken herausgeschnitten sind; der Verkehr wird bereinigt und zurückgeschickt. Damit das funktioniert, müssen die Registries vorher vorbereitet sein. Der ROA muss diese /24 erlauben, in der RIR-Datenbank muss ein Route-Objekt existieren, das AS-SET muss die richtigen Netze enthalten, und gehört der Adressraum jemand anderem, verlangt das Scrubbing-Center eine LOA.
Die häufigste Lücke ist ein ROA, der genau auf das Aggregat angelegt ist, ohne maxLength. Solange nur das Aggregat angekündigt wird, funktioniert alles. Während eines Angriffs wird jedes herausgelöste /24 RPKI-invalid, und validierende Netze verwerfen es. Die Korrektur dauert Minuten, bis sie in den Filtern ankommt, vergehen Stunden, manchmal zwei Tage. RFC 9319 sagt es klar: Ein ROA für einen DDoS-Mitigationsdienst muss vor dem Angriff existieren.
Was zu prüfen ist – und was zu korrigieren
| Was der Test prüft | Was Sie zur Korrektur bekommen | |
|---|---|---|
| 🛡️ | ROAs – wird jedes aus Ihren Blöcken herausgelöste /24 (/48) RPKI-valid sein? | fertige ROAs zum Einfügen: einer pro /24 (RFC 9319) oder maxLength auf dem Aggregat |
| 📒 | Route-Objekte – liegen sie in einer RIR-Datenbank und nicht nur in RADB oder einer anderen Registry, die Betreiber nicht akzeptieren? Gibt es veraltete Objekte mit anderem Origin? | fertige Route-Objekte in RPSL; welche Objekte zu löschen sind |
| 📝 | LOA – gehört der Adressraum einer anderen Organisation oder ist es PA-Adressraum eines LIR? | eine LOA-Vorlage mit den Präfixen und ihren Inhabern |
| 🧹 | AS-SET-Hygiene – wie viele ASe zieht Ihr Set tatsächlich hinein? Verstecken sich IXP- oder Peer-Listen darin? Mitglieder, die gegangen sind? | was zu kürzen ist, und die Faustregel: Würden Sie das in BGP weiterverbreiten? |
| 🕵️ | Wer Ihr AS aufnimmt – welche Netze ohne BGP-Beziehung zu Ihnen haben Ihr AS in ihre AS-SETs eingetragen? | die Liste der zu prüfenden Sets, wen Sie um Entfernung bitten, ASPA und Monitoring |
| 🔗 | ASPA, Abuse-Kontakt, PeeringDB, Upstreams – einschließlich des AS des Scrubbing-Centers, wenn Sie es angeben | die genaue Stelle, an der Sie jedes davon in Ihrer Registry setzen |
| 📏 | Präfixlänge – ist etwas länger als /24 oder /48 und wird gefiltert? | welche Präfixe zu ersetzen sind |
| 🧾 | Was von außen nicht prüfbar ist – Wortlaut der LOA, Tunnel und MSS, Propagationszeit, Ankündigung und Rücknahme, Routing-Schleifen, Filterung bei Kunden, Trockenlauf | eine Checkliste für die Abstimmung mit Ihrem Scrubbing-Center |
Am Ende steht ein Urteil – ✅ bereit, ⚠️ bereit mit Vorbehalten, ❌ nicht bereit – und ein 🔧 Maßnahmenplan in sinnvoller Reihenfolge, mit Anleitungen für Ihre eigene Registry.
Ihr AS-SET ist ein Sicherheitsobjekt, keine Dokumentation
Upstreams – und Scrubbing-Center – bauen den Filter für die Routen, die sie von Ihnen annehmen, aus Ihrem AS-SET. RPKI-ROAs validieren nur das Origin-AS; der Transitteil des Pfads wird durch diese registrybasierten Filter geschützt. Damit ist das AS-SET ein Sicherheitsobjekt. Das Werkzeug prüft es aus drei Blickwinkeln.
Größe. Wenn sich Ihr AS-SET auf Tausende Netze ausdehnt, passiert ein Route-Leak eines Ihrer Kunden den Filter Ihres Upstreams. Wir vergleichen das aufgelöste Set mit den in BGP tatsächlich sichtbaren Kunden und markieren Sets, die um ein Vielfaches größer, tief verschachtelt oder von einem einzigen Mitglieds-Set dominiert sind.
Inhalt. Ein Set für die Filterung sollte Ihren Kundenkegel enthalten und sonst nichts. IXP-Mitgliederlisten und Peer-Listen darin lassen es explodieren. Die Faustregel ist einfach: Würden Sie das in BGP weiterverbreiten? Wenn nicht, gehört es nicht in Ihr AS-SET. Das Werkzeug listet auch Mitglieder auf, die nicht mehr als Ihre Kunden sichtbar sind.
Wer Sie aufnimmt. Jeder kann Ihr AS in sein AS-SET eintragen. Mit gefälschtem Origin ist die Ankündigung ROA-valid und passiert registrybasierte Transitfilter. Das Werkzeug listet jedes AS-SET auf, das Ihr AS enthält, markiert die von Netzen ohne BGP-Beziehung zu Ihnen und sagt, was zu tun ist: um Entfernung bitten, ASPA veröffentlichen und die Registries überwachen.
Fünf Registries, zehn Sprachen
Die Schritte unterscheiden sich von Registry zu Registry, und das Werkzeug weiß das. Bei APNIC erzeugt ein Formular ROA und Route-Objekt zusammen; bei LACNIC werden Route-Objekte aus ROAs erzeugt, sodass ein /24-Route-Objekt einen ROA pro /24 braucht; bei ARIN hat das IRR keine Maintainer-Objekte, und der Zugang richtet sich nach den Kontakten Ihrer Organisation. Die Anleitungen decken RIPE NCC, ARIN, APNIC, AFRINIC und LACNIC ab, jeweils mit Link zur Dokumentation der Registry.
Die Oberfläche funktioniert auf Polnisch, Englisch, Deutsch, Französisch, Spanisch, Portugiesisch, Italienisch, Niederländisch, Tschechisch und Rumänisch, in einem hellen und einem dunklen Design.
Auf dem eigenen Rechner ausführen
Das Werkzeug läuft im Browser und hat keinen Server: Der Browser fragt öffentliche Dienste direkt ab – die RIPE-Datenbank, RIPEstat, die RIR-Registries (RDAP), IRR Explorer und PeeringDB. Sie können es auch herunterladen und lokal ausführen: start.bat unter Windows, start.sh unter Linux und macOS oder Docker. Mit installiertem bgpq4 (im Docker-Image bereits enthalten) ergänzt die lokale Version Präfixlisten, die aus Ihren AS-SETs gebaut werden: Präfixanzahl, eine Junos-prefix-list und die vollständige Liste als Datei.
Der Code steht unter AGPL-3.0, der Inhalt unter CC BY-SA 4.0. Anleitungen zum Herunterladen und Ausführen finden Sie im README (auf Englisch).
Worauf die Tests beruhen
Jede Prüfung folgt einer veröffentlichten Quelle: IETF-RFCs (6811, 9319, 9582, 7454, 6483, 2622 und die ASPA-Drafts), Dokumenten des RIPE NCC und der Dokumentation aller fünf RIRs, MANRS sowie den öffentlichen Onboarding-Anforderungen bekannter Scrubbing-Center-Betreiber. Die AS-SET-Prüfungen bauen auf Vorträgen von Lasse Jarlskov (Telia Company) auf – „Securing your AS-set” auf der BalticNOG 2025 und „Prelude to a BGP hijack?” auf der DKNOG15 – sowie auf „The Scourge of Excessive AS-SETs” von Doug Madory und Job Snijders. Die vollständige Liste mit Autoren und Links steht im Quellenabschnitt des README.
Wann Sie uns anrufen sollten
Das Werkzeug zeigt, was in den Registries zu korrigieren ist. Die Umleitung ist nur ein Teil des Schutzes: Zuerst muss der Angriff innerhalb von Sekunden erkannt und am Rand Ihres eigenen Netzes gefiltert werden, und die Übergabe an ein Scrubbing-Center braucht ein vorab abgestimmtes Verfahren. Wenn Sie das vor dem ersten Angriff mit uns durchgehen möchten, nehmen Sie Kontakt auf.
