Prefix-Filtering-Best-Practices: Hijacks und Leaks verhindern

Prefix-Filtering-Best-Practices sind eine der effektivsten und zugleich unterschätzten Maßnahmen, um Hijacks und Leaks im Internet-Routing zu verhindern. Während BGP technisch „nur“ Routen verteilt, entscheidet Ihre Policy darüber, welche Routen Sie akzeptieren, welche Sie weitergeben und welche Sie konsequent blockieren. Genau hier passieren die gefährlichsten Fehler: Ein Kunde kündigt versehentlich Transit-Routen an (Route Leak), ein falsches Origin-AS wird akzeptiert (Hijack), oder zu breite Export-Policies machen Sie unbeabsichtigt zur Leak-Quelle. Das Problem ist dabei selten ein einzelner „großer Knall“. Häufig beginnt es mit einer unscheinbaren Fehlkonfiguration oder einem Automationsfehler, der erst unter Last, nach einem Session-Reset oder nach einem Change eskaliert. Ein gutes Prefix Filtering schützt nicht nur das globale Internet, sondern auch Ihr eigenes Backbone: weniger unerwartete Traffic-Shifts, weniger Congestion durch falsche Pfade, weniger eskalierende NOC-Tickets und deutlich kürzere MTTR bei Routing-Vorfällen. Dieser Leitfaden zeigt praxisnah, wie Provider und Netzbetreiber Prefix-Filtering-Best-Practices umsetzen: rollenbasierte Policies (Customer/Peer/Transit), Prefix-Listen und IRR/RPKI-gestützte Filter, Max-Prefix-Guardrails, AS-PATH- und Community-Strategien, Monitoring über Prefix Count und Churn sowie Change-Validation-Schritte, die Hijacks und Leaks zuverlässig verhindern.

Warum Prefix Filtering der wichtigste „Safety Belt“ im BGP ist

BGP ist grundsätzlich vertrauensbasiert: Ein Nachbar kann Routen announcen, und ohne strenge Filter und Rollenlogik würden Sie diese Routen potenziell akzeptieren und weiterverbreiten. Prefix Filtering ist deshalb weniger ein Feature als ein Sicherheits- und Qualitätsstandard. Es adressiert zwei Hauptprobleme:

• Hijacks: Ein AS kündigt ein Präfix an, das ihm nicht gehört (falsches Origin), oft mit dem Ziel, Traffic abzufangen oder umzuleiten.
• Route Leaks: Routen werden an eine Richtung propagiert, für die sie nicht bestimmt sind (z. B. Customer annonciert Transit-Routen, Peer propagiert Transit weiter).

Für das Protokoll selbst ist RFC 4271 die grundlegende Referenz. Für rollenbasierte Leak-Vermeidung ist RFC 9234 besonders relevant, weil es BGP-Rollen (Customer/Peer/Provider) als operatives Konzept formalisiert.

Grundprinzip: Rollenbasierte Policies statt „One Size Fits All“

Der häufigste Designfehler ist, Prefix Filtering pro Session „ad hoc“ zu bauen. Besser ist ein klares Rollenmodell, das Templates ermöglicht und Fehlerquellen reduziert:

• Customer: darf nur definierte Kundenpräfixe announcen (und ggf. deren erlaubte Deaggregation), niemals Full Table.
• Peer: darf in der Regel eigene und Kundenpräfixe announcen, aber keine Transit-Routen.
• Transit/Upstream: darf sehr viele Präfixe senden; hier sind andere Guardrails nötig (RPKI, Monitoring, Traffic-Engineering-Policies).

Dieses Rollenmodell ist die Grundlage für jede Filter-Entscheidung: Was ist normal, was ist verdächtig, und welche Limits sind sinnvoll?

Inbound Prefix Filtering: Was Sie akzeptieren sollten

Inbound Filtering ist Ihr erster Schutzwall. Ziel: Sie akzeptieren nur Routen, die der Nachbar gemäß Rolle senden darf. Dabei ist es wichtig, zwischen „received“ (pre-policy) und „accepted“ (post-policy) zu unterscheiden, um Fehlerszenarien sauber zu erkennen.

Best Practice 1: Kundenpräfixe strikt whitelisten

Für Customer-Sessions ist das Prinzip einfach und sehr wirksam: Whitelist statt „best effort“. Sie pflegen eine erlaubte Präfixliste (und ggf. Längenbereiche) pro Kunde. Alles andere wird verworfen.

• Vorteil: Route Leaks aus Customer-Richtung werden effektiv verhindert.
• Risiko: Kundenänderungen (neue Präfixe, Migrationen, DDoS-Deaggregation) müssen als Change-Prozess behandelt werden.
• Praxis-Tipp: Nutzen Sie ein Self-Service- oder Ticket-basiertes Prefix-Onboarding mit Review.

Best Practice 2: Max-Prefix als Notbremse pro Session

Max-Prefix schützt Sie vor „massenhaften“ Fehlern: Ein Kunde annonciert plötzlich tausende Präfixe, ein Peer sendet unerwartet weit mehr als vereinbart. Max-Prefix ersetzt keine Filter, aber es verhindert, dass ein einzelner Fehler Ihre Control Plane und Ihr Routing destabilisiert.

Max-Prefix-Logik als Guardrail (MathML)

$\mathrm{Trigger}\Leftarrow \mathrm{Prefixes}\_\mathrm{received}>\mathrm{MaxPrefixes}$

• Best Practice: Zwei Schwellen definieren: Warnschwelle (z. B. 80–90%) und Hard Limit (Schutz).
• Best Practice: Separate Limits für IPv4 und IPv6, da Größenordnungen unterschiedlich sind.
• Risiko: Hard Limit kann Session resetten und Traffic verschieben; daher pro Rolle passend wählen.

Best Practice 3: RPKI-basierte Origin Validation integrieren

RPKI ergänzt Prefix Filtering um kryptografische Origin-Validierung. Damit können Sie viele Hijacks als „Invalid“ erkennen und entsprechend behandeln. Für die Umsetzung sind RFC 6811 (Origin Validation) und RFC 8210 (RPKI-to-Router, RTR) wichtige Referenzen. Ein bewährter Ansatz ist stufenweises Rollout: beobachten (taggen), depräferieren, dann invalid droppen.

• Vorteil: Reduziert erfolgreich angenommene Hijacks (falsches Origin-AS).
• Risiko: Falsch gesetzte ROAs (maxLength, Origin-Wechsel) können legitime Routen „Invalid“ machen.
• Mitigation: Monitoring der Invalid-Rate und schnelle ROA-Fix-Prozesse mit Kunden.

Best Practice 4: AS-PATH- und Rollen-Checks (wo sinnvoll)

Prefix Listen prüfen „was“, AS-PATH-Checks helfen bei „woher“. Für Customer-Sessions kann es sinnvoll sein, zu prüfen, dass das Customer-AS im AS-PATH erwartungskonform vorkommt (z. B. als Origin oder in der Nähe des Origin). Für Peers kann man Transit-Signaturen erkennen (plötzlich tauchen viele neue, fremde ASNs in Pfaden auf).

• Vorteil: Zusätzliche Leak-Erkennung, besonders bei komplexen Kunden-Setups.
• Risiko: Zu strenge Regeln können legitime Multi-Homing- und Reseller-Modelle brechen.
• Best Practice: AS-PATH-Checks rollen- und vertragsspezifisch, nicht pauschal.

Outbound Prefix Filtering: Was Sie announcen sollten

Outbound Filtering entscheidet, ob Sie selbst zum Leak-Quelle werden. In vielen realen Großereignissen war die Ursache nicht „bösartig“, sondern ein falsches Export-Template oder ein fehlendes „no-export“. Outbound Filtering ist daher Pflicht für Provider-Qualität.

Best Practice 5: Export-Policies rollenbasiert und minimalistisch halten

• An Customers: typischerweise Full Table oder Teilmengen (nach Produkt), aber keine Routen, die policy-widrig sind (z. B. Peer-only oder Blackhole-Klassen, wenn nicht vereinbart).
• An Peers: eigene + Kundenpräfixe, keine Transit-Routen (kein „Peer als Transit“).
• An Transits: eigene + Kundenpräfixe; zusätzliche TE-Communities gezielt und dokumentiert.

Best Practice 6: Communities sauber standardisieren

Communities sind im Provider-Ökosystem ein wichtiges Steering- und Safety-Werkzeug (no-export, blackhole, scope-tags). Ohne Standardisierung werden sie jedoch zur Fehlerquelle.

• Best Practice: Community-Katalog mit klarer Semantik (intern/extern), inklusive „wer setzt was“.
• Best Practice: Default: keine extern wirksamen Communities aus Kundenrichtung ungeprüft weiterreichen.
• Risiko: Community-Missverständnisse können Export massiv verändern und Leaks auslösen.

Best Practice 7: „No-Transit“-Absicherung für Peerings

Ein praktisches Ziel ist, Peerings technisch so zu gestalten, dass Sie nicht versehentlich Transit für Peers werden. Das ist weniger ein einzelnes Kommando als eine Kombination aus Export-Filtern und Policy-Tests:

• Export an Peer: strikt auf Kunden+eigene Präfixe begrenzen.
• Import von Peer: entsprechend der Peering-Policy begrenzen (kein „ungeprüftes“ Durchreichen).
• Monitoring: advertised prefix count an Peer als Alarmindikator (unerwartete Anstiege sind hochkritisch).

IRR-basierte Filter: Nutzen, Grenzen und Betriebsrealität

IRR (Internet Routing Registry) kann genutzt werden, um Prefix-Listen und AS-Set-basierte Policies automatisiert zu erzeugen. Das ist besonders für große Kundenbasen attraktiv. Der Gewinn kommt aber nur, wenn IRR-Daten gepflegt und Prozesse sauber sind.

• Vorteil: Skalierbares Prefix-Onboarding, weniger manuelle Listenpflege.
• Risiko: veraltete oder falsche IRR-Objekte führen zu falschen Filterlisten (Overblocking oder Leaks).
• Best Practice: IRR-Automation mit Review, Drift-Detection und Fallback (manuelle Override-Liste) kombinieren.

Monitoring: Prefix Filtering ohne Monitoring ist „blind“

Selbst perfekte Filter können im Alltag durch Drift, Change-Fehler oder Sonderfälle aus dem Tritt geraten. Monitoring sorgt dafür, dass Sie nicht erst über Kundentickets lernen, dass etwas schief läuft.

Best Practice 8: Prefix Count Monitoring pro Session (received/accepted/advertised)

Prefix Count ist einer der besten Frühindikatoren für Leaks. Entscheidend ist die Trennung:

• received: zeigt, was der Nachbar sendet (auch wenn Sie es filtern).
• accepted: zeigt, was Sie tatsächlich in Ihr Routing übernehmen.
• advertised: zeigt, was Sie nach außen geben (Leak-Risiko, wenn es unerwartet steigt).

Abweichungsregel (MathML)

$\mathrm{RelDev}=\frac{\mathrm{|P}\_\mathrm{current}-P\_\mathrm{baseline|}}{P\_\mathrm{baseline}}$

Best Practice: Alarmierung mit kombinierter Schwelle (absolut + relativ), damit kleine Sessions nicht „überempfindlich“ sind und große Sessions nicht „unterempfindlich“.

Best Practice 9: Churn Monitoring (Update/Withdraw Rate)

Hijacks und Leaks gehen oft mit ungewöhnlich hohem Churn einher. Selbst wenn Prefix Count nicht extrem springt, kann eine massive Update-/Withdraw-Rate ein Frühindikator sein, dass etwas eskaliert oder Schutzmechanismen (z. B. Max-Prefix) greifen.

• Nutzen: erkennt Storms, Instabilität, beginnende Eskalationen.
• Best Practice: Churn-Alarm pro Rolle unterschiedlich bewerten (Transit hat naturgemäß mehr Bewegung als Customer).

Best Practice 10: „Top-N neue Präfixe/ASNs“ als automatisches Evidence Pack

Bei Alarmen sollte Ihr System automatisch Beispiele liefern: Welche neuen Präfixe sind hinzugekommen? Welche neuen ASNs tauchen im AS-PATH auf? Das beschleunigt Mitigation dramatisch und reduziert Diskussionen.

• Für Customer-Leaks: neue Transits im AS-PATH sind besonders verdächtig.
• Für Hijacks: plötzliches Auftauchen eines Präfixes mit falschem Origin-AS ist ein starkes Indiz.

Change Management: Prefix Filtering als Teil der Change-Validation

Viele Leaks entstehen durch Changes: neue Kunden, neue Sessions, neue Templates, neue Automationspipelines. Deshalb sollten Prefix Filtering und Monitoring-Gates Teil jeder Routing-Änderung sein.

• Vor Change: Baseline (Prefix Counts, Invalid Rate, advertised Counts) sichern.
• Nach Change: checken, ob accepted/advertised Prefix Counts im Erwartungsband bleiben.
• Stop-Kriterium: unerwarteter advertised Spike an Peer/Transit ist ein harter Stop (Leak-Risiko).

Praktische Minimal-Checkliste: Prefix-Filtering-Best-Practices (einsatzbereit)

• Rollenmodell aktiv: Customer/Peer/Transit als Templates, keine „Sonderlocken ohne Dokumentation“.
• Customer Ingress Whitelist: erlaubte Präfixe + erlaubte Prefix-Längen (Deaggregation-Regeln).
• Max-Prefix: Warnschwelle + Hard Limit, getrennt für IPv4/IPv6.
• RPKI Integration: observe-only → depräferieren → invalid droppen, mit Monitoring der Invalid Rate.
• Peer Export strikt: nur eigene + Kundenrouten; keine Transit-Routen.
• Community Governance: dokumentierter Katalog, kein ungeprüftes Weiterreichen externer Steuer-Communities.
• Prefix Count Monitoring: received/accepted/advertised pro Session, Baselines und Abweichungsalarme.
• Churn Monitoring: Update/Withdraw Rate, Top-N neue Präfixe/ASNs automatisch sammeln.
• Change-Validation: nach Routing-Changes advertised Counts und Policy-Diffs prüfen.
• Incident Runbook: klare Mitigation-Schritte (Filter schärfen, Max-Prefix senken, Export begrenzen) in Minuten.

Häufige Fehler in der Praxis und wie Sie sie vermeiden

• „Wir filtern später“: ohne Ingress-Whitelist und Max-Prefix ist ein Customer-Leak nur eine Frage der Zeit.
• Max-Prefix ohne Baseline: zu hohe Limits schützen nicht; zu niedrige erzeugen unnötige Resets.
• RPKI ohne Support-Prozess: Invalid Drops ohne ROA-Workflow erzeugen Kundenausfälle und Ticketstürme.
• Export-Policy Copy/Paste: ein Peer-Template wird wie Transit exportiert → Sie werden zum Transit.
• Monitoring nur „Session up“: Sessions sind oft stabil, während Leaks laufen; Prefix Counts sind entscheidend.

Outbound-Ressourcen

• RFC 4271 (BGP-4)
• RFC 9234 (Route Leak Prevention and Detection Using Roles in BGP)
• RFC 6811 (BGP Prefix Origin Validation)
• RFC 8210 (RPKI-to-Router Protocol, RTR)
• MANRS (Best Practices für Routing-Sicherheit)
• RIPE NCC RPKI (Praxisinformationen und Betrieb)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.