Zusammenfassung

  • Die bekannte Community BLACKHOLE ist eine beratende Bitte, Verkehr zum markierten Präfix zu verwerfen. Der Empfänger entscheidet lokal und braucht eine Vereinbarung auf der konkreten Session sowie die Werbeberechtigung des Nachbarn für ein überdeckendes Präfix.
  • Zielbasiertes RTBH akzeptiert eine spezifischere Route, um sie auf discard/null aufzulösen. Dadurch verschwindet Angriffslast vor dem Engpass, zugleich aber jeder legitime Verkehr zum Ziel.
  • Der Nachweis muss rohes UPDATE, Präfixautorisierung, Incident-Freigabe, ROV, Import-Policy, Begrenzung, RIB, FIB, Zähler, Pakete, Rücknahme und Wiederherstellung verbinden. Established belegt nur den Zustand der Session.

Ein Ziel opfern, damit der Anschluss überlebt

Ein synthetisches Beispiel: Ein Transitkunde wird auf 203.0.113.19 volumetrisch angegriffen. Der Access-Link ist voll, bevor ein Filter beim Kunden wirksam werden kann. Der Kunde kündigt seinem Provider 203.0.113.19/32 mit BLACKHOLE an. Die Session ist für den Dienst freigeschaltet, und der Provider kennt die Berechtigung des Kunden für 203.0.113.0/24.

Der Provider nimmt /32 an, hält die Route im eigenen Ausführungsbereich und programmiert an den Ingress-Routern eine Verwerfung. Der Angriff passiert den knappen Link nicht mehr. Legitime Pakete zum Host ebenfalls nicht. Andere Adressen im /24 bleiben erreichbar. Die Zieladresse wurde nicht gerettet, sondern zugunsten der Umgebung geopfert.

Später kündigt eine Automatisierung irrtümlich 203.0.113.91/32 an, einen gesunden Dienst im selben Aggregat. Peer, Überdeckung und Community stimmen. Sind das die einzigen Prüfungen, führt der Provider eine formal zulässige Anweisung mit falscher Incident-Absicht aus. Die BGP-Session bleibt stabil; der zweite Dienst wird still.

Die Szene behauptet keinen realen Ausfall. Sie zeigt eine reale Grenze: Das Recht, innerhalb eines Adressblocks zu announcen, beweist nicht die aktuelle Absicht, gerade diesen Host abzuschalten.

Gemeinsame Semantik ist keine globale Befehlsgewalt

IANA registriert BLACKHOLE als 0xFFFF029A, häufig dargestellt als 65535:666. RFC 7999 definiert die Community als well-known, advisory und transitive für zielbasiertes Blackholing. Ein gemeinsamer Wert ersetzt viele providerspezifische Trigger.

Annahme und Ausführung oder Ignorieren bleiben jedoch Wahl jedes Operators. In einer bilateralen Beziehung müssen beide Netze die Nutzung vorab vereinbaren. Ohne ausdrückliche Konfiguration sollte ein Gerät Verkehr nicht allein wegen des Codes verwerfen.

Die Standardisierung macht den Sender nicht zum Administrator der Forwarding-Ebene des Empfängers. Der Sender stellt eine Anfrage. Der Empfänger prüft Session, Präfix und lokale Policy. Ein Netz kann den Wert verstehen und den Dienst nicht anbieten; ein Collector kann ihn speichern, ohne irgendein Paket zu beeinflussen.

Heng Lus Minimum Initial Specification beschreibt diese Grenze präzise. Gemeinsam sind nur stabiler Codepunkt und enge Bedeutung. Kundenzulassung, Geschäftsmodell, Region, Geräteumfang und Laufzeit bleiben lokal. Localized Future Decision erlaubt Annahme oder Ablehnung ohne zentrale Sanktion. Voluntary Adoption verlangt Implementierung und Nutzung: Dokument und Registry-Eintrag erzeugen noch keine Verwerfung.

Wenn die beste Route Nichtzustellung bedeutet

RFC 5635 beschreibt eine Route zu einem Null- oder Discard-Interface. Eine BGP-Policy lässt die spezifischere Zielroute auf diesen Next Hop auflösen. Pakete sterben nahe den Eintrittspunkten, bevor sie die Kapazität bis zum Kunden verbrauchen.

Die Route kann syntaktisch korrekt, ausgewählt und in der Loc-RIB vorhanden sein. Ihre programmierte Wirkung ist trotzdem Nichtzustellung. Loc-RIB-Präsenz beweist weder normale Erreichbarkeit noch die tatsächliche Verwerfung. Dafür müssen FIB-Eintrag, Next-Hop-Auflösung und Disposition jeder Ingress-Klasse geprüft werden.

Zielbasiertes RTBH unterscheidet nicht zwischen Angriff und legitimer Nutzung. Es nimmt das Ziel vollständig offline und begrenzt dafür den Kollateralschaden. Ein Bericht braucht deshalb zwei Achsen: geschützte gemeinsame Kapazität und Verfügbarkeit des geopferten Dienstes. Sinkende Linkauslastung kann gleichzeitig erfolgreiche Eindämmung und vollständigen Serviceverlust bedeuten.

„Mitigiert“ muss ein Objekt nennen. Für das Backbone kann die Maßnahme erfolgreich sein, für den Kundendienst nicht.

Zwei RFC-Sperren und eine fehlende Incident-Sperre

RFC 7999 verlangt bilateral zwei Bedingungen. Das Blackhole-Präfix muss von einem gleichen oder kürzeren Präfix überdeckt sein, das der Nachbar ankündigen darf. Außerdem muss der Empfänger vereinbart haben, BLACKHOLE auf genau dieser Session zu honorieren.

Die erste Bedingung verhindert, dass ein Kunde fremde Ziele verwirft. Die zweite verhindert, dass jedes Peering unbeabsichtigt zum Abschaltkanal wird. Beide begrenzen Raum und Beziehung.

Sie beweisen nicht die aktuelle Incident-Absicht. Ein falsches /32 kann im richtigen /24 liegen. Zugangsdaten können kompromittiert, alte Requests später erneut gesendet werden. Ein UPDATE enthält keinen allgemein prüfbaren Datensatz zu Freigebendem, Dienst, Grund, Ablauf und Rücknahmeverantwortung.

Diese dritte Sperre muss das Betriebssystem um BGP liefern. Für jede Aktivierung werden Requester, Incident-ID, exaktes Präfix, Dienst, Begründung, Scope, Freigabezeit, Ablauf und Withdrawal Owner gespeichert. Der Datensatz wird mit Peer, AFI/SAFI und Policy-Version verbunden.

Der Präfixfilter beantwortet, ob der Kunde in diesem Raum announcen darf. Das Incident-Register beantwortet, ob eine berechtigte Person dieses Ziel jetzt wirklich opfern will. Manuelle Freigabe ohne deterministischen Filter lädt Tippfehler ein; Filter ohne Incident-Kontext gewährt der Automatisierung ein dauerhaftes Abschaltrecht über den gesamten Block.

Host-Genauigkeit braucht einen kontrollierten Ausnahmeweg

RFC 7999 empfiehlt möglichst spezifische Präfixe, typisch /32 für IPv4 und /128 für IPv6. So bleibt der Adress-Kollateralschaden klein. Das globale Routing filtert jedoch häufig Routen länger als /24 beziehungsweise /48.

Ein interdomain RTBH-Dienst öffnet eine bewusste Ausnahme: Er akzeptiert den Host-Route des Kunden zur lokalen Verwerfung, verhindert aber seine Verbreitung als normale Internetroute. Diese Ausnahme braucht exakte Kundenaggregate, erlaubte Längen je Adressfamilie, Session, Community, Region und lokale Aktion.

Spezifischer bedeutet nicht automatisch richtig. Eine einzelne Adresse kann DNS, Authentisierung oder Steuerung tragen. Ein /24-Blackhole kann bei einem breiten Angriff notwendig sein, opfert aber viele Dienste. Präfixlänge ist eine Blast-Radius-Entscheidung.

Auch Anzahl, Zeit und Ausschlüsse müssen begrenzt sein. Ein einzelner destruktiver Route kann mehr Schaden anrichten als tausende normale Routen. Ein gewöhnliches Maximum-Prefix-Limit erkennt diesen Unterschied nicht.

Den destruktiven More-Specific einschließen

RFC 7999 empfiehlt NO_ADVERTISE, NO_EXPORT oder eine vergleichbare Community. RFC 1997 unterscheidet: NO_ADVERTISE stoppt jede weitere Peer-Ankündigung, NO_EXPORT erlaubt interne Verteilung, verhindert aber das Verlassen des AS oder der Confederation.

Der Provider kann den Route an alle Ingresses oder nur an betroffene Regionen verteilen wollen. Die Begrenzung muss dem tatsächlichen Ausführungsgraphen entsprechen. Zu eng verhindert Schutz; zu weit lässt den More-Specific entkommen.

Ein Leak ist selbst dann gefährlich, wenn das entfernte Netz BLACKHOLE ignoriert, denn Longest-Prefix-Match kann Verkehr anziehen. Wird die Community honoriert, wächst der Verwerfungsbereich. Deshalb empfiehlt RFC 5635 Egress-Präfixfilter.

Die aktuelle FRRouting-Dokumentation sagt, dass bei Empfang von BLACKHOLE automatisch NO_ADVERTISE ergänzt wird. Das ist Implementierungsnachweis für FRR, keine universelle Garantie. Andere Plattformen benötigen explizite Policy; eine Regel, die Communities ersetzt, kann den Schutzwert löschen.

Der Beweis ist Adj-RIB-Out nach Policy für jede relevante Nachbarklasse. Konfiguration beschreibt Absicht; die Ausgangsansicht zeigt, was das Gerät wirklich senden wollte.

Ein authentisierter Kanal kann eine falsche Absicht tragen

BLACKHOLE reist im klassischen COMMUNITIES-Attribut, das RFC 1997 nach lokaler Policy veränderbar macht. RFC 7999 warnt, dass BGP das Hinzufügen, Entfernen oder Ändern nicht spezifisch verhindert; BGPsec löst die Integrität der Community nicht. Unbefugtes Hinzufügen kann einen Denial of Reachability erzeugen.

Session-Schutz mindert Peer-Impersonation, beweist aber nicht, dass der richtige Dienst gewählt wurde. RPKI prüft eine andere Beziehung: Präfix, Origin AS und maxLength. Es signiert weder Community noch Discard-Absicht.

Ein legitimer /32-Blackhole kann RPKI Invalid sein, wenn die ROA nur /24 erlaubt. RFC 7999 verlangt, legitime Signale nicht versehentlich durch Origin Validation zu blockieren. Eine pauschale Ausnahme für jede markierte Route wäre riskant: Ein veränderbares Attribut würde zum Bypass. Jede ROA bis /32 oder /128 zu erweitern vergrößert wiederum die Menge validierbarer More-Specifics.

Ein individuelles Internet-Draft schlug 2022 eine signierte RPKI Discard Origin Authorization vor. Es ist abgelaufen und besitzt keinen formalen IETF-Status. Es belegt die Lücke, nicht die Existenz einer heute standardmäßig verfügbaren Lösung.

Die aktuelle Vertrauenskette bleibt zusammengesetzt: Peer-Identität, genauer Präfixfilter, erklärtes ROV-Verhalten, Community, Incident-Freigabe, lokaler Scope und beobachtete FIB. Kein grüner Status ersetzt den Rest.

Vier Maßnahmen sauber trennen

Zielbasiertes RTBH verwirft alles zum Opfer. Quellbasiertes RTBH kombiniert Discard-Routen mit uRPF, sodass die Source-Prüfung an gewählten Eingängen scheitert. RFC 5635 fordert eine andere Community und warnt davor, solche Source-Trigger gewöhnlich von externen Peers anzunehmen.

FlowSpec verteilt Match- und Action-Regeln in einer anderen NLRI; RFC 7999 schließt BLACKHOLE dafür aus. Ein Sinkhole leitet Verkehr zur Beobachtung um. Scrubbing versucht legitime Pakete zu erhalten. Destination-Blackholing analysiert und säubert nicht, sondern löscht.

Der Incident-Datensatz muss den Mechanismus und das erwartete Kundenergebnis nennen. Soll der angegriffene Dienst online bleiben, ist Destination RTBH ein letzter Kapazitätsschutz und kein Verfügbarkeitsnachweis.

Vom UPDATE bis zum fehlenden Paket beweisen

Vor der Freischaltung stehen Kunde, exakte Session, AFI/SAFI, Aggregate, Längen, Community, geschützte Ausschlüsse, Regionen, ROV-Regel, Höchstdauer und Withdrawal Owner fest.

Je Trigger werden bewahrt:

  1. rohes UPDATE, Zeit, Peer, AS_PATH, Origin, Next Hop und alle Communities;
  2. exakter Autorisierungsfilter und dessen Quelle;
  3. ROV-Zustand und angewandte Regel;
  4. getroffener Import-Term, Begrenzung und Next-Hop-Änderung;
  5. Adj-RIB-In, Loc-RIB-Auswahl und Grund;
  6. FIB jeder Ingress-Klasse mit Discard-Auflösung;
  7. Drop-Zähler mit Gerät, Interface, Semantik und Baseline;
  8. Paketbeobachtung vor und nach der Verwerfungsgrenze;
  9. Adj-RIB-Out jedes Nachbarn, der den Route nicht erhalten darf;
  10. Withdrawal, FIB-Entfernung, Rückkehr der normalen Route und Service-Probes.

UPDATE beweist Eingang, Policy die Entscheidung, RIB die Auswahl, FIB die ausführbare Anweisung und Pakete die Folge. Die Ausgangssicht beweist Begrenzung. Die Wiederherstellung beweist das Ende der Autorität.

Ein einzelnes „Blackhole aktiv“ unterscheidet keine nicht ausgewählte Route, fehlerhafte Next-Hop-Auflösung, teilweise programmierte Flotte oder stale FIB nach Withdrawal. RFC 7999 empfiehlt langfristige UPDATE-Aufbewahrung; eine belastbare Prüfung speichert zusätzlich Policy, FIB, Zähler und Freigabe.

Opfer und Rückkehr canary-testen

Ein sicher messbares Canary-Präfix durchläuft jede Sessionklasse, Adressfamilie, Region, Plattform und Version. Der Test akzeptiert den autorisierten Fall und verweigert fremdes Präfix, falsche Session und unzulässige Länge. Er prüft Begrenzung, FIB, Zähler, eingeschränkten Paketeffekt und Rückkehr nach Withdrawal.

Pausieren bei fehlendem Live-Incident, geschütztem Endpoint, unerklärtem ROV, fehlender Begrenzung, unerwartetem eBGP-Export, divergenter FIB, fehlendem Ablauf oder Withdrawal Owner. Zurückrollen bei falschem Serviceverlust, wachsendem Scope, Leak, Schaden außerhalb des Präfixes oder nicht rekonstruierbarer Aktion.

Withdrawal eröffnet den Rollback, schließt ihn nicht ab. Discard muss aus jeder FIB verschwinden, die normale Route zurückkehren und Probes müssen Zustellung zeigen. Forwarding ist reversibel; Verantwortlichkeit wird es nicht, wenn die Belege ablaufen.

Quellen