Control Plane Policing (CoPP): Router vor Angriffen schützen

Control Plane Policing (CoPP) schützt Cisco Router vor Angriffen und Fehlkonfigurationen, indem es Traffic zur Control Plane (CPU) klassifiziert und begrenzt. Ohne CoPP kann schon ein moderater ICMP-/Scan-/Routing-Flood die CPU auslasten, wodurch Management (SSH), Routing-Protokolle (OSPF/BGP) und sogar Forwarding indirekt beeinträchtigt werden können. CoPP ist deshalb ein zentraler Hardening-Baustein für Router am Internet-Edge, in großen Campus-Netzen und überall dort, wo viele Hosts die Router-IP erreichen.

Was ist die Control Plane – und warum ist sie angreifbar?

Die Control Plane verarbeitet Pakete, die der Router selbst „terminiert“: Management (SSH/SNMP), Routing-Protokolle (OSPF/BGP), ICMP an die Router-IP, ARP/ND, DHCP-Relay, u. a. Diese Pakete landen auf der CPU. Dataplane-Forwarding hingegen wird oft hardwarebasiert abgewickelt.

• Control Plane: CPU-Processing (Router als Ziel)
• Data Plane: Forwarding durch den Router (Transit)
• Angriffsmuster: viele Pakete an Router-IP → CPU-Last

Merker

$\text{CoPP} => \text{Rate-Limit für CPU-Traffic}$

Wann CoPP besonders wichtig ist

CoPP ist immer sinnvoll, aber besonders kritisch an Stellen, wo viele Clients die Router-IP erreichen oder wo Internet-Traffic potenziell bis zur Router-Control-Plane durchkommt.

• Internet-Edge und Provider-Uplinks
• Campus-Core/Distribution mit vielen VLAN-Gateways
• DMZ-Router, Partnernetze, Extranet
• Router mit aktivem BGP/OSPF und exponierten Loopbacks

CoPP-Design: „Classify, Police, Protect“

CoPP besteht aus drei Teilen: du definierst, welcher Traffic zur Control Plane gehört (class-map), du legst Limits fest (policy-map), und du bindest die Policy an die Control Plane (service-policy input). Wichtig ist ein konservatives, schrittweises Vorgehen, um Routing und Management nicht zu stören.

• Class-Maps: Traffic-Gruppen definieren
• Policy-Map: Limits (police) setzen
• Control-Plane: Policy als Input binden

Schritt 1: Management- und Routing-Traffic definieren

Der wichtigste Designschritt ist die saubere Klassifizierung. Typisch sind separate Klassen für SSH, Routing-Protokolle und ICMP. Alles andere wird restriktiv behandelt oder stark begrenzt.

Beispiel: ACLs für Control-Plane-Traffic (präzise Quellen)

Best Practice ist, Management nur aus einem Admin-Netz zuzulassen und Routing-Protokolle nur von erwarteten Peers.

Router# configure terminal
Router(config)# ip access-list extended CP_SSH
Router(config-ext-nacl)# permit tcp 192.168.10.0 0.0.0.255 any eq 22
Router(config-ext-nacl)# exit
Router(config)# ip access-list extended CP_OSPF

Router(config-ext-nacl)# permit ospf 10.0.0.0 0.0.0.255 any

Router(config-ext-nacl)# exit
Router(config)# ip access-list extended CP_BGP

Router(config-ext-nacl)# permit tcp host 203.0.113.1 any eq 179

Router(config-ext-nacl)# permit tcp host 198.51.100.1 any eq 179

Router(config-ext-nacl)# exit
Router(config)# ip access-list extended CP_ICMP

Router(config-ext-nacl)# permit icmp any any echo

Router(config-ext-nacl)# permit icmp any any echo-reply

Router(config-ext-nacl)# exit

Router(config)# end

Schritt 2: Class-Maps erstellen (Match per ACL oder Protokoll)

Class-maps gruppieren den Traffic. Du kannst per ACL matchen (empfohlen, weil du Quellen einschränken kannst) oder per Protokoll, je nach IOS/Plattform.

Router# configure terminal
Router(config)# class-map match-any CM_CP_SSH
Router(config-cmap)# match access-group name CP_SSH
Router(config-cmap)# exit
Router(config)# class-map match-any CM_CP_OSPF

Router(config-cmap)# match access-group name CP_OSPF

Router(config-cmap)# exit
Router(config)# class-map match-any CM_CP_BGP

Router(config-cmap)# match access-group name CP_BGP

Router(config-cmap)# exit
Router(config)# class-map match-any CM_CP_ICMP

Router(config-cmap)# match access-group name CP_ICMP

Router(config-cmap)# exit

Router(config)# end

Schritt 3: Policy-Map mit Police-Limits definieren

Nun legst du Limits fest. Werte sind stark abhängig von Plattform, Routing-Dichte und Management-Volumen. Ein sicherer Ansatz ist: Management und Routing moderat erlauben, ICMP restriktiv begrenzen, Default-Class stark begrenzen oder droppen.

Policy-Map Beispiel (Startkonfiguration)

Router# configure terminal
Router(config)# policy-map PM_COPP
Router(config-pmap)# class CM_CP_SSH
Router(config-pmap-c)# police 64000 conform-action transmit exceed-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# class CM_CP_OSPF

Router(config-pmap-c)# police 128000 conform-action transmit exceed-action drop

Router(config-pmap-c)# exit
Router(config-pmap)# class CM_CP_BGP

Router(config-pmap-c)# police 128000 conform-action transmit exceed-action drop

Router(config-pmap-c)# exit
Router(config-pmap)# class CM_CP_ICMP

Router(config-pmap-c)# police 32000 conform-action transmit exceed-action drop

Router(config-pmap-c)# exit
Router(config-pmap)# class class-default

Router(config-pmap-c)# police 16000 conform-action transmit exceed-action drop

Router(config-pmap-c)# end

Warum class-default nicht „permit all“ sein sollte

Unklassifizierter Traffic ist genau der Traffic, den Angriffe ausnutzen. Wenn du class-default zu offen lässt, ist CoPP wirkungslos. Wenn du ihn zu hart drosselst, kann legitimer „Control-Plane-Randverkehr“ leiden – daher schrittweise vorgehen.

Schritt 4: CoPP an die Control Plane binden

Die Policy wirkt erst, wenn sie an die Control Plane gebunden ist. Das passiert typischerweise mit control-plane und service-policy input.

Router# configure terminal
Router(config)# control-plane
Router(config-cp)# service-policy input PM_COPP
Router(config-cp)# end

Verifikation: Zähler und CPU-Last prüfen

Nach dem Aktivieren prüfst du, ob Pakete in den Klassen matchen und ob Drops auftreten. Zusätzlich beobachtest du CPU und Log-Meldungen. Drops sind nicht per se schlecht – sie zeigen, dass CoPP arbeitet.

Policy Counters prüfen

Router# show policy-map control-plane
Router# show policy-map control-plane input

CPU und Logs prüfen

Router# show processes cpu sorted
Router# show logging

Best Practices: CoPP sicher einführen ohne Routing-Ausfall

CoPP ist mächtig – und kann bei falschen Limits Routing-Protokolle oder SSH stören. Ein kontrollierter Rollout ist deshalb essenziell.

• Zuerst Klassifizierung korrekt bauen (Quellen eng halten)
• Mit großzügigen Limits starten, dann schrittweise reduzieren
• Während der Änderung Console/OOB bereit halten
• Routing-Neighbors (OSPF/BGP) und SSH nach Aktivierung testen
• class-default nicht vergessen, aber konservativ behandeln

Operational Checks nach Aktivierung

Router# show ip ospf neighbor
Router# show ip bgp summary
Router# show users
Router# show policy-map control-plane

Typische Fehler und Lösungen

Wenn nach CoPP-Aktivierung Probleme auftreten, ist fast immer ein Match zu breit oder ein Police-Limit zu niedrig. Prüfe zuerst die Zähler: Wo steigen Drops?

• SSH bricht: SSH-Klasse matcht nicht oder Limit zu klein
• OSPF/BGP flappen: Routing-Klasse unvollständig oder zu aggressiv gedrosselt
• Alles scheint ok, aber CPU bleibt hoch: class-default zu offen
• Unklare Drops: ACLs matchen „any any“ statt erwartete Quellen

Quick-Checks

show policy-map control-plane
show processes cpu sorted
show ip ospf neighbor
show ip bgp summary
show running-config | section control-plane
show access-lists

Konfiguration speichern

Wenn Zähler plausibel sind, Routing-Neighbors stabil bleiben und SSH zuverlässig funktioniert, speichere die Konfiguration.

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.