{"id":180,"date":"2007-06-18T00:24:06","date_gmt":"2007-06-17T22:24:06","guid":{"rendered":"http:\/\/security-planet.de\/2007\/06\/18\/cisco-ios-der-paketfilter-der-control-plane-protection\/"},"modified":"2007-06-18T00:24:06","modified_gmt":"2007-06-17T22:24:06","slug":"cisco-ios-der-paketfilter-der-control-plane-protection","status":"publish","type":"post","link":"https:\/\/cyber-fi.net\/index.php\/2007\/06\/18\/cisco-ios-der-paketfilter-der-control-plane-protection\/","title":{"rendered":"Cisco IOS: Der Paketfilter der Control-Plane-Protection"},"content":{"rendered":"

\u00dcber Control Plane Policing (CPP) habe ich vor einiger Zeit schon etwas geschrieben<\/a>. 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.<\/p>\n

Dieses Beispiel zeigt die Wichtigkeit dieser Funktion auf einem meiner Router.
\n
\nIch verwende einen Cisco 1802 mit IOS 12.4(11)XJ3<\/p>\n

router#sh ver | i ersion\nCisco IOS Software, C180X Software (C180X-ADVIPSERVICESK9-M), Version 12.4(11)XJ3, RELEASE SOFTWARE (fc1)\nSynched to technology version 12.4(11)T\nROM: System Bootstrap, Version 12.3(8r)YH6, RELEASE SOFTWARE (fc1)<\/code><\/pre>\n
Um m\u00f6glichst viele Pakete schnell senden zu k\u00f6nnen habe ich den Portscanner scanrand 1.10 aus dem Paket Paketto Keiretsu<\/a> benutzt:<\/p>\n
scanrand -S -b0 10.255.255.1:all<\/code><\/pre>\n
Das 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\u00f6gerung.
\nMit einer Interface-Geschwindigkeit von nur 10 MBit\/s dauert das Senden zwar ca. f\u00fcnf Sekunden, das Ergebnis ist aber dasselbe.<\/p>\n
Nach dem Neustart ist die Fehlermeldung zu erkennen:<\/p>\n
\nrouter#sh ver | i to ROM\nSystem returned to ROM by error - an Illegal Opcode exception, PC 0x83526940 at 15:06:59 MESZ Mon Jun 11 2007<\/code><\/pre>\n
Um dieses Problem der DOS-Anf\u00e4lligkeit zu beheben, wird Control-Plane-Protection (CPPr) konfiguriert:<\/p>\n
Eine Class-Map, die geschlossene Ports erkennt, wird konfiguriert:<\/p>\n
class-map type port-filter match-all closed-ports\n match closed-ports<\/code><\/pre>\n
Eine Policy-Map benutzt die Class-Map, um die Pakete zu verwerfen:<\/p>\n
policy-map type port-filter CP-Filtering\n class closed-ports\n   drop<\/code><\/pre>\n
Die Policy-Map wird auf die Control-Plane gebunden:<\/p>\n
control-plane host\n service-policy type port-filter input CP-Filtering\n<\/code><\/pre>\n
Nach dieser Konfiguration wird der Router wirklich gestresst:<\/p>\n
while [ 1 ]; do scanrand -S -b0 10.255.255.1:all; done\n<\/code><\/pre>\n
Das Paket-Forwarding ist w\u00e4hrend dieses Beschusses mit Paketen deutlich gest\u00f6rt, was auch an der Menge verlorener echo-requests zu erkennen ist:<\/p>\n
...\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=91 ttl=247 time=53.1 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=93 ttl=247 time=50.1 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=94 ttl=247 time=47.4 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=99 ttl=247 time=45.3 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=100 ttl=247 time=34.6 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=101 ttl=247 time=34.3 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=102 ttl=247 time=51.1 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=109 ttl=247 time=46.2 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=111 ttl=247 time=51.0 ms\n64 bytes from www.heise.de (193.99.144.85): icmp_seq=112 ttl=247 time=46.7 ms\n...<\/code><\/pre>\n
Der Router bleibt aber stabil und ist nach Beendigung eines gut einmin\u00fctigen “Angriffs” sofort wieder erreichbar:<\/p>\n
CPU utilization for five seconds: 46%\/46%; one minute: 68%; five minutes: 30%\n PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process\n  53        2528      8680        291  0.27%  0.20%  0.12%   0 COLLECT STAT COU\n  81        1612      3004        536  0.36%  0.20%  0.10%   0 IP Input\n<\/code><\/pre>\n
Die “Wichtigkeit” dieser Aktion mu\u00df 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\u00fchren. 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\u00fchrt.<\/p>\n
Nach diesem Test habe ich erstmal auf diversen Routern das CPPr aktiviert. Diese Abst\u00fcrze sind zwar sicher IOS-Bugs, aber wenn man sich mit ein paar Zeilen auch dagegen sch\u00fctzen kann, ist es doch auch gut.<\/p>\n
Weitere Informationen gibt es in der Dokumentation von Cisco:<\/p>\n