BGP Security Hardening: TTL Security, MD5, Max-Prefix, GTSM sauber umsetzen

BGP ist das Steuerprotokoll für Internet- und WAN-Routing – und damit ein attraktives Ziel für Angriffe, Fehlkonfigurationen und „accidental peering“. Security Hardening bedeutet hier nicht „ein Feature aktivieren“, sondern mehrere Schutzschichten sauber kombinieren: (1) Session-Schutz gegen Spoofing/Off-Path-Angriffe (TTL Security/GTSM), (2) Authentifizierung/Integrität auf der TCP-Sitzung (MD5/TCP-AO je nach Plattform), und (3) Guardrails gegen Routing-Fehlerszenarien (Max-Prefix, Filter, Logging). Dieser Artikel zeigt praxistaugliche Konfigurationsmuster auf Cisco Routern und erklärt typische Fallstricke.

Bedrohungsmodell: Was du mit BGP-Hardening wirklich adressierst

BGP-Hardening schützt vor zwei Hauptklassen: Angriffe auf die BGP-Session (Reset, Hijack, Spoofing) und Betriebsfehler (Route-Leaks, Full-Table in falsche Richtung, Prefix-Explosion). Die Maßnahmen unterscheiden sich je nach eBGP (Provider) oder iBGP (intern).

• Session-Angriffe: gefälschte TCP-Pakete, unerwartete Peers, Reset-Attacken
• Betriebsfehler: zu viele Prefixes, falsche Announcements, Policy-Miss
• Designfehler: Peering über „unsichere“ Transitpfade ohne Schutz

TTL Security vs. GTSM: gleiche Idee, sauberer Einsatz

TTL Security und GTSM (Generalized TTL Security Mechanism) basieren auf einem Prinzip: Off-Path-Angreifer sollen die BGP-Session nicht erreichen, weil ihre Pakete nicht mit der erwarteten TTL am Router ankommen. Bei direkt verbundenen eBGP-Peers ist das besonders wirksam und fast „kostenlos“.

• Direktes eBGP (1 Hop): sehr empfehlenswert
• eBGP Multihop: möglich, aber TTL-Logik muss passen
• iBGP: weniger üblich, aber bei untrusted Underlay sinnvoll

TTL-Logik

$\text{Off-Path Angreifer} \to \text{TTL fällt unterwegs} \to \text{Paket wird verworfen}$

GTSM/TTL Security konfigurieren: Direktes eBGP (Best Practice)

Für direktes eBGP mit Provider ist die Standardempfehlung: TTL Security aktivieren. Das reduziert die Angriffsfläche stark, ohne die Session zu verkomplizieren.

TTL Security auf dem Neighbor (Beispiel)

router bgp 65000
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 ttl-security hops 1

Verifikation

show ip bgp neighbors 203.0.113.1 | include TTL|security

GTSM bei eBGP Multihop: Risiko und saubere Parameter

Bei Multihop-eBGP (z. B. Peering über Loopbacks) musst du TTL so setzen, dass es zur realen Hop-Anzahl passt. Zu niedrig: Session kommt nicht hoch. Zu hoch: Schutzwirkung sinkt. Multihop sollte außerdem immer mit strengen ACLs und TCP/MD5 kombiniert werden.

Multihop Beispiel (Pattern)

router bgp 65000
 neighbor 10.255.0.2 remote-as 64500
 neighbor 10.255.0.2 ebgp-multihop 2
 neighbor 10.255.0.2 ttl-security hops 2

MD5 (TCP MD5) für BGP: Integrität der Session

TCP MD5 schützt die BGP-Sitzung gegen Spoofing und unautorisierte Reset-Pakete, weil jedes Segment mit einem Shared Secret signiert wird. Es ist besonders sinnvoll bei eBGP Multihop oder wenn du nicht garantieren kannst, dass der Transportpfad „trusted“ ist.

• Direktes eBGP: TTL Security oft ausreichend, MD5 zusätzlich möglich
• Multihop: MD5 stark empfohlen
• Pitfall: Key-Rollover braucht Prozess, sonst Outage

MD5 konfigurieren (Beispiel)

router bgp 65000
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 password 7 02050D480809

Hinweis zur Praxis

• Nutze starke Secrets und verwalte sie wie Credentials
• Plane Key-Rollover als Change (beidseitig synchron)

Max-Prefix: Der wichtigste Guardrail gegen Route-Explosion

Max-Prefix schützt dich, wenn ein Provider oder ein interner Peer plötzlich viel mehr Routen sendet als erwartet (Fehlkonfiguration, Leak, Full Table). Das ist ein klassischer „saves-your-day“-Parameter. Wichtig ist die Schwelle und das Verhalten: Warnen, drosseln oder Session resetten.

Max-Prefix konfigurieren (Beispiel)

router bgp 65000
 neighbor 203.0.113.1 maximum-prefix 100000 90 restart 5

Interpretation

• 100000: Hard-Limit
• 90: Warnschwelle in Prozent
• restart 5: Session nach 5 Minuten automatisch versuchen

Prefix-Filtering: Ohne Filter ist Hardening unvollständig

TTL/MD5 schützen die Session, aber nicht die Inhalte. Daher ist Filtering Pflicht: inbound Bogons/Private Netze, outbound nur eigene Prefixes. Das verhindert Route Leaks und reduziert Fehlerszenarien drastisch.

Outbound Whitelist (Beispiel)

ip prefix-list PL_OUT_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_OUT_OWNED seq 20 permit 198.51.100.0/24
ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32
route-map RM_OUT permit 10

match ip address prefix-list PL_OUT_OWNED

route-map RM_OUT deny 100

match ip address prefix-list PL_ANY

Anwendung am Neighbor

router bgp 65000
 neighbor 203.0.113.1 route-map RM_OUT out

CoPP und ACLs: Control Plane zusätzlich absichern

Auch mit TTL Security/MD5 bleibt BGP ein Control-Plane-Service. Du solltest BGP-Traffic nur von erwarteten Peer-IPs zulassen und die Control Plane gegen Floods schützen. Besonders bei Internet-Edges ist das Standard.

• ACL: TCP/179 nur von Peer-IP erlauben
• CoPP: Rate-Limits für Control-Plane Traffic
• Logging: Session-Flaps und Policy-Drops sichtbar machen

ACL-Prinzip (Beispiel, Interface-Ingress)

ip access-list extended ACL_WAN_IN
 permit tcp host 203.0.113.1 host 203.0.113.2 eq 179
 deny   tcp any host 203.0.113.2 eq 179
 permit ip any any

iBGP Hardening: Andere Prioritäten als eBGP

Im iBGP ist das Hauptproblem selten „Internet-Angriff“, sondern Fehlkonfiguration und Skalierung. Trotzdem sind Guards wichtig: MD5 bei untrusted Transport, Max-Prefix gegen interne Leaks, und saubere RR-Designs.

• RR-Design + Cluster-IDs korrekt (Loop-Prevention)
• Max-Prefix auch intern (z. B. VRF Leaks, Automation-Bugs)
• MD5/ACL, wenn iBGP über fremde Netze transportiert wird

Verifikation: Hardening ist nur gut, wenn du es messen kannst

Nach dem Rollout musst du prüfen, ob die Session stabil ist und ob Limits/Policies greifen. Gerade Max-Prefix und Filter sollten im Normalbetrieb „0 Drops“ erzeugen und nur im Fehlerfall wirken.

Status prüfen

show ip bgp summary
show ip bgp neighbors 203.0.113.1

Policy/Filter prüfen

show route-map
show ip prefix-list
show access-lists

Max-Prefix/Events prüfen

show logging | include BGP|MAXPFX|TTL|security

Typische Pitfalls und wie du sie vermeidest

Hardening scheitert meist an Details: falsche TTL-Hops bei Multihop, MD5 nicht auf beiden Seiten identisch, oder Max-Prefix zu niedrig gesetzt. Das führt zu vermeidbaren Outages.

• TTL Security zu niedrig → Session kommt nicht hoch
• MD5 Key mismatch → Session bleibt idle/active
• Max-Prefix falsch dimensioniert → unnötige Resets
• Outbound Filter fehlt → Route Leak trotz „sicherer Session“

Quick-Template: eBGP Peer sicher (TTL + MD5 + Max-Prefix + Filter)

Dieses Template ist eine Baseline für direktes eBGP. Passe IPs, Limits und Prefixes an.

ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32
ip prefix-list PL_OUT_OWNED seq 10 permit 203.0.113.0/24
route-map RM_OUT permit 10

match ip address prefix-list PL_OUT_OWNED

route-map RM_OUT deny 100

match ip address prefix-list PL_ANY
router bgp 65000

neighbor 203.0.113.1 remote-as 64500

neighbor 203.0.113.1 ttl-security hops 1

neighbor 203.0.113.1 password 7 02050D480809

neighbor 203.0.113.1 maximum-prefix 100000 90 restart 5

neighbor 203.0.113.1 route-map RM_OUT out

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.