Site icon bintorosoft.com

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

Cloud computing network diagram with various connections illustration

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.

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.

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.

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.

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.

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

Egress Prefix Filter

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).

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:

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.

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:

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.

Edge-Firewalls und BGP: Besonderheiten in Security-Umgebungen

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

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.

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:

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:

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

Outbound-Quellen für Standards und Vertiefung

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:

Lieferumfang:

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.

 

Exit mobile version