BGP Security: GTSM, MD5, Prefix Limits – Best Practices

BGP ist kritisch für Internet- und WAN-Routing – und damit ein attraktives Ziel für Fehlkonfigurationen und Angriffe. „Security“ bei BGP bedeutet in der Praxis: Sessions gegen Spoofing absichern, ungewollte Nachbarn verhindern, Route Leaks begrenzen und Ressourcen schützen. Die wichtigsten Werkzeuge auf Cisco sind GTSM (TTL-Schutz), TCP MD5 (Session-Auth) und Prefix Limits (Max-Prefix). Kombiniert mit Filtern (Prefix-Lists/Route-Maps) entsteht ein robustes, auditierbares Edge-Design.

Bedrohungsbild: Was kann bei BGP schiefgehen?

Viele BGP-Vorfälle sind nicht „Hacker“, sondern Konfigurationsfehler: falsche Announcements, unerwartete Full Tables oder Sessions mit falschen Nachbarn. Die Folgen reichen von lokalen Ausfällen bis zu großflächigen Routing-Störungen.

• Unautorisierte Session (Spoofing/fehlende Edge-ACLs)
• Route Leak: fremde Präfixe werden announct
• Prefix Flood: zu viele Routen → RAM/CPU-Probleme
• Session Instability: Resets, Flaps, Timing-Probleme

GTSM (TTL Security): Schutz gegen Spoofing auf eBGP-Links

GTSM (Generalized TTL Security Mechanism) schützt BGP, indem es erwartet, dass Pakete mit hoher TTL ankommen (typischerweise 255). Damit werden Off-Path-Angriffe deutlich erschwert, weil Pakete aus „weiter weg“ durch TTL-Abbau nicht mehr akzeptiert werden.

• Typisch für eBGP direkt verbunden (1 Hop)
• Verhindert viele Spoofing-Szenarien durch TTL-Check
• Funktioniert nur sauber, wenn der Hop-Count passt

GTSM konfigurieren (Cisco IOS, eBGP direkt)

Router# configure terminal
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.1 remote-as 64500
Router(config-router)# neighbor 203.0.113.1 ttl-security hops 1
Router(config-router)# end

Wichtig bei Multihop

Wenn eBGP über mehrere Hops läuft, muss die Hop-Zahl passen oder GTSM ist ungeeignet. In Multihop-Szenarien wird oft eher mit Infrastruktur-ACLs und stabilen Loopback-Designs gearbeitet.

TCP MD5: Authentifizierung der BGP-Session

TCP MD5 schützt die Session vor unautorisierten TCP-Verbindungen und erschwert Session-Hijacking. Beide Seiten müssen exakt das gleiche Passwort konfigurieren. Ein Mismatch führt zu TCP-Resets oder „Active“-Zuständen.

• Schützt die TCP-Session (nicht die Route-Inhalte)
• Beide Seiten müssen identisch konfiguriert sein
• Operational: Key-Rotation planen, Dokumentation wichtig

MD5-Passwort setzen (Cisco IOS)

Router# configure terminal
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.1 remote-as 64500
Router(config-router)# neighbor 203.0.113.1 password Str0ngBGPKey!
Router(config-router)# end

MD5-Probleme erkennen

Router# show ip bgp summary
Router# show ip bgp neighbors 203.0.113.1 | include BGP state
Router# show logging | include BGP|TCP|MD5

Prefix Limits (Maximum-Prefix): Schutz vor Route Floods

maximum-prefix begrenzt, wie viele Präfixe du von einem Neighbor akzeptierst. Das schützt Ressourcen und hilft gegen Konfigfehler beim Provider (z. B. plötzlich Full Table statt Default). Je nach Policy kannst du bei Überschreitung warnen, die Session resetten oder automatisch neu starten.

• Ressourcenschutz: RAM/CPU
• Safety Net gegen unerwartete Routenmengen
• Pro Neighbor individuell anpassbar (Default-only vs. Full table)

Maximum-Prefix setzen (Beispiel: Full Table + Warnschwelle)

Router# configure terminal
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.1 maximum-prefix 200000 90 restart 5
Router(config-router)# end

Default-Only Szenario (kleines Limit)

Wenn du bewusst nur eine Default Route akzeptierst, sollte das Prefix-Limit entsprechend klein sein.

Router# configure terminal
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.1 maximum-prefix 20 90 warning-only
Router(config-router)# end

Pflicht ergänzen: Route Filtering als Basis-Security

GTSM, MD5 und Prefix Limits sind wichtig, ersetzen aber nicht das Kernprinzip: inbound und outbound filtern. Outbound musst du verhindern, dass du fremde Präfixe announcest. Inbound solltest du nur annehmen, was du brauchst.

• Outbound: Prefix-List „nur mein Netz“ + deny all
• Inbound: Default-only oder definierte Präfixsets
• Zusätzlich: Communities/Policies nur gezielt matchen

Outbound-Filter (nur eigenes /24)

Router# configure terminal
Router(config)# ip prefix-list OUT-MYNET seq 10 permit 203.0.113.0/24
Router(config)# ip prefix-list OUT-MYNET seq 999 deny 0.0.0.0/0 le 32
Router(config)# router bgp 65001

Router(config-router)# neighbor 203.0.113.1 prefix-list OUT-MYNET out

Router(config-router)# end

Inbound-Filter (nur Default)

Router# configure terminal
Router(config)# ip prefix-list IN-DEFAULT seq 10 permit 0.0.0.0/0
Router(config)# ip prefix-list IN-DEFAULT seq 999 deny 0.0.0.0/0 le 32
Router(config)# router bgp 65001

Router(config-router)# neighbor 203.0.113.1 prefix-list IN-DEFAULT in

Router(config-router)# end

Control Plane und ACLs: BGP nur vom richtigen Nachbarn erlauben

Auch ohne komplexe Control-Plane-Policing-Designs solltest du mindestens sicherstellen, dass TCP/179 nur vom erwarteten Neighbor erreicht wird. Das reduziert Angriffsfläche und Debug-Aufwand.

Interface/Transit-ACL prüfen (und gezielt einschränken)

Router# show ip interface gigabitEthernet0/1
Router# show running-config | include access-group
Router# show access-lists

Operational Best Practices: sicher betreiben ohne Ausfälle

Security-Features sind nur dann hilfreich, wenn sie konsistent ausgerollt und verifiziert werden. Plane Änderungen, überwache Sessions und dokumentiere Limits und Keys.

• GTSM auf direkt verbundenen eBGP-Links standardisieren
• MD5-Schlüssel rotieren (Change-Prozess), Secrets sicher verwalten
• Maximum-Prefix pro Neighbor passend dimensionieren
• Inbound/Outbound-Filter immer aktiv (Prefix-Lists/Route-Maps)
• Nach Changes: advertised/received routes prüfen

Verifikation: Wirkt die Security-Konfiguration?

Nach dem Rollout prüfst du Sessions, Route-Mengen und Filterwirkung. Ziel ist: Session stabil, keine unerwarteten Routen, Limits greifen nur im Ausnahmefall.

Session und Route-Menge prüfen

Router# show ip bgp summary
Router# show ip bgp neighbors 203.0.113.1 | include prefixes
Router# show ip bgp

Advertised/Received prüfen (Filterwirkung)

Router# show ip bgp neighbors 203.0.113.1 advertised-routes
Router# show ip bgp neighbors 203.0.113.1 received-routes

Logs bei Schutz-Events prüfen

Router# show logging | include BGP|MAXPFX|TTL|MD5

Quick-Reference: Security-Checkliste (Copy & Paste)

Diese Kommandos reichen meist, um BGP-Security-Status schnell zu validieren.

show ip bgp summary
show ip bgp neighbors 203.0.113.1
show ip bgp neighbors 203.0.113.1 advertised-routes
show ip bgp neighbors 203.0.113.1 received-routes
show ip prefix-list
show route-map
show ip interface gigabitEthernet0/1
show access-lists
show logging | include BGP|MAXPFX|TTL|MD5

Konfiguration speichern

Router# copy running-config startup-config

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.