BGP Security am Edge: RPKI, Prefix Filter und Route Leak Mitigation

BGP Security am Edge ist heute ein Pflichtprogramm für jede Organisation, die eigene Präfixe ins Internet annonciert, Multi-Homing betreibt oder als Service Provider Kundenrouting entgegennimmt. Border Gateway Protocol (BGP) ist dabei bewusst „vertrauensbasiert“ entworfen worden: Es prüft nicht automatisch, ob ein Nachbar ein Präfix überhaupt announcen darf oder ob ein AS-Pfad plausibel ist. Genau daraus entstehen reale Risiken wie Route Hijacks, Route Leaks und großflächige Erreichbarkeitsprobleme – oft nicht durch böswillige Angriffe, sondern durch Fehlkonfigurationen. Moderne Maßnahmen wie RPKI (Route Origin Validation), saubere Prefix Filter, AS-PATH- und Next-Hop-Policies, Max-Prefix-Limits sowie Route Leak Mitigation reduzieren dieses Risiko drastisch, wenn sie konsequent und betrieblich sauber umgesetzt werden. Wichtig ist dabei ein ganzheitlicher Blick: BGP Security am Edge ist nicht nur „ein paar Filter“, sondern ein Design aus Governance (wer darf was announcen?), technischen Kontrollen (RPKI, Filter, Limits), Monitoring (Route-Change-Alarmierung) und getesteten Failover-Prozessen. Dieser Artikel zeigt, wie Sie RPKI, Prefix Filter und Route Leak Mitigation praxisnah kombinieren, ohne Ihr Routing unnötig fragil zu machen.

Warum BGP am Edge besonders gefährdet ist

Am Edge treffen Ihre Routing-Domäne und das „Internet als fremdes System“ aufeinander. BGP-Nachbarn sind oft Provider, Transit-Carrier, IX-Peers oder Kunden. Das Risiko entsteht aus zwei Faktoren: Erstens kann Ihr Edge-Router/Firewall-Gerät falsche Routen akzeptieren (Ingress-Risiko). Zweitens kann es falsche Routen weitergeben (Egress-Risiko), etwa durch Redistribution-Fehler, falsche Communities oder versehentlich zu breite Announcements.

• Route Hijack: Ein Präfix wird von einem falschen Ursprung-AS annonciert (Origin Hijack) oder durch Manipulation im Pfad umgeleitet.
• Route Leak: Routen werden in falsche Richtung propagiert, z. B. Kundenrouten werden zum Transit, oder interne Routen gelangen nach außen.
• Misconfiguration: Max-Prefix fehlt, Filter zu breit, Default-Route wird geleakt, oder ein „redistribute all“ schiebt unerwartete Routen ins eBGP.

Die technische Basis von BGP ist in RFC 4271 (BGP-4) beschrieben. Entscheidend ist: BGP selbst validiert keine „Routing-Rechte“ – das müssen Sie als Betreiber am Edge erzwingen.

Threat Model: Welche Angriffe und Fehler Sie realistisch adressieren sollten

Für ein robustes Design ist es hilfreich, zwischen böswilligen und unbeabsichtigten Ereignissen zu unterscheiden. Beide können gleich große Auswirkungen haben.

• Unabsichtlich: Falsche Prefix-Liste, falscher Export, falsches Peering-Template, falsche Redistribution, Tippfehler bei Maskenlänge.
• Böswillig: Hijack durch kompromittiertes AS, gezielte Umleitung, Traffic-Interception, Abgreifen von Daten oder DoS durch blackholing.
• Ökosystem-Risiko: Dritte (Upstream/Peer) leaken Routen; Ihre Kante muss solche Fehler erkennen und abfangen.

Ein praxistaugliches Ziel ist: Die häufigsten und gefährlichsten Fehler sollen automatisch abgefangen werden, und die restlichen Fälle sollen über Monitoring und schnelle Rollback-Prozesse beherrschbar sein.

Grundprinzipien: „Default Deny“ für Routing

Viele Edge-Setups sind historisch gewachsen und arbeiten implizit: „Wenn der Provider es schickt, wird es akzeptiert.“ Für BGP Security am Edge ist das Gegenteil sinnvoll: Default Deny für Routen, erlaubt wird nur das, was explizit erwartet wird.

• Ingress: Von Nachbar X akzeptiere ich nur Prefixes aus Set A, mit erwartbaren Attributen, und begrenze Menge/Masken.
• Egress: Zu Nachbar X annonce ich nur Prefixes aus Set B, niemals interne/privaten Ranges, niemals „zufällig“ redistributierte Routen.
• Separation of Roles: Transit, Peer und Customer werden strikt getrennt behandelt (Templates).

RPKI: Was es löst und was nicht

RPKI (Resource Public Key Infrastructure) adressiert die zentrale Frage: Darf dieses AS dieses Präfix als Ursprung announcen? Das nennt sich Route Origin Validation (ROV). Dazu veröffentlicht der Präfixinhaber sogenannte ROAs (Route Origin Authorizations), die festlegen, welches AS ein Präfix originieren darf und bis zu welcher maximalen Präfixlänge (maxLength). Ihre Edge-Devices oder ein vorgeschalteter Validator prüfen eingehende BGP-Updates gegen diese ROAs und klassifizieren sie typischerweise als Valid, Invalid oder NotFound.

• Valid: Origin-AS und Prefix/MaxLength passen zu einer ROA.
• Invalid: Es existiert eine ROA, aber Origin-AS oder Prefixlänge passen nicht (typischer Hijack-Indikator oder ROA-Fehler).
• NotFound: Keine ROA vorhanden (noch nicht abgedeckt, nicht zwingend böse).

RPKI schützt primär gegen Origin Hijacks, nicht gegen Path-Manipulationen oder Leaks. Trotzdem ist es einer der größten Sicherheitshebel, weil es viele Hijacks zuverlässig markiert. Eine gute Übersicht zu ROV im BGP-Kontext finden Sie in RFC 6811.

RPKI Best Practices am Edge

Die größte Herausforderung bei RPKI ist nicht „ob“, sondern „wie“ Sie es betrieblich stabil einführen. Ein robustes Modell arbeitet mit klaren Policies und einem sicheren Rollout.

• Validator redundant: Betreiben Sie mindestens zwei unabhängige RPKI-Validatoren (oder Services), um SPOF zu vermeiden.
• Policy-Entscheidung klar: Was machen Sie mit Invalid? Üblich: reject oder deprefer. Für NotFound: meist akzeptieren, aber ggf. weniger bevorzugen.
• ROA-Hygiene: Eigene Präfixe korrekt mit maxLength planen, sonst erzeugen Sie selbst „Invalid“-Zustände bei legitimen Announcements.
• Rollout in Stufen: Zuerst nur markieren und loggen (Monitor), dann Invalid de-prefer, erst später Invalid hart verwerfen (Reject), je nach Risikoappetit.
• Alerting: Invalid-Events sind Security-Signale; NotFound-Rate kann ein KPI für RPKI-Abdeckung sein.

Prefix Filter: Der wichtigste Schutz gegen Route Leaks

Prefix Filter sind das Fundament der Route Leak Mitigation. Sie definieren, welche Prefixes Sie von welchem Nachbarn akzeptieren oder zu ihm exportieren. RPKI ersetzt Prefix Filter nicht, weil RPKI nicht prüft, ob ein Nachbar überhaupt Transit spielen darf oder ob er plötzlich die gesamte Welt routet.

Ingress Prefix Filter

• Customer: Akzeptieren Sie nur Prefixes, die der Kunde besitzen darf (Customer Prefix List). Alles andere ist per Default Drop.
• Peer: Akzeptieren Sie nur das, was im Peering-Kontext plausibel ist (oft viele Prefixes, aber mit Max-Prefix/Policy und ggf. IRR/RPKI-gestützt).
• Transit: Akzeptieren Sie die „Full Table“ nur von definierten Transits, mit Max-Prefix und Schutzmechanismen.

Egress Prefix Filter

• Zu Transit: Exportieren Sie nur Ihre eigenen Prefixes und ggf. Kundenprefixes, die Sie bewusst transiten wollen.
• Zu Peer: Exportieren Sie in der Regel nur Ihre eigenen und Kundenprefixes (kein Transit für fremde Upstreams).
• Zu Customer: Exportieren Sie das, was der Kunde braucht (z. B. Default oder Full Table), aber bewusst gesteuert.

Ein starkes, standardisiertes Filter-Design verhindert, dass „ein falscher Redistribute“ plötzlich Internetrouten oder private Netze nach außen leakt.

IRR-basierte Filter und ihre Grenzen

Viele Betreiber nutzen zusätzlich IRR (Internet Routing Registry), um automatisiert Prefix-Listen zu generieren. Das kann operativ helfen, ist aber nicht gleichwertig zu RPKI, weil IRR-Daten historisch uneinheitlich gepflegt werden können. Best Practice ist: IRR als unterstützende Quelle verwenden, aber mit zusätzlichen Checks kombinieren (z. B. RPKI und manuelle Validierung kritischer Kunden).

• Vorteil: Skalierbare Generierung von Kundenfilterlisten.
• Nachteil: Datenqualität variiert; nicht alle Objekte sind gepflegt; Spoofing ist möglich, wenn Registries nicht streng sind.

Route Leak Mitigation: Praktische Kontrollen, die wirklich wirken

Route Leaks entstehen häufig durch fehlende Richtungskontrolle (valley-free routing) oder durch falsche Export-Policies. Die folgenden Maßnahmen haben sich als besonders wirksam erwiesen:

• Role Templates: Separate Konfigurations-Templates für Transit, Peer, Customer, mit Default Deny.
• Max-Prefix Limits: Setzen Sie pro Neighbor eine Obergrenze für akzeptierte Prefix-Anzahl (und definieren Sie Alarm/Action).
• AS-PATH Hygiene: Erwartete AS-PATH-Patterns prüfen (z. B. Kunden sollten nicht plötzlich „viele AS-Hops“ als Transit liefern).
• Default-Route Schutz: Default nur dort akzeptieren/annoncen, wo es designiert ist; niemals „aus Versehen“.
• Communities konsequent: Communities für Export-/Importsteuerung nutzen (no-export, blackhole, prepends), aber strikt validieren, wer welche Community setzen darf.

Als Referenz zum Thema Route Leaks und typischer Gegenmaßnahmen ist RFC 7908 hilfreich, das Route-Leak-Szenarien und Mitigations beschreibt.

AS-PATH Filter und Neighbor Validation

Prefix Filter prüfen „was“ geroutet wird. AS-PATH Filter prüfen „wie“ es gekommen ist. Beide zusammen sind deutlich stärker als eine einzelne Maßnahme.

• Customer-Links: Häufig ist es sinnvoll, sicherzustellen, dass der AS-PATH bei Kundenrouten mit dem Kunden-AS beginnt (oder nur wenige erlaubte AS-Varianten hat).
• Peer/Transit: AS-PATH Filter sind hier schwieriger, aber Sie können auffällige Patterns blocken (z. B. private ASNs, unerwartete AS-Übergänge, zu kurze/zu lange Pfade in bestimmten Kontexten).
• Neighbor AS Check: Stellen Sie sicher, dass der Neighbor wirklich das erwartete Remote-AS ist (keine „wildcards“).

Max-Prefix: Schutz vor „Full Table im falschen Kontext“

Max-Prefix-Limits verhindern nicht jeden Leak, aber sie stoppen viele der schlimmsten Eskalationen: Ein Kunde, der plötzlich eine große Menge Prefixes sendet, oder ein Peer, der versehentlich Transit spielt. Best Practices:

• Grenzen realistisch setzen: Nicht zu niedrig (sonst false positives), aber klar unterhalb eines „Worst Case“.
• Warnschwellen: Viele Plattformen unterstützen Warnung bei z. B. 80–90% der Grenze.
• Action definieren: Nur Alarmieren oder Session automatisch abschalten? Im Enterprise-Kontext ist „shutdown neighbor“ riskant, aber bei Kundenlinks oft sinnvoll, wenn klar kommuniziert.

Blackholing und DDoS: Sicheres Handling am Edge

BGP wird häufig für Blackhole-Routing genutzt (RTBH), um DDoS-Traffic gezielt zu verwerfen. Das ist wirksam, aber nur sicher, wenn Communities und Prefix-Scope streng kontrolliert werden.

• Nur definierte Prefixes: Blackhole-Announcements müssen auf Ihre eigenen Prefixes beschränkt sein.
• Community-Validation: Nur autorisierte Quellen dürfen Blackhole-Communities setzen (z. B. nur DDoS-Controller, nicht jeder Kunde).
• Audit und Expiry: Blackholes sind zeitkritisch; automatisches Entfernen/Timeout und Logging sind Pflicht.

Edge-Firewalls und BGP: Besonderheiten in Security-Umgebungen

Wenn BGP auf Firewalls läuft (statt auf reinen Routern), greifen zusätzliche Aspekte:

• Asymmetry-Risiko: ECMP oder Multi-Exit muss so gebaut sein, dass stateful Flows nicht asymmetrisch laufen.
• NAT-Interaktion: NAT kann Pfade beeinflussen; bei Multi-Homing müssen NAT- und Routing-Policy zusammenpassen.
• Failover-Verhalten: HA-Failover verändert Nachbarschaften. Virtuelle IPs/stabile Identitäten reduzieren Flaps.
• Control Plane Schutz: Routing-Prozesse dürfen nicht durch Logstürme oder DPI-Funktionen beeinträchtigt werden; Management Plane Security ist hier zentral.

Failover und Stability: BFD, Hold-Timer und „zu schnell“

Schnelles Failover klingt immer gut, kann aber bei instabilen Pfaden zu Flapping führen. BFD kann BGP/OSPF schneller informieren, muss aber zu Ihrer Netzwerkqualität passen.

• BFD sinnvoll bei: stabilen, gut gemessenen Pfaden, wo schnelle Konvergenz geschäftlich relevant ist.
• BFD riskant bei: Pfaden mit Jitter/Loss (z. B. Internet-Uplinks ohne QoS), weil kurze BFD-Intervalle falsche Down-Events erzeugen.
• Best Practice: Erst messen, dann aggressiver tunen; Flap-Dämpfung und Monitoring ergänzen.

Für BFD-Hintergrund ist RFC 5880 eine gute Einstiegsklasse.

Monitoring und Detection: Route-Change-Observability als Sicherheitskontrolle

BGP Security am Edge ist nicht nur Prävention, sondern auch Erkennung. Selbst mit RPKI und Filtern können problematische Routen durchkommen (z. B. NotFound, oder legale, aber schädliche Leaks). Ein robustes Monitoring umfasst:

• RPKI Status Events: Invalid/NotFound Trends, plötzliche Sprünge bei Invalids.
• Prefix-Count Anomalien: Nachbar sendet plötzlich deutlich mehr/weniger Prefixes.
• Best-Path Changes: Ungewöhnliche Umschaltungen, neue Upstreams, neue AS-PATHs.
• Latency/Reachability: Technische Indikatoren, dass Traffic umgeleitet wird (z. B. RTT-Sprünge zu kritischen SaaS/Partnern).
• Logpipeline Health: Drops/Lag/Parser-Fehler, weil Routing-Events sonst nicht zuverlässig auswertbar sind.

Governance: Dokumentation und Rezertifizierung der Edge-Policies

Ein häufiger Grund für Route Leaks ist „Policy Drift“: Filterlisten, Communities und Templates werden über Jahre ergänzt, ohne regelmäßig überprüft zu werden. Best Practices:

• Owner pro Neighbor: Wer ist verantwortlich für Transit/Peer/Customer X?
• Policy-as-Code: BGP-Policies, Prefix-Listen und Communities versionieren, reviewen und testen.
• Rezertifizierung: Kundenprefixlisten, Exportregeln und Max-Prefix-Limits regelmäßig prüfen.
• Change-Prozess: Jede Änderung an Edge-Routing bekommt Ticket-ID, Testnachweis und Rollback-Plan.

Für auditierbare Prozessanforderungen kann ISO/IEC 27001 als Rahmen dienen, während die CIS Controls praxistaugliche Mindestkontrollen zu Konfigurationsmanagement und Monitoring liefern.

Praktische Umsetzung: Ein solides Edge-BGP Security Blueprint

• 1) Rollenmodell definieren: Transit, Peer, Customer strikt trennen; Templates nutzen.
• 2) Prefix Filter „default deny“: Ingress und Egress strikt filtern; keine „accept all“-Nachbarn.
• 3) RPKI/ROV einführen: Validator redundant; Invalid zunächst monitoren, dann de-prefer, später verwerfen (je nach Risikoappetit).
• 4) Max-Prefix und Schutzlimits: Pro Neighbor Grenzen und Warnschwellen, inklusive klarer Aktionen.
• 5) Communities kontrollieren: Nur erlaubte Communities akzeptieren; Blackhole- und TE-Communities schützen.
• 6) Route Leak Mitigation aktiv: Export-Policies strikt; Redistribution minimieren; Default-Route nur bewusst.
• 7) Monitoring/Alerting: Prefix-Count, Best-Path-Changes, RPKI-Invalids, Flaps, BFD-Events korrelieren.
• 8) Regelmäßige Reviews: Prefixlisten, ROAs, Max-Prefix, Templates rezertifizieren; Drift abbauen.

Outbound-Quellen für Standards und Vertiefung

• RFC 4271 (BGP-4) als Protokollgrundlage für BGP.
• RFC 6811 (Route Origin Validation) für RPKI-basierte Origin-Validierung.
• RFC 7908 (Route Leak Mitigation) für Route-Leak-Szenarien und Gegenmaßnahmen.
• RFC 5880 (BFD) für schnelle Failure Detection als Baustein für Failover.
• CIS Controls für praxistaugliche Kontrollen zu Konfigurationsmanagement, Monitoring und Change-Prozessen.

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.