Bin ich angegriffen oder einfach nur dumm?

Ich betreibe einen Server mit Debian Squeeze mit mehreren OpenVZ-Containern. Die Container laufen hauptsächlich mit Squeeze, einige mit Lenny und einige bereits mit Wheezy. Der Host macht nicht viel mehr als iptables und DHCP. Dateiserver, Proxys, Mailserver, Kerberos, LDAP usw. werden in Containern abgelegt. Das System lief viele Jahre lang stabil und hatte bis auf einige Firewall-Regeln über ein Jahr lang keine wesentlichen Änderungen.

Vor 2 Tagen stürzte das System plötzlich ab. Ich hatte viele Probleme, es wieder aufzurufen. Zuerst würde es mich nicht über ssh einloggen lassen. Die Root-Anmeldung wurde abgelehnt durch 'Sie existieren nicht. Geh weg!' Lokale Anmeldung war in Ordnung. Einige Zeit später arbeitete ssh wieder. Zufällig habe ich die Zeile aus dem Bash-Verlauf nicht wiederverwendet, sondern einen neuen Befehl eingegeben, der dreifach überprüft wurde und mit der Zeile identisch war, die vorher nicht funktionierte, aber vor dem Absturz funktionierte.

Dann lief das System, aber der Netzwerkverkehr auf den meisten Protokollen wurde nach SYN ACK blockiert. DNS, Telnet und SSH waren in Ordnung, aber der Rest war ein Chaos. Nach ein paar Stunden Fischen im Dunkeln und mehrmaligem Nachladen der Firewall ging plötzlich alles wieder gut. Ich konnte in den Protokollen nichts Verdächtiges finden - aber ich bin kein forensischer Experte.

Heute hat der nscd des Dateiservers aufgrund des Containerkontingents keine Sockets mehr, um den LDAP zu kontaktieren. Etwas, das noch nie passiert ist. Ich habe auch viele (> 30) Steckdosen gesehen, die von smbd beansprucht wurden.

/ var / log / messages sah genauso aus wie syslog . /var/log/kern.log hatte diese zusätzlichen Informationen zu Absturzgründen:

/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.

Der endgültige Absturz von "sendmail" erfolgte nach dem Neustart des Computers. Seitdem sind solche Ereignisse nicht mehr aufgetreten. 'imapd' und 'postgres' laufen definitiv in verschiedenen Containern.

Nun, ich sehe keine rauchende Waffe, aber ich bin wahrscheinlich nur blind. Das Einrichten des Systems aus bekannten / vermuteten guten Backups würde mich zu sehr treffen, um es ohne sehr gute Gründe zu versuchen.

Ich würde mich über jeden Rat freuen, was als nächstes zu überprüfen ist.

Danke für Ihre Hilfe.

Update : Ich habe mehr Aufwand bei der Suche nach einem Vorläufer des Absturzes betrieben und im Syslog Folgendes gefunden:

Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)

Ich weiß, dass dies als unkritisch angesehen wird, aber es scheint ein seltenes Ereignis zu sein. Das Abschneiden von Paketen erfolgt nur am Tag des zweiten Absturzes. Nirgendwo sonst in allen verfügbaren Protokolldateien.

Dies sieht aus wie DoS, das höchstwahrscheinlich aus New York oder aus einem kompromittierten Container stammt.

Ich würde vmstat untersuchen, es kontinuierlich alle 5 Sekunden ausführen: vmstat 5 und notieren, wo Ressourcen ausgegeben werden. Sie können auch screen verwenden und vmstat 60 (jede Minute) in einem separaten Fenster ausführen. Auf diese Weise können Sie Spitzen feststellen, wenn sie über einen längeren Zeitraum auftreten.

In dieser Situation zeigen eine hohe / spitzende System-CPU (sy), eine hohe Kontext-Switch-Rate (cs) und eine hohe E / A (es werden sowohl Netzwerk als auch Festplatte angezeigt) DoS an:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   9584   6820 132432  23256    1    1   136    12    1    1 83  1 15  0  0
 0  0   9584   6696 132432  23256    0    0     0     0   20   32  0  0 99  0  1

Gleichzeitig den Netzwerkverkehr auf dem Host überwachen, empfehle ich ntop, dh:

$ nload -t 10000 -u H eth0

Es sieht aus wie ein Festplatten-E / A-Fehler. Führen Sie fsck aus und suchen Sie nach Fehlern.

Möglicherweise haben Sie keine Dateisystemfehler, aber ich bin sicher, dass Sie diese Warnungen in Ihrem Protokoll sehen, da sich viele Prozesse im Status D befinden (auf E / A warten) und der Kernel Sie über das lange Warten informiert.

Der Fehler zeigt an, dass Ihre Prozesse zu lange (120 Sekunden) auf den Zugriff auf Datenträger warten. Dies geschieht auf stark überfüllten Servern, auf denen die Festplatten zu ausgelastet sind, um auf Prozesse zu reagieren.

Sie können dies sicherstellen, indem Sie unter vmstat auf "Warten" klicken.