Botnet
Diesen Beitrag schrieb ich 12 Jahre und 6 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Mich traf fast der Schlag, als ich von meinem Provider eine E-Mail erhielt: ich solle Stellung nehmen zu dem Angriff, der von meinem Server aus am Vortag erfolgte.
Direction OUT
Internal a.b.c.d
Threshold PacketsDiff 10.000 packets/s, Diff: 106.526 packets/s
Sum 31.958.000 packets/300s (106.526 packets/s), 5 flows/300s (0 flows/s),
2,322 GByte/300s (63 MBit/s)
External z.y.x.w, 31.958.000 packets/300s (106.526 packets/s), 5 flows/300s (0 flows/s),
2,322 GByte/300s (63 MBit/s)
Uff! Und mein munin-Graph bestätigte es – eine halbe Stunde lang hatte die Maschine mit voller Bandbreite ihr Ziel angegriffen. Doch wie? Wie konnte das sein? Ich begann die Maschine zu durchforsten… Als erstes überprüfte ich – Ehrensache – die eingeloggten User. Doch außer mir ist niemand in Sicht. Dann prüfe ich mit lastlog, wer sich überhaupt so auf dem System rumtummelt, das erzeugt eine Ausgabe wie diese hier:
...
ftp **Never logged in**
ntpd **Never logged in**
localwurst pts/0 p4fc33251.dip.t- Fri Mar 1 11:32:58 +0100 2012
...
So erhielt ich die Bestätigung dafür, dass sich außer den erlaubten Usern nie jemand auf dem System eingeloggt hatte, und auch last bestätigte mir das. Ich durchforstete die Logfiles, konnte jedoch nichts Auffälliges feststellen. Ich überlegte, was sich geändert haben könnte, doch mir fiel nichts ein. Ich suchte nach Auffälligkeiten, doch ich fand nichts, und fast hätte ich – unter anderem aufgrund der fortgeschrittenen Uhrzeit und nöligem Rumpelstilzchen – aufgegeben. Doch nachdem ich das Rumpelstilzchen erfolgreich ins Bett verfrachtet hatte, kam mir die Idee. So schaute ich mir genauer an, was sich so an ssh-Prozessen auf dem Sytsem befand (der Übersichtlichkeit halber hab ich mal die unnötigen Angaben entfernt):
root@ux:/root# ps auxf|grep ssh
root 2267 Mar01 0:00 /usr/sbin/sshd -D
root 24294 11:32 0:00 \_ sshd: spiller [priv]
spiller 24320 11:32 0:00 \_ sshd: spiller@pts/0
root 29753 12:15 0:00 \_ grep ssh
www-data 24156 Feb19 0:00 sshd:
Ein ssh-Prozess, von User www-data initiiert? Das kam mir nun doch verdächtig vor. Also schaute ich mir den mit lsof (list open files und dann ein grep auf die Prozess-ID dieses sshd:-Prozesses) genauer an (auch hier entferne ich mal die an dieser Stelle nicht so relevanten Angaben wie TYPE und DEVICE):
root@ux:/var/log# lsof | grep 24156
24156 ? 00:00:00 sshd:
sshd: 24156 www-data cwd /var/www/EinOrdner/.m
sshd: 24156 www-data rtd /
sshd: 24156 www-data txt /var/www/EinOrdner/.m/sshd:
sshd: 24156 www-data mem /lib32/libresolv-2.13.so
sshd: 24156 www-data mem /lib32/libnss_dns-2.13.so
sshd: 24156 www-data mem /lib32/libc-2.13.so
sshd: 24156 www-data mem /lib32/libnss_files-2.13.so
sshd: 24156 www-data mem /lib/i386-linux-gnu/ld-2.13.so
sshd: 24156 www-data 0u TCP ux:36458->quakenet.xs4all.nl:ircd (ESTABLISHED)
sshd: 24156 www-data 3u UDP *:34001
Es war also in /var/www/EinOrdner ein Unterordner namens .m angelegt worden – und in diesem steckte der Scheiß! Der sshd:-Prozess war in Wirklichkeit ein Stück IRC, das sich mit dem Quakenet verbunden hatte und auf Kommandos wartete. Verdammt! In dem Ordner fand sich unter anderem auch eine Datei namens cron.d, und die machte genau das, was man von ihr erwartete:
* * * * * /var/www/EinOrdner/.m/update >/dev/null 2>&1
Es wurde also ständig überprüft, ob der Prozess noch lief und, wenn nicht, wurde er klammheimlich neu gestartet. Einmal erkannt war es natürlich nicht so schwer, die Daten aus dem System zu werfen, den Cron-Job zu löschen – doch die bange Frage blieb doch: wie war der Dreck aufs System gelangt? Und auch das klärte sich mit Sichtung der diversen Logfiles:
PHP Warning: Unterminated comment starting line 3 in
/var/www/phpldapadmin-1.2.0.5/lib/functions.php(1060) : runtime-created
function on line 3
Ein zu alter PHPLdapAdmin diente als Einfallstor – zu bemerken ist, dass der User www-data am System herumfummelte, doch als Nerver logged in. geführt wurde. Er versuchte auch, sich zu root zu machen, was jedoch nicht gelang:
pam_unix(su:auth): authentication failure; logname= uid=33
euid=0 tty=/dev/pts/0 ruser=www-data rhost= user=root
FAILED su for root by www-data
- /dev/pts/0 www-data:root
Doch in anderen Fällen gelingt auch das – und dann werden ganz dreist neue Systemuser mit eigenen Homes angelegt, und aus diesen Homes heraus die Clients gestartet! Vorsicht ist also geboten bei Prozessen, die hohe Ports belegen – wenn man nicht weiß, worum es sich dabei handelt, sollte man es eingehend überprüfen. Interessant ist in diesem Zusammenhang übrigens noch, dass weder chkrootkit noch rkhunter angeschlagen haben – was sie meines Erachtens zumindest im Sinne von suspicious files ruhig hätten tun können ;-) Aber nunja. Wieder was dazugelernt.
Was also kann man tun? Ich für meinen Teil habe damit begonnen, die Möglichkeiten von fail2ban besser auszuschöpfen. Mit cron.allow bzw. cron.deny kann man verhindern, dass obskure User Cronjobs aufsetzen. Natürlich sollte jegliche Software auf dem neuesten Stand sein – WordPress, Webmailer… und natürlich jegliche Art von PHP-Admin-Panels. Und, so das Rumpelstilzchen mir Zeit dazu lässt, wieder öfter mal Logfiles lesen, einfach nur so – dabei entdecke ich immer wieder was Interessantes.
Update: wie ich inzwischen gelesen habe, können auch korrupte Wordpress-Plugins diese Dinge heraufbeschwören; neben regelmäßigem Update des WordPress-Kerns sollte man sich also gut überlegen, welche Plugins wirklich benötigt sind – ich hab jetzt erstmal eine ganze Reihe rausgeschmissen. Der Inhalt des .m-Ordners gestaltet sich übrigens wie folgt:
-rwx--x--x 1 user group 174 Feb 27 02:00 1
-rwxr-xr-x 1 user group 323 Jan 13 2011 autorun
-rw-r--r-- 1 user group 1198 Feb 27 02:50 cat.seen
-rw-r--r-- 1 user group 137 Feb 26 18:17 cron.d
-rw-r--r-- 1 user group 104 Feb 26 18:17 mech.dir
-rw-r--r-- 1 user group 1064 Feb 27 02:00 mech.levels
-rw------- 1 user group 6 Feb 26 18:17 mech.pid
-rw-r--r-- 1 user group 320 Feb 27 02:00 mech.session
-rwx--x--x 1 user group 531 Jan 12 2011 mech.set
-rwxr-xr-x 1 user group 27 Jan 12 2011 run
-rwx--x--x 1 user group 152108 Jan 12 2011 sshd:
-rwxr-xr-x 1 user group 17 Nov 5 2008 start
-rwx--x--x 1 user group 15195 Sep 2 2004 std
-rwxr--r-- 1 user group 445 Feb 26 18:17 update
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten