Site icon bintorosoft.com

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

Red Snapper

internet concept

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

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

TTL-Logik

Off-Path Angreifer  →  TTL fällt unterwegs  →  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.

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

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

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

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.

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

Sie erhalten

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.

Exit mobile version