Kaputtmonitored
Alle zwei Stunden verweigert ein Router die SNMP-Monitoringabfragen. Er liefert keine Werte mehr fürs Accounting. Er stellt sich tot. Man kann die Uhr danach stellen. Aber warum?
Die Kiste selbst war nie auffällig, sobald die Meldung über den Ausfall kommt. Sie antwortet auf SNMP und reagiert ganz vernünftig.
Zuerst einmal habe ich triviale SNMP Anfragen (SNMPv2-MIB::sysUpTime.0) und ein Ping alle paar Minuten per cronjob losgeschickt. Vielleicht liegt es ja an einem sporadischen DNS oder Routingproblem. Es könnten ARP- oder DNS-Einträge austimen.
#! /bin/sh SLEEP=5 HOST=mein.router GEHEIM='quick&dirty' for (( i=0; i<12; i=i+SLEEP )); do echo -n "$i: $(date '+%H:%M:%S') " ping -w1 -c1 -n $HOST | egrep 'icmp_seq|Timeout' snmpget -v2c -c '$GEHEIM' $HOST SNMPv2-MIB::sysUpTime.0 echo sleep $SLEEP done >> /var/log/router-debug.log 2>&1
Das Ergebnis sieht so aus:
0: 00:15:01 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=0.334 ms SNMPv2-MIB::sysUpTime.0 = Timeticks: (140753008) 16 days, 6:58:50.08 5: 00:15:06 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=7.13 ms SNMPv2-MIB::sysUpTime.0 = Timeticks: (140753520) 16 days, 6:58:55.20 10: 00:15:12 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=0.390 ms SNMPv2-MIB::sysUpTime.0 = Timeticks: (140754028) 16 days, 6:59:00.28 0: 00:16:01 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=0.310 ms SNMPv2-MIB::sysUpTime.0 = Timeticks: (140758932) 16 days, 6:59:49.32 5: 00:16:06 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=0.318 ms SNMPv2-MIB::sysUpTime.0 = Timeticks: (140759436) 16 days, 6:59:54.36 10: 00:16:11 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=0.316 ms SNMPv2-MIB::sysUpTime.0 = Timeticks: (140759941) 16 days, 6:59:59.41 0: 00:17:01 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=13.5 ms Timeout: No Response from mein.router. 5: 00:17:12 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=82.6 ms Timeout: No Response from mein.router. 10: 00:17:23 64 bytes from <IPv4>: icmp_seq=1 ttl=255 time=72.9 ms Timeout: No Response from mein.router.
Immer 17 Minuten nach einer geraden Stunde gehen die Ping-Zeiten hoch und die Kiste antwortet nicht mehr auf SNMP.
Der Spuk hält ca. vier Minuten an. Die Alarmierung kommt – wenn überhaupt – immer 20 nach. Das erklärt zumindest, warum man nach dem Vorfall nichts mehr sah. Oder doch?
100 *###* 90 * *###* * 80 ** *#### * * * 70 * **** *#### * * * * * 60 * * **** *#### * * * * * * * * 50 * * **#* *#### * * * * * * * * 40 * * ###* ##### * * * * * ** * *** 30 * * #### ##### **** * * * * ** ** * **** 20 **********####*#####****** ******************************** 10 ***#****#**####*#####**#*****#****#****#****#****#****#****# 0....5....1....1....2....2....3....3....4....4....5....5.... 0 5 0 5 0 5 0 5 0 5 CPU% per minute (last 60 minutes) * = maximum CPU% # = average CPU%
Offenbar ist die Maschine gerade heftig unter Last geraten. Ein BGP Update? Möglich. Aber so regelmäßig?
Mit der Kenntnis der Uhrzeit schau ich gegen XX:18 rein: Ohje, 100% CPU im SNMP Prozess. Wer ist das? Wo kommt das her? Sniffer an Ports der den üblichen Verdächtigen bringen keine Treffer. Also ein Drittsystem.
Umliegende Router und Firewalls bekommen nun ebenfalls einen Sniffer auf diese Art von Anfragen und siehe da: Ein bislang völlig unverdächtiges System generiert eine Unmenge an SNMP-v1 Anfragen, die den Router lahmlegen.
Der crontab dieses Systems offenbart eine Altlast:
0 0,2,4,6,8,10,12,14,16,18,20,22 * * * \ /var/local/nedi/nedi.pl -por > /var/local/nedi/nedi.lastrun 2>&1
Ohja. Das Zeitschema paßt wie die Faust aufs Auge.
Und was tut dieses Nedi? Es erkundet Netzwerke, ermittelt Nachbarschaften durch Analyse von CDP-, ARP-, MAC- und Routingtabellen, es versucht sich an noch unbekannten Systeme anzumelden und das Netz weiter und weiter zu erkunden.
In der Liste der manuell konfigurierten SNMP-Communities steht tatsächlich auch die Community dieses Routers. Also hat er ihn erfaßt.
Was da so lange dauert ist der Versuch, einem BGP Router die Full-Table per "snmpwalk -v 1" auszulesen. Das ist grandios ineffizient und verursacht eine unglaubliche Last auf dem Router, der immer wieder den Aufsetzpunkt in der Routingtabelle ermitteln muß, um genau einen nächsten Eintrag zu ermitteln.
Und wofür das Ganze? Für eine vergessene Testinstallation.