BGP Security Design: RPKI, Prefix Filter, Max-Prefix und Route Leaks

BGP Security Design: RPKI, Prefix Filter, Max-Prefix und Route Leaks ist heute ein Muss für jedes Unternehmen, jeden ISP und jede Plattform, die eigene IP-Präfixe annonciert oder über BGP an Provider, Exchanges oder Cloud-Hubs angebunden ist. Border Gateway Protocol (BGP) ist das Rückgrat des Internets, aber historisch nicht mit „Security by default“ gebaut: Ohne zusätzliche Kontrollen kann ein falsch konfigurierter oder kompromittierter Peer versehentlich (oder absichtlich) Präfixe ankündigen, die ihm nicht gehören, zu viele Routen senden oder Traffic über unerwünschte Pfade umleiten. Die Folgen reichen von kurzen Ausfällen bis zu großflächigen Umleitungen (Hijacks), Blackholing, Performance-Degradation und schwer nachvollziehbaren Incident-Ketten. Ein robustes BGP-Sicherheitsdesign kombiniert deshalb mehrere Schutzschichten: RPKI-basierte Origin Validation als kryptografischen Anker, konsequente Prefix- und AS-Filter als erste Verteidigungslinie, Max-Prefix-Limits als Airbag gegen „Route Leaks“ und klare Betriebs-Playbooks, die verhindern, dass im Ernstfall hektische Änderungen das Problem verschlimmern. Dieser Beitrag zeigt, wie Sie RPKI, Prefix Filtering, Max-Prefix und Leak-Prevention in eine wartbare Architektur überführen, die auch bei Wachstum, Multi-Homing und Cloud-Interconnects stabil bleibt.

Warum BGP-Sicherheit heute geschäftskritisch ist

Viele Organisationen betrachten BGP als „Provider-Thema“. Spätestens bei Multi-Homing, Anycast, DDoS-Mitigation, Cloud-Direct-Connect/ExpressRoute, SD-WAN-Hubs oder eigenen IP-Adressräumen wird BGP jedoch zur eigenen Verantwortung. Angriffs- und Fehlerbilder sind dabei nicht exotisch, sondern alltäglich:

• Route Leaks: Ein Peer leakt Routen aus einem Transit/Upstream in Richtung eines anderen Peers und wird unbeabsichtigt zum Transit.
• Prefix Hijacks: Ein AS annonciert ein Präfix, das ihm nicht gehört, und zieht Traffic an (absichtlich oder durch Fehlkonfiguration).
• Deaggregation: Zu spezifische Präfixe werden annonciert und verdrängen legitime, aggregierte Routen (Traffic wird umgelenkt).
• Routing Table Floods: Ein Peer sendet extrem viele Routen; Geräte laufen in CPU/RAM-Probleme oder Max-Prefix-Trigger.
• Policy-Fehler: Local Preference, Communities oder Export-Policies führen zu unerwünschten Pfaden und Performance-Einbrüchen.

BGP Security Design bedeutet deshalb: Nicht nur „Angriffe verhindern“, sondern auch Fehlkonfigurationen abfangen, bevor sie zu großflächigen Incidents werden.

Grundlagen: Was BGP absichert und was nicht

BGP tauscht Reachability-Informationen zwischen autonomen Systemen (AS) aus. Es entscheidet anhand von Attributen, welcher Pfad „besser“ ist. BGP selbst prüft jedoch nicht, ob ein AS ein Präfix wirklich announcen darf. Genau hier setzen zusätzliche Kontrollen an. Eine gute konzeptionelle Basis liefert die Einführung in BGP in RFC 4271 (Border Gateway Protocol 4).

Für Sicherheitsdesign ist wichtig, drei Ebenen auseinanderzuhalten:

• Origin: Darf dieses AS dieses Präfix als Ursprung announcen?
• Path: Ist der AS-Pfad plausibel, oder deutet er auf Leaks/Manipulation hin?
• Policy: Werden Routen nur so importiert/exportiert, wie es dem Geschäftsmodell entspricht?

RPKI adressiert primär die Origin-Frage. Prefix Filter und Max-Prefix adressieren Import/Export und Stabilität. Route-Leak-Prevention ist eine Kombination aus korrekten Policies, Communities und Monitoring.

RPKI: Kryptografische Basis für Origin Validation

RPKI (Resource Public Key Infrastructure) ermöglicht es Präfixinhabern, kryptografisch zu veröffentlichen, welche ASNs bestimmte IP-Präfixe announcen dürfen. Diese Informationen werden als ROAs (Route Origin Authorizations) veröffentlicht. Router oder Validatoren können damit BGP-Routen als „valid“, „invalid“ oder „not found“ klassifizieren. Eine zentrale Spezifikation ist RFC 6482 (Route Origin Authorization).

Wie RPKI in der Praxis wirkt

• Schutz gegen viele Hijacks: Wenn ein fremdes AS Ihr Präfix annoncieren will, kann die Route als „invalid“ erkannt werden.
• Mehr Vertrauen bei Peers: Viele Provider bevorzugen zunehmend RPKI-validierte Ankündigungen oder droppen „invalid“.
• Fehlerprävention: Auch eigene Fehlkonfigurationen (falsches Origin-AS) werden schneller sichtbar.

Wichtig ist jedoch: RPKI ist kein vollständiger Schutz gegen alle Leak-Szenarien, weil es nicht den gesamten Pfad kryptografisch absichert, sondern primär den Origin.

ROA-Design: MaxLength, Aggregation und Betriebsrisiko

ROAs enthalten neben Präfix und Origin-AS typischerweise auch einen MaxLength-Wert, der festlegt, wie spezifisch Subpräfixe sein dürfen, um noch „valid“ zu sein. Hier entstehen häufig Fehler:

• Zu restriktiv: MaxLength = /24, aber Sie announcen auch /25 (oder in IPv6 /48 vs. /56). Ergebnis: Ihre eigenen Ankündigungen werden „invalid“.
• Zu großzügig: MaxLength zu groß erlaubt potenziell zu viele spezifische Ankündigungen (kann im Missbrauchsfall schaden).
• Aggregation nicht bedacht: Sie wollen eigentlich nur ein /22 announcen, erzeugen aber ROAs, die ungewollte Deaggregation „legitimieren“.

Ein praxistauglicher Ansatz ist, ROAs eng am realen Announcement-Plan zu halten: Aggregation als Standard, Deaggregation nur, wenn sie fachlich erforderlich ist (z. B. Traffic Engineering, DDoS-Mitigation, Anycast-Design).

RPKI-Betrieb: Validator, Cache und Routing-Policy

RPKI-Validierung wird häufig über einen RPKI-Validator (Relying Party) betrieben, der ROAs aus den RIR-Trust-Ankern zieht und als Validierungsdaten bereitstellt. Router beziehen diese Daten (je nach Hersteller/Plattform) und setzen Import-Policies um. Kernelemente:

• Redundante Validatoren: Mindestens zwei, damit Validierung nicht zum Single Point of Failure wird.
• Klare Policy: „invalid“ droppen oder stark depriorisieren; „not found“ zunächst akzeptieren, aber beobachten.
• Monitoring: Alarm bei Sprüngen in invalid/not-found-Anteilen, insbesondere für eigene Präfixe.

Prefix Filter: Die wichtigste, simplest wirkende Schutzschicht

Prefix Filtering bedeutet, dass Sie an jedem BGP-Peering festlegen, welche Präfixe Sie von einem Peer akzeptieren (Inbound) und welche Sie an ihn exportieren (Outbound). Das klingt banal, ist aber eine der wirksamsten Maßnahmen gegen Route Leaks und Fehlkonfigurationen. Ohne Prefix Filter vertrauen Sie darauf, dass der Peer immer „das Richtige“ sendet.

Inbound Prefix Filter: Was Sie vom Peer annehmen

Die ideale Regel lautet: Sie akzeptieren vom Peer nur Präfixe, die zu seiner Rolle passen. Beispiele:

• Kunde (Customer): Akzeptieren nur die Kundenpräfixe (plus ggf. wenige definierte Spezialfälle). Niemals „Full Table“ vom Kunden, außer er ist ausdrücklich Transit-Kunde.
• Peer (IX/PNI): Akzeptieren nur die Peering-Routen (kein Transit), typischerweise begrenzt auf dessen announced Prefix-Set.
• Upstream/Transit: Akzeptieren Full Table oder definierte „Default + Selected Routes“, aber mit Max-Prefix-Schutz.

Praktisch wird das häufig über Prefix-Sets aus IRR (Internet Routing Registry) und/oder über automatisierte Listen (z. B. aus PeeringDB-Daten) unterstützt. Für das Verständnis von IRR-Objekten und operationalen Policies kann RIPE Database (IRR/Registry-Kontext) als Ausgangspunkt dienen.

Outbound Prefix Filter: Was Sie exportieren

Outbound Filtering ist genauso wichtig, weil viele Leaks dadurch entstehen, dass ein Router „zu viel“ exportiert. Best Practices:

• Default deny outbound: Standardmäßig wird nichts exportiert, außer explizit erlaubt.
• Nur eigene Präfixe: Zu Peers und Kunden exportieren Sie nur die Routen, die sie erhalten sollen (kein ungewollter Transit).
• Communities als Steuerung: Wenn Sie mehrere Export-Optionen haben (z. B. blackhole community, no-export), sollten diese dokumentiert und kontrolliert sein.

Ein häufiger Fehler ist, dass ein Peer versehentlich Full Table erhält und dann als Transit genutzt wird. Outbound Filter verhindern das zuverlässig.

Max-Prefix: Der Airbag gegen Routing-Floods und Leaks

Max-Prefix-Limits begrenzen, wie viele Routen Sie von einem Peer akzeptieren. Wenn der Peer plötzlich viel mehr sendet (z. B. durch Leak oder Fehlkonfiguration), kann Ihre Session automatisch gedrosselt oder beendet werden. Das ist ein wichtiges Schutzmittel gegen Kontrollplane-Überlast und gegen „Route Leaks“, die sich als plötzlicher Routenanstieg zeigen.

Wie Sie sinnvolle Max-Prefix-Werte wählen

• Baseline messen: Wie viele Präfixe kommen im Normalbetrieb von diesem Peer?
• Puffer einplanen: Ein Sicherheitsfaktor (z. B. +10–30 %) verhindert unnötige Flaps bei normalem Wachstum.
• Rolle berücksichtigen: Upstreams können sehr viele Routen liefern (Full Table), Kunden und Peers typischerweise deutlich weniger.
• Warnschwellen nutzen: Viele Plattformen erlauben Warning-Thresholds unterhalb des harten Limits.

Max-Prefix ist kein Ersatz für Prefix Filter. Ein Leak kann auch „wenige“ Routen beinhalten, aber hochkritische Präfixe betreffen. Trotzdem ist Max-Prefix ein sehr wirksamer Schutz gegen großflächige Fehler.

Fail-Safe-Design: Was passiert, wenn Max-Prefix triggert?

Wenn die BGP-Session wegen Max-Prefix down geht, kann das selbst Impact erzeugen. Daher sollte Ihr Design Folgendes festlegen:

• Fallback-Pfade: Redundanter Upstream, alternative Peerings, ggf. Default Route als Notbetrieb.
• Automatisierte Alarmierung: Max-Prefix-Events sind Incident-relevant und müssen sofort sichtbar sein.
• Runbook: Klare Schritte: Peer kontaktieren, Filter prüfen, temporäre Mitigation, sichere Wiederherstellung.

Route Leaks: Typen, Ursachen und Abwehrmuster

Ein Route Leak ist meist kein klassischer „Hack“, sondern eine Policy-Verletzung: Routen werden in eine Richtung exportiert, in die sie nicht gehören. Das kann ganze Verkehrsflüsse umleiten oder Netze zu ungewollten Transits machen.

Häufige Leak-Szenarien

• Customer-Leak: Ein Kunde exportiert Full Table an Sie, und Sie leaken diese weiter zu Peers.
• Peer-to-Peer-Transit: Sie geben Peers gegenseitig Transit, weil Outbound Filter fehlen.
• Default Route Leak: Eine unerwünschte Default Route verbreitet sich in Bereiche, die sie nicht bekommen sollen.
• Deaggregation Leak: Zu spezifische Präfixe werden großflächig verteilt und ziehen Traffic an.

Policy Patterns gegen Leaks

• Rollenbasierte Export-Policy: Customer bekommt Transit, Peer bekommt kein Transit, Upstream bekommt eigene Präfixe plus ggf. kundenseitig definierte Ankündigungen.
• Communities zur Steuerung: z. B. „no-export“, „no-advertise“, „blackhole“ (mit strikter Governance).
• Prefix-Listen und AS-Path-Filter: Nur erlaubte Prefix-Sets und erwartete AS-Pfade akzeptieren.
• RPKI-OV: „invalid“ nicht weiterpropagieren; reduziert bestimmte Hijack-/Leak-Effekte.

Als praktischer Leitfaden, wie Leaks operational eingeordnet und mitigiert werden, ist der Ansatz der Mutually Agreed Norms for Routing Security (MANRS) verbreitet: MANRS Routing Security Initiative.

AS-Path, Communities und Route Policy: Sicherheit durch klare Domänengrenzen

Viele Sicherheits- und Stabilitätsprobleme entstehen durch unklare Routing-Domänengrenzen. BGP bietet Mechanismen, um Domänen sauber zu trennen:

• AS-Path-Filter: Für Kunden kann erwartet werden, dass ihr AS im Pfad erscheint; für bestimmte Peerings können Pfad-Constraints helfen.
• Local Preference: Steuert Pfadwahl intern; sollte konsistent sein, um unerwartete Traffic-Shifts zu vermeiden.
• Communities: Einheitlich dokumentieren, wer welche Communities setzen darf und welche Wirkung sie haben.
• Route Maps/Policies: Klar getrennte Blöcke für Import, Export, DDoS-Blackholing, TE-Ausnahmen.

Ein häufiger Betriebsvorteil ist, Policies wie Code zu behandeln: Versionierung, Reviews, Tests und Rollbacks. So werden Leak-Risiken deutlich reduziert.

Blackholing und DDoS: BGP-Sicherheit trifft Availability

BGP Security Design überschneidet sich oft mit DDoS-Strategien. Blackhole-Communities oder RTBH können nötig sein, um volumetrische Angriffe schnell zu stoppen. Damit das nicht selbst zum Risiko wird, brauchen Sie strikte Kontrolle:

• Nur autorisierte Systeme: Nur definierte Router oder Automationssysteme dürfen Blackhole-Communities setzen.
• Begrenzte Prefix-Längen: Blackholing nur für zulässige Präfixe, idealerweise spezifisch genug, um Kollateralschäden zu minimieren.
• Timeouts und Rezertifizierung: Temporäre Blackholes müssen automatisch auslaufen oder aktiv bestätigt werden.
• Monitoring: Sichtbarkeit, welche Präfixe aktuell geblackholed sind und warum.

Observability: BGP-Sicherheit braucht Messbarkeit und schnelle Korrelation

Ohne Sichtbarkeit bleibt BGP-Security ein „Hope-Model“. Ein guter Blueprint definiert, welche Signale Sie kontinuierlich überwachen:

• Session Health: BGP Up/Down, Flaps, Hold Timer Events, Graceful Restart Verhalten.
• Prefix Counts: pro Peer (Basis für Max-Prefix und Leak-Erkennung).
• RPKI-Status: Anteil valid/invalid/not-found, besonders für eigene Präfixe.
• Route Change Rate: ungewöhnliche Update-Spikes, die auf Leaks oder Instabilität hinweisen.
• Traffic Shifts: plötzliche Änderungen in Ingress/Egress-Volumen je Peer/Region.

Praktisch sollten Sie Alerts nicht nur auf „Session down“ setzen, sondern auf Impact-nahe Indikatoren wie „Prefix Count verdoppelt“ oder „RPKI invalid für eigenes Präfix“. Das verkürzt Time-to-Detect erheblich.

Operating Model: Prozesse, Reviews und sichere Changes

BGP-Sicherheit ist so sehr Prozess wie Technik. Ein wirksames Operating Model umfasst:

• Peer Onboarding: Standard-Checkliste (Prefix-Set, RPKI-Policy, Max-Prefix, Communities, Contact Paths).
• Change Governance: Route Policies versioniert, reviewed, getestet; klare Rollback-Schritte.
• Rezertifizierung: Regelmäßige Reviews von Prefix-Listen, IRR/RPKI-Daten, Max-Prefix-Werten und Community-Policies.
• Incident Playbooks: Route Leak, Hijack-Verdacht, RPKI-Invalid-Spike, Max-Prefix-Trigger.

Besonders bei RPKI gilt: Änderungen an ROAs sind produktionskritisch. Ein falsches MaxLength oder falsches Origin-AS kann dazu führen, dass eigene Routen global als „invalid“ gelten. Daher sollten ROA-Änderungen wie Production Changes behandelt werden.

Typische Anti-Patterns im BGP Security Design

• Keine Prefix Filter: Vertrauen auf „wird schon passen“. Lösung: Inbound/Outbound Default deny mit expliziten Prefix-Sets.
• RPKI ohne Policy: Validator läuft, aber „invalid“ wird nicht behandelt. Lösung: klare Import-Policy (drop/deprio) und Monitoring.
• Max-Prefix ohne Puffer: Normales Wachstum löst Session-Drops aus. Lösung: Baseline + Puffer + Warnschwellen.
• Communities ohne Governance: Jeder setzt alles, Wirkungen sind unklar. Lösung: dokumentierte Community-Policy, Rollen, Validierung.
• Kein Peer-Runbook: Im Incident wird improvisiert. Lösung: Playbooks, Kontaktlisten, schnelle Mitigation-Schritte.
• IRR/RPKI nicht gepflegt: Daten sind veraltet, Filter werden falsch. Lösung: regelmäßige Rezertifizierung und Automatisierung.

Praxis-Checkliste: BGP Security Design mit RPKI, Prefix Filtern und Leak-Schutz

• Aktivieren Sie RPKI Origin Validation: redundante Validatoren, klare Policy für valid/invalid/not-found und sauberes Monitoring.
• Implementieren Sie strikte Inbound/Outbound Prefix Filter pro Peer-Rolle (Customer/Peer/Upstream) mit Default deny.
• Setzen Sie Max-Prefix-Limits mit Warnschwellen, basierend auf gemessenen Baselines und realistischem Wachstumspuffer.
• Schützen Sie gegen Route Leaks: rollenbasierte Export-Policies, saubere Communities, AS-Path-Checks, keine ungewollten Transits.
• Planen Sie Blackholing/DDoS-Mechanismen mit Governance: autorisierte Quellen, Prefix-Listen, Timeouts, Observability.
• Verankern Sie Observability: Prefix-Counts, Update-Raten, RPKI-Status, Session-Health, Traffic-Shifts pro Peer.
• Führen Sie ein Operating Model ein: Peer-Onboarding-Standards, Policy-as-Code, regelmäßige Rezertifizierung, Incident-Playbooks.
• Nutzen Sie etablierte Best-Practice-Programme als Leitlinie (z. B. MANRS) und dokumentieren Sie Ihre lokalen Regeln als wiederverwendbare Muster.

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.