Über Control Plane Policing (CPP) habe ich vor einiger Zeit schon etwas geschrieben. In der IOS-Version 12.4(4)T wurde der Schutz der Control-Plane nochmals erweitert, u.a. mit einem Paketfilter, der auf geschlossene Ports wirkt.
Dieses Beispiel zeigt die Wichtigkeit dieser Funktion auf einem meiner Router.
Ich verwende einen Cisco 1802 mit IOS 12.4(11)XJ3
router#sh ver | i ersion
Cisco IOS Software, C180X Software (C180X-ADVIPSERVICESK9-M), Version 12.4(11)XJ3, RELEASE SOFTWARE (fc1)
Synched to technology version 12.4(11)T
ROM: System Bootstrap, Version 12.3(8r)YH6, RELEASE SOFTWARE (fc1)Um möglichst viele Pakete schnell senden zu können habe ich den Portscanner scanrand 1.10 aus dem Paket Paketto Keiretsu benutzt:
scanrand -S -b0 10.255.255.1:allDas Senden der Pakete dauert ca. eine Sekunde und dieser Router ist danach reproduzierbar nicht mehr erreichbar. Manchmal rebootet er sofort, manchmal mit ein paar Sekunden Verzögerung.
Mit einer Interface-Geschwindigkeit von nur 10 MBit/s dauert das Senden zwar ca. fünf Sekunden, das Ergebnis ist aber dasselbe.
Nach dem Neustart ist die Fehlermeldung zu erkennen:
router#sh ver | i to ROM
System returned to ROM by error - an Illegal Opcode exception, PC 0x83526940 at 15:06:59 MESZ Mon Jun 11 2007Um dieses Problem der DOS-Anfälligkeit zu beheben, wird Control-Plane-Protection (CPPr) konfiguriert:
Eine Class-Map, die geschlossene Ports erkennt, wird konfiguriert:
class-map type port-filter match-all closed-ports
match closed-portsEine Policy-Map benutzt die Class-Map, um die Pakete zu verwerfen:
policy-map type port-filter CP-Filtering
class closed-ports
dropDie Policy-Map wird auf die Control-Plane gebunden:
control-plane host
service-policy type port-filter input CP-Filtering
Nach dieser Konfiguration wird der Router wirklich gestresst:
while [ 1 ]; do scanrand -S -b0 10.255.255.1:all; done
Das Paket-Forwarding ist während dieses Beschusses mit Paketen deutlich gestört, was auch an der Menge verlorener echo-requests zu erkennen ist:
...
64 bytes from www.heise.de (193.99.144.85): icmp_seq=91 ttl=247 time=53.1 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=93 ttl=247 time=50.1 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=94 ttl=247 time=47.4 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=99 ttl=247 time=45.3 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=100 ttl=247 time=34.6 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=101 ttl=247 time=34.3 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=102 ttl=247 time=51.1 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=109 ttl=247 time=46.2 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=111 ttl=247 time=51.0 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=112 ttl=247 time=46.7 ms
...Der Router bleibt aber stabil und ist nach Beendigung eines gut einminütigen “Angriffs” sofort wieder erreichbar:
CPU utilization for five seconds: 46%/46%; one minute: 68%; five minutes: 30%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
53 2528 8680 291 0.27% 0.20% 0.12% 0 COLLECT STAT COU
81 1612 3004 536 0.36% 0.20% 0.10% 0 IP Input
Die “Wichtigkeit” dieser Aktion muß man allerdings doch relativieren. Einen Absturz konnte ich nur bei zwei Routern (diesem 1802 und einem 876) mit sehr neuen IOS-Releases und sehr komplexen Konfigurationen herbeiführen. Sowohl die Tests mit 12.4-IOS-Releases und einfacherer Konfiguration, als auch auf anderen Plattformen (2621XM, 3640, 2801, 2811) haben nicht zu einem Absturz geführt.
Nach diesem Test habe ich erstmal auf diversen Routern das CPPr aktiviert. Diese Abstürze sind zwar sicher IOS-Bugs, aber wenn man sich mit ein paar Zeilen auch dagegen schützen kann, ist es doch auch gut.
Weitere Informationen gibt es in der Dokumentation von Cisco: