BGP Security Baseline: RPKI, Prefix Filters, Max-Prefix und Route Leak Schutz

Eine BGP Security Baseline beschreibt den verbindlichen Mindeststandard, mit dem Provider und Netzbetreiber Border Gateway Protocol (BGP) gegen Fehlkonfigurationen, Hijacks und Route Leaks absichern. BGP ist das „Navigationssystem“ des Internets: Es entscheidet, welche Präfixe über welche Nachbarn erreichbar sind. Genau deshalb können kleine Fehler große Auswirkungen haben – von regionalen Störungen bis zu globalen Blackholes oder Traffic-Umleitungen. Eine professionelle Baseline kombiniert mehrere Schutzschichten: RPKI zur kryptografischen Validierung von Origin-Informationen, Prefix Filters und strikte Import-/Export-Policies zur Begrenzung des erlaubten Routings, Max-Prefix als Schutz gegen „Route Flooding“ und versehentliche Full-Table-Leaks sowie zusätzliche Mechanismen gegen Route Leaks und Fehlpropagationen. Für Telcos ist das besonders relevant, weil sie oft viele Peerings, Kundenbeziehungen, Transitpfade und regionale Edges betreiben. Eine BGP Security Baseline hilft, Prioritäten richtig zu setzen: Sie reduziert das Risiko von Ausfällen, schützt die eigene Reputation bei Peers und Upstreams und macht Routing-Änderungen auditierbar und wiederholbar.

Warum BGP ohne Baseline ein operatives und sicherheitliches Risiko ist

BGP wurde historisch für ein kooperatives Internet entwickelt. Sicherheitsmechanismen waren lange kein Kernbestandteil. In der Praxis führt das zu zwei Hauptproblemklassen: absichtlicher Missbrauch (z. B. Prefix Hijacking, Man-in-the-Middle über Umrouting) und unabsichtliche Fehlkonfiguration (z. B. Route Leaks, falsche Export-Policies, versehentlich announced Full Tables). In beiden Fällen ist der Schaden oft identisch: Traffic läuft falsch, Dienste fallen aus, Kunden melden Störungen und das NOC muss unter Druck reagieren.

Eine Baseline wirkt wie ein Sicherheitsgurt: Sie verhindert nicht jede Störung, aber sie reduziert Eintrittswahrscheinlichkeit und Auswirkungen deutlich. Besonders wichtig ist dabei der mehrschichtige Ansatz: RPKI allein reicht nicht, genauso wenig wie reine Prefix-Filter. Erst die Kombination aus kryptografischer Validierung, strikten Policies und „Guard Rails“ wie Max-Prefix und Leak-Schutz ergibt ein robustes Gesamtbild.

Baseline-Grundprinzipien: Default Deny für Routing

Eine gute BGP Security Baseline folgt einem einfachen Leitmotiv: Nur explizit erlaubte Routen werden akzeptiert und propagiert. Das ist im Routing-Kontext das Pendant zu „Default Deny“ bei Firewalls. Praktisch bedeutet das:

• Import-Policies nehmen nur erlaubte Präfixe und akzeptierte Attribute an.
• Export-Policies announcen nur das, was die Beziehung zulässt (Customer, Peer, Transit).
• Validierung (RPKI, Filter, Limits) wird automatisiert und kontinuierlich überwacht.
• Fail-Safe Mechanismen (Max-Prefix, Dampening/Guard Policies) begrenzen den Blast Radius.
• Observability macht Abweichungen schnell sichtbar (Alerts, Dashboards, Route Analytics).

Damit diese Prinzipien im Alltag funktionieren, muss die Baseline außerdem betriebsnah sein: standardisierte Templates, klar definierte Ownership und kontrollierte Changes sind essenziell.

RPKI: Kryptografische Origin-Validierung als Baseline-Baustein

RPKI (Resource Public Key Infrastructure) ermöglicht es, BGP-Origin-Angaben kryptografisch zu validieren. Vereinfacht: Über sogenannte ROAs (Route Origin Authorizations) wird festgelegt, welcher AS ein Präfix announcen darf und bis zu welcher Prefix-Länge. Router können dann eingehende BGP-Ankündigungen als valid, invalid oder unknown/not found klassifizieren.

Was RPKI in der Baseline leisten kann

• Hijack-Reduktion: viele einfache Origin-Hijacks werden als „invalid“ erkennbar.
• Fehlkonfigurationen sichtbar machen: falsche Origin-AS oder zu lange Prefixes werden auffällig.
• Automatisierbare Policy: Valid/Invalid-Handling kann klar standardisiert werden.

RPKI-Policy-Design: Valid, Invalid, Unknown

Eine praxisnahe Baseline definiert explizit, wie mit den drei Zuständen umgegangen wird:

• Valid: akzeptieren (normaler Policy-Pfad).
• Invalid: in der Regel verwerfen oder stark depriorisieren; im Provider-Umfeld ist „drop invalid“ häufig der Zielzustand.
• Unknown: akzeptieren, aber wie „nicht verifiziert“ behandeln (z. B. Monitoring, ggf. geringere Preference).

Wichtig ist die Betriebsrealität: Nicht alle Präfixe sind heute mit ROAs abgedeckt. Eine Baseline sollte deshalb einen realistischen Migrationspfad enthalten: zuerst beobachten und reporten, dann schrittweise „invalid“ härter behandeln, insbesondere an kritischen Edge- und Transit-Punkten.

Prefix Filters: Die wichtigste Schutzschicht für Customer- und Peer-Sessions

Prefix Filters sind eine der effektivsten und zugleich einfachsten Maßnahmen gegen Route Leaks und Hijacks. Sie legen fest, welche Präfixe von einem Nachbarn akzeptiert werden dürfen. Im Idealfall sind Prefix Filters „positiv“ (Allow-List), nicht „negativ“ (Block-List). Für Provider ist das besonders wichtig in zwei Fällen: bei Kunden (Customers) und bei Peerings, weil hier Fehlkonfigurationen oft direkt nach außen wirken.

Filterstrategie nach Beziehungstyp

• Customer: nur die Präfixe akzeptieren, die dem Kunden gehören (oder explizit vertraglich vereinbart sind). Keine Full Table vom Kunden.
• Peer: nur Routen akzeptieren, die der Peer selbst oder seine Kunden announcen dürfen – abhängig vom Peering-Modell. Oft werden zusätzlich Route-Server-Policies genutzt.
• Transit/Upstream: hier ist der Scope größer (teilweise Full Table). Trotzdem bleiben Guard Rails wichtig (Max-Prefix, RPKI, Leak-Schutz).

Bei Customer-Prefix-Filtern ist die Datenquelle entscheidend: IPAM, Provisioning oder Vertragsdaten sollten die Allow-List speisen. Eine Baseline, die hier auf manuelle Listen setzt, wird langfristig inkonsistent. Deshalb ist Automatisierung ein Kernbestandteil.

Max-Prefix: Schutz vor Route Flooding und „Full Table vom Kunden“

Max-Prefix begrenzt, wie viele Routen ein BGP-Nachbar maximal senden darf, bevor Schutzmaßnahmen greifen (z. B. Warnung oder Session-Shutdown). In der Praxis verhindert Max-Prefix viele Großstörungen, etwa wenn ein Kunde versehentlich eine Full Table exportiert oder wenn ein Router durch Fehler plötzlich massenhaft Routen generiert.

Baseline-Regeln für Max-Prefix

• Customer Sessions: strikte Limits, basierend auf erwarteter Präfixanzahl plus Reserve.
• Peer Sessions: Limits abhängig von Peering-Typ (z. B. Teilmengen, regionales Peering, Full Table via RS).
• Upstream Sessions: Limits nahe der erwarteten Full Table plus Reserve, um echte Wachstumstrends nicht als Fehler zu behandeln.
• Warnschwelle: ein Frühwarnwert unterhalb des harten Limits, damit NOC reagieren kann.

Wichtig ist die Balance: Ein zu niedriges Max-Prefix erzeugt unnötige Session-Resets und Betriebslärm. Ein zu hohes Limit schützt nicht. Eine gute Baseline verlangt deshalb eine dokumentierte Erwartungszahl und regelmäßige Überprüfung (z. B. monatlich oder quartalsweise).

Route Leak Schutz: Das häufigste BGP-Problem im Betrieb

Ein Route Leak ist vereinfacht die falsche Weitergabe von Routen: Ein Netz akzeptiert Routen aus einer Beziehung und exportiert sie fälschlicherweise in eine andere, wo sie nicht hingehören. Typische Beispiele sind: ein Kunde exportiert Transit-Routen an einen Peer, ein Peer exportiert Full Table an einen anderen Peer, oder ein internes Segment leakt interne Routen ins öffentliche Routing. Route Leaks sind oft nicht böswillig, aber extrem störend.

Baseline-Mechanismen gegen Route Leaks

• Strikte Export-Policies: klare „Customer/Peer/Transit“-Templates, die standardmäßig korrekt filtern.
• Communities: standardisierte BGP-Communities zur Steuerung, was propagiert wird (z. B. no-export, no-advertise, lokale Communities).
• AS-PATH-Checks: Plausibilitätsregeln, z. B. kein eigenes AS in unerwarteten Pfaden, begrenzte AS-PATH-Länge je nach Beziehung.
• Peer-Lock/AS-List: bei kritischen Sessions nur erwartete Origin-AS oder erwartete AS-PATH-Muster zulassen.
• Route-Server-Policy-Kontrollen: am IX/RS nur definierte Exports zulassen, insbesondere bei großen Peering-Fabrics.

Ein besonders wirksamer Baseline-Ansatz ist „Policy by Relationship“: Jede BGP-Session wird eindeutig klassifiziert (Customer/Peer/Transit), und daraus ergeben sich automatisch Import- und Export-Templates. Das reduziert manuelle Sonderfälle und verhindert, dass ein Engineer im Stress eine falsche Richtung exportiert.

Routen-Validierung und Hygiene: Prefix-Längen, Bogons und Martians

Eine BGP Security Baseline sollte neben RPKI und Prefix Filtern auch grundlegende Routenhygiene abdecken. Dazu gehören Filter gegen offensichtlich falsche oder unerwünschte Präfixe sowie Regeln für akzeptierte Prefix-Längen.

Typische Hygiene-Regeln in Provider-Baselines

• Prefix-Length Filtering: keine zu spezifischen Präfixe akzeptieren (z. B. extrem kleine Netze), je nach Policy und IPv4/IPv6 separat.
• Bogon Filtering: nicht öffentlich routbare Bereiche und reservierte Netze nicht aus externen Sessions akzeptieren.
• Martian Filtering: eindeutig ungültige Quellen/Präfixe blockieren (z. B. unroutebare, interne Sonderbereiche).
• Next-Hop Plausibility: Next-Hop nur in erlaubten Bereichen, um Missbrauch über unerwartete Next-Hops zu reduzieren.

Wichtig ist, dass Hygiene-Regeln konsistent und zentral gepflegt werden. Inkonsistente Bogon-Listen führen zu schwer erklärbaren Reachability-Problemen. Eine Baseline sollte daher definieren, wie Listen aktualisiert und ausgerollt werden (Templates, Versionierung, Rezertifizierung).

Operational Baseline: Monitoring, Alerting und Route Analytics

Routing-Sicherheit ist nicht nur Prävention, sondern auch Erkennung. Selbst mit starken Policies können externe Ereignisse (Hijacks, globale Leaks) auftreten. Eine BGP Security Baseline sollte deshalb Observability als Pflicht definieren. Ziel ist, ungewöhnliche Routenänderungen früh zu erkennen und den Impact schnell zu begrenzen.

Was überwacht werden sollte

• BGP Session Health: Flaps, Reset-Gründe, Hold-Timer-Events, keepalive stability.
• Prefix-Anzahl: Trends, Ausreißer, Max-Prefix-Warnungen und harte Überschreitungen.
• RPKI-Status: Anteil valid/invalid/unknown, neue invalid Events, Top-Talker nach invalid.
• Route Leak Indikatoren: plötzlich neue Pfade, ungewöhnliche AS-PATH-Muster, massive Policy-Diffs.
• Customer/Peer Anomalien: neue Origins, neue Prefixes außerhalb des erwarteten Scopes.

Für Telcos ist außerdem wichtig, Alerts so zu gestalten, dass sie handlungsfähig sind: Ein Max-Prefix-Warnwert muss in einem Ticket landen, RPKI-invalid Peaks müssen korreliert werden, und Policy-Diffs sollten nachvollziehbar sein (z. B. „welche neuen Präfixe sind hinzugekommen?“).

Baseline-as-Code: Policies versionieren und in CI/CD validieren

Gerade im Provider-Umfeld mit vielen Routern, Sessions und Regionen ist manuelle Policy-Pflege ein Risikofaktor. Moderne BGP Security Baselines werden deshalb zunehmend als Code verwaltet: Prefix-Listen, Communities, Relationship-Templates und RPKI-Policies sind versioniert, reviewbar und automatisiert testbar.

Was in CI/CD sinnvoll geprüft wird

• Prefix-Listen Vollständigkeit: Kundenpräfixe vorhanden, keine „Any“-Freigaben in Customer-Policies.
• Max-Prefix Werte: plausibel im Verhältnis zur erwarteten Anzahl, Warn- und Hardlimits definiert.
• Export-Policy-Konsistenz: Customer/Peer/Transit-Templates korrekt, keine ungewollten Transits.
• RPKI-Handling: invalid wird gemäß Baseline behandelt, unknown wird nachvollziehbar gehandhabt.
• Diff-Impact: welche Präfixe werden neu akzeptiert oder exportiert, welche fallen weg?

Damit werden Fehler früh gefunden, bevor sie im Backbone wirken. Zusätzlich entstehen Audit-Nachweise automatisch: Wer hat was geändert, wer hat es reviewed, und welche Tests sind gelaufen.

Peering und Customer Onboarding: Baseline als wiederholbarer Prozess

Eine BGP Baseline ist besonders stark, wenn sie Onboarding standardisiert. Neue Kunden oder Peers sollten nicht individuell „von Hand“ angebunden werden, sondern über wiederholbare Blueprints: Relationship-Typ wählen, Prefix-Quelle hinterlegen, Max-Prefix setzen, Communities definieren, Monitoring aktivieren.

• Onboarding-Checkliste: Prefix-Ownership, RPKI-Status, Filter, Max-Prefix, Export-Policy.
• Standard-Communities: für Traffic-Engineering, Export-Steuerung und Incident-Fälle.
• Rezertifizierung: regelmäßige Prüfung von Kundenpräfixen, insbesondere bei Produkt- oder Vertragsänderungen.
• Incident-Runbooks: klare Abläufe bei Leak/Hijack (temporäre Filter, Depriorisierung, Kontaktwege).

Praktische Baseline-Checkliste: BGP Security im Provider-Netz

• RPKI aktiviert? Valid/Invalid/Unknown-Policy definiert, Monitoring für invalid Events vorhanden.
• Prefix Filters umgesetzt? Allow-Lists für Kunden, klare Policies für Peers/Upstreams, automatisierte Pflege.
• Max-Prefix gesetzt? Warnschwelle und Hardlimit je Session, regelmäßige Anpassung an Wachstum.
• Route Leak Schutz aktiv? strikte Export-Templates, Community-Strategie, AS-PATH-Plausibilitätschecks.
• Hygiene-Regeln konsistent? Bogons/Martians, Prefix-Length-Filter, Next-Hop-Plausibilität.
• Observability vorhanden? Session Health, Prefix-Trends, Policy-Diffs, Route-Analytics und Alerts.
• Governance etabliert? Baseline-as-Code, Reviews, Canary-Rollouts, Rezertifizierung und Nachweise.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.