Angriffe auswerten: von Kontinent zu Kontinent

Eigentlich bin ich nicht der große Analyst und programmieren kann ich auch nicht. Aber ich halte mich für einen Menschen mit einer guten Beobachtungsgabe. Vielleicht liegt es auch an meinen Beruflichen Lebenslauf. Wenn ich dann regelmäßig einen Servercheck durchführe und die blacklist beobachte, erfasse ich – und denke jede Admina – relativ schnell, was sich da so anhäuft.

Hier zeige ich einen kleinen Auszug aus dem Log eines Webservers. In diesen Auszug kann sehr schön beobachtet werden, wie systematisch verschiedene Server-aliase abgeprüft werden. Das hier ein Script abspult und kein Mensch diese Anfragen händisch ausführt ist wohl selbst-redend. Beachte dazu den Zeitstempel.

Der Angreifer vermutet auf dem Webserver einen Ordner, in dem das Programm phpMyAdmin – ein Programm zur Datenbankverwaltung hinterlegt ist. Die verschiedenen Kombinationen des alias (sql, mysql) legen nahe, dass in solchen benannten Ordern, lt. Hacker erfahrungsgemäß, Webserver Admins einen Zugang zu diesen Programm bereitstellen – Also ein mögliches Tor zu einer Webserver Datenbank. Hurrah. Und weil der Hacker schon dabei ist, checkt er auch gleich auf SQLite Datenbanken und Verwaltungstools ab.

[13/Aug/2015:15:56:53 +0200] 188.165.237.12 TLSv1 DHE-RSA-AES128-SHA "GET /mysqldumper HTTP/1.1" 50458
[13/Aug/2015:15:57:28 +0200] 188.165.237.12 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 50458
[13/Aug/2015:15:57:45 +0200] 188.165.237.12 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 50458
[13/Aug/2015:15:58:23 +0200] 188.165.237.12 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 50458
[13/Aug/2015:15:58:40 +0200] 188.165.237.12 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 50458
[13/Aug/2015:16:00:12 +0200] 188.165.237.12 TLSv1 DHE-RSA-AES128-SHA "GET /sqlite/main.php HTTP/1.1" 50458
[13/Aug/2015:16:00:48 +0200] 188.165.237.12 TLSv1 DHE-RSA-AES128-SHA "GET /sqlitemanager/main.php HTTP/1.1" 50458
[17/Aug/2015:18:24:39 +0200] 5.196.213.36 TLSv1 DHE-RSA-AES128-SHA "GET /mysqldumper HTTP/1.1" 68358
[17/Aug/2015:18:25:34 +0200] 5.196.213.36 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68358
[17/Aug/2015:18:25:59 +0200] 5.196.213.36 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68358
[17/Aug/2015:18:27:26 +0200] 5.196.213.36 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68358
[17/Aug/2015:18:27:54 +0200] 5.196.213.36 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68358
[17/Aug/2015:18:30:31 +0200] 5.196.213.36 TLSv1 DHE-RSA-AES128-SHA "GET /sqlite/main.php HTTP/1.1" 68358
[17/Aug/2015:18:32:20 +0200] 5.196.213.36 TLSv1 DHE-RSA-AES128-SHA "GET /sqlitemanager/main.php HTTP/1.1" 68358
[17/Aug/2015:19:27:15 +0200] 37.187.77.142 TLSv1 DHE-RSA-AES128-SHA "GET /mysqldumper HTTP/1.1" 68358
[17/Aug/2015:19:27:19 +0200] 37.187.77.142 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68358
[17/Aug/2015:19:27:20 +0200] 37.187.77.142 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68358
[17/Aug/2015:19:27:22 +0200] 37.187.77.142 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68358
[17/Aug/2015:19:27:22 +0200] 37.187.77.142 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68358
[17/Aug/2015:19:27:25 +0200] 37.187.77.142 TLSv1 DHE-RSA-AES128-SHA "GET /sqlite/main.php HTTP/1.1" 68358
[17/Aug/2015:19:27:27 +0200] 37.187.77.142 TLSv1 DHE-RSA-AES128-SHA "GET /sqlitemanager/main.php HTTP/1.1" 68358
[18/Aug/2015:11:45:54 +0200] 158.85.157.57 TLSv1 DHE-RSA-AES128-SHA "GET /mysqldumper HTTP/1.1" 68358
[18/Aug/2015:11:45:57 +0200] 158.85.157.57 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68358
[18/Aug/2015:11:45:59 +0200] 158.85.157.57 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68358
[18/Aug/2015:11:46:03 +0200] 158.85.157.57 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68358
[18/Aug/2015:11:46:05 +0200] 158.85.157.57 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68358
[18/Aug/2015:11:46:12 +0200] 158.85.157.57 TLSv1 DHE-RSA-AES128-SHA "GET /sqlite/main.php HTTP/1.1" 68358
[18/Aug/2015:11:46:24 +0200] 158.85.157.57 TLSv1 DHE-RSA-AES128-SHA "GET /sqlitemanager/main.php HTTP/1.1" 68358
[21/Aug/2015:11:26:00 +0200] 198.12.153.239 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /mysql HTTP/1.1" 68350
[21/Aug/2015:11:26:24 +0200] 198.12.153.239 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sql HTTP/1.1" 68350
[21/Aug/2015:11:28:25 +0200] 198.12.153.239 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sqlitemanager/main.php HTTP/1.1" 68350
[22/Aug/2015:02:12:47 +0200] 5.135.233.109 TLSv1 DHE-RSA-AES128-SHA "GET /mysqldumper HTTP/1.1" 68350
[22/Aug/2015:02:12:50 +0200] 5.135.233.109 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68350
[22/Aug/2015:02:12:51 +0200] 5.135.233.109 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68350
[22/Aug/2015:02:12:56 +0200] 5.135.233.109 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68350
[22/Aug/2015:02:12:57 +0200] 5.135.233.109 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68350
[22/Aug/2015:02:13:05 +0200] 5.135.233.109 TLSv1 DHE-RSA-AES128-SHA "GET /sqlite/main.php HTTP/1.1" 68350
[22/Aug/2015:02:13:12 +0200] 5.135.233.109 TLSv1 DHE-RSA-AES128-SHA "GET /sqlitemanager/main.php HTTP/1.1" 68350
[22/Aug/2015:21:29:01 +0200] 167.114.115.19 TLSv1 DHE-RSA-AES128-SHA "GET /mysqldumper HTTP/1.1" 68350
[22/Aug/2015:21:29:05 +0200] 167.114.115.19 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68350
[22/Aug/2015:21:29:07 +0200] 167.114.115.19 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68350
[22/Aug/2015:21:29:12 +0200] 167.114.115.19 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68350
[22/Aug/2015:21:29:15 +0200] 167.114.115.19 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68350
[22/Aug/2015:21:29:24 +0200] 167.114.115.19 TLSv1 DHE-RSA-AES128-SHA "GET /sqlite/main.php HTTP/1.1" 68350
[22/Aug/2015:21:29:30 +0200] 167.114.115.19 TLSv1 DHE-RSA-AES128-SHA "GET /sqlitemanager/main.php HTTP/1.1" 68350
[23/Aug/2015:23:41:41 +0200] 178.32.255.140 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /mysql HTTP/1.1" 68724
[23/Aug/2015:23:41:42 +0200] 178.32.255.140 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sql HTTP/1.1" 68724
[23/Aug/2015:23:41:43 +0200] 178.32.255.140 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sqlite/main.php HTTP/1.1" 68724
[23/Aug/2015:23:41:44 +0200] 178.32.255.140 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sqlitemanager/main.php HTTP/1.1" 68724
[25/Aug/2015:21:43:18 +0200] 94.228.220.10 TLSv1 DHE-RSA-AES128-SHA "GET /mysqldumper HTTP/1.1" 68724
[25/Aug/2015:21:43:33 +0200] 94.228.220.10 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68724
[25/Aug/2015:21:43:39 +0200] 94.228.220.10 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68724
[25/Aug/2015:21:43:54 +0200] 94.228.220.10 TLSv1 DHE-RSA-AES128-SHA "GET /mysql HTTP/1.1" 68724
[25/Aug/2015:21:43:57 +0200] 94.228.220.10 TLSv1 DHE-RSA-AES128-SHA "GET /sql HTTP/1.1" 68724
[25/Aug/2015:21:44:10 +0200] 94.228.220.10 TLSv1 DHE-RSA-AES128-SHA "GET /sqlite/main.php HTTP/1.1" 68724
[25/Aug/2015:21:44:18 +0200] 94.228.220.10 TLSv1 DHE-RSA-AES128-SHA "GET /sqlitemanager/main.php HTTP/1.1" 68724
[27/Aug/2015:19:33:36 +0200] 149.202.52.176 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /mysqldumper HTTP/1.1" 68724
[27/Aug/2015:19:33:37 +0200] 149.202.52.176 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /mysql HTTP/1.1" 68724
[27/Aug/2015:19:33:37 +0200] 149.202.52.176 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sql HTTP/1.1" 68724
[27/Aug/2015:19:33:38 +0200] 149.202.52.176 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /mysql HTTP/1.1" 68724
[27/Aug/2015:19:33:38 +0200] 149.202.52.176 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sql HTTP/1.1" 68724
[27/Aug/2015:19:33:40 +0200] 149.202.52.176 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sqlite/main.php HTTP/1.1" 68724
[27/Aug/2015:19:33:41 +0200] 149.202.52.176 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /sqlitemanager/main.php HTTP/1.1" 68724

Warum der run auf Datenbanken? So verwunderlich ist das garnicht: Der Großteil aller Daten liegt heutzutage in einer Datenbank. Kann sich ein Angreifer Zugang zu einer Datenbank erobern, ist er sozusagen im Daten Paradies. Passwörter, Texte, Konten- Informationen, Steuerungen, Hintertüren, falsche Identitäten – alles ist dann machbar!

Das gezeigte Log ist natürlich keine große Überraschung für einen Admin, der regelmäßig einen Servercheck macht. Was ist aber mit diesen Werten noch zu beobachten?

Regionen der Welt

Viele Adminas kennen bestimmt die Seite utrace.de mit der, durch Eingabe einer IP-Adresse, der mutmaßliche geografische Standort des Angreifers abgefragt werden kann. Mutmaßlich deswegen, weil es IT-technisch möglich ist, IP-Adressen zu verschleiern, d.h. der wirkliche Standort kann ein ganz anderer Ort sein. Gehen wir davon aus, dass wir mit dem Log-Auszug auch den wirklichen Standort haben, sind die Regionen der Welt präsent:

IP-Adresse 149.202.52.176 aus dem obigen Log ist lt. utrace.de das Siemens Netzwerk in München (wobei ich es bedenklich finde, dass solche Aktionen aus einem Unternehmensnetzwerk gestartet werden können. Siemens Admin! Mach was! Und ich würde mich über ein feedback als Kommentar freuen, was es mit diesen Rechner auf sich hatte.)
5.135.233.109 und 37.187.77.142 ist ein Rechner von OHV Systems und steht scheinbar in Frankreich. Sehr weit scheint die Deutsch-Französische Freundschaft nicht zu gehen. Spass beiseite. Interessant ist hier, dass die Rechner aus dem OHV Netzwerk schon liebgewonnene Gäste sind. Wenn ich mich recht erinnere, sind blacklistet OHV Rechner plötzlich aus der Region Kanada ersetzt worden.
158.85.157.57 ist ein Rechner aus dem IBM Netz (lt. utrace.de). Auch hier wieder eine beunruhigende Feststellung, dass solche Scripte (und welche noch?) aus einen Unternehmensnetzwerk arbeiten. Diesmal Standort USA.
167.114.115.19 ist ein mexikanischer Vertreter dieser Gattung.
Interessant ist, dass in diesen Log-Auszug so gut wie keine IP-Adressen aus der Asiatischen Region sind. Dies ist auf eine blacklist zurück zu führen, die auffällige Subnetze aus dieser Region ausschließt. Als Admina könnte man meinen, eine Milliarde Chinesen haben den ganzen Tag nicht anderes zutun, als einen Server zu hacken.

Intervalle

Interessant ist immer, die Rythmik eines Angriffs zu beobachten und natürlich die Möglichkeiten der eigenen Filterprogramme zu berücksichtigen. Immerhin könnten Intervalle eines Angriffs so angelegt sein, dass sie nicht wirklich sinnvoll rauszufiltern sind. Folgender Log- Auszug zeigt einen solchen Spezi:

Sep 27 10:22:54 postfix/smtpd[25283]: connect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:54 postfix/smtpd[25283]: lost connection after AUTH from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:54 postfix/smtpd[25283]: disconnect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:56 postfix/smtpd[25283]: connect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:56 postfix/smtpd[25283]: lost connection after AUTH from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:56 postfix/smtpd[25283]: disconnect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:58 postfix/smtpd[25283]: connect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:58 postfix/smtpd[25283]: lost connection after AUTH from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:22:58 postfix/smtpd[25283]: disconnect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:26:18 postfix/anvil[25285]: statistics: max connection rate 3/60s for (smtp:74.208.72.7) at Sep 27 10:22:58
Sep 27 10:26:18 postfix/anvil[25285]: statistics: max connection count 1 for (smtp:74.208.72.7) at Sep 27 10:22:54
Sep 27 10:26:18 postfix/anvil[25285]: statistics: max cache size 1 at Sep 27 10:22:54
Sep 27 10:29:04 postfix/smtpd[25294]: connect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:04 postfix/smtpd[25294]: lost connection after AUTH from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:04 postfix/smtpd[25294]: disconnect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:05 postfix/smtpd[25294]: connect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:06 postfix/smtpd[25294]: lost connection after AUTH from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:06 postfix/smtpd[25294]: disconnect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:07 postfix/smtpd[25294]: connect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:08 postfix/smtpd[25294]: lost connection after AUTH from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:29:08 postfix/smtpd[25294]: disconnect from s15433861.onlinehome-server.com[74.208.72.7]
Sep 27 10:32:28 postfix/anvil[25296]: statistics: max connection rate 3/60s for (smtp:74.208.72.7) at Sep 27 10:29:07
Sep 27 10:32:28 postfix/anvil[25296]: statistics: max connection count 1 for (smtp:74.208.72.7) at Sep 27 10:29:04
Sep 27 10:32:28 postfix/anvil[25296]: statistics: max cache size 1 at Sep 27 10:29:04

Wahrscheinlich hält sich dieser ‘Hacker’ für sehr helle, weil er nur alle 3 Minuten 3 Versuche startet. Ich vermute mal, dass er diesen Intervall extra gewählt hat, weil dieser für Filterprogramme, wie z.B. fail2ban schwer greifbar ist. Immerhin können diese Nutzungsversuche einen gültigen Anwender treffen, der dann (vorschnell) gesperrt wird, weil er sein Passwort vergessen oder falsch eingegeben hatte. Hier noch ein Intervall – abwechselnd nach einer und jeder 3 Minute:

Nov 13 18:17:05 pilgermaske postfix/smtpd[12319]: lost connection after AUTH from unknown[193.189.117.150]
Nov 13 18:17:05 postfix/smtpd[12319]: disconnect from unknown[193.189.117.150]
Nov 13 18:20:25 postfix/anvil[12321]: statistics: max connection rate 1/60s for (smtp:193.189.117.150) at Nov 13 18:17:05
Nov 13 18:20:25 postfix/anvil[12321]: statistics: max connection count 1 for (smtp:193.189.117.150) at Nov 13 18:17:05
Nov 13 18:20:25 postfix/anvil[12321]: statistics: max cache size 1 at Nov 13 18:17:05
Nov 13 18:21:16 postfix/smtpd[13385]: connect from unknown[193.189.117.150]
Nov 13 18:21:16 postfix/smtpd[13385]: lost connection after AUTH from unknown[193.189.117.150]
Nov 13 18:21:16 postfix/smtpd[13385]: disconnect from unknown[193.189.117.150]
Nov 13 18:24:36 postfix/anvil[13389]: statistics: max connection rate 1/60s for (smtp:193.189.117.150) at Nov 13 18:21:16
Nov 13 18:24:36 postfix/anvil[13389]: statistics: max connection count 1 for (smtp:193.189.117.150) at Nov 13 18:21:16
Nov 13 18:24:36 postfix/anvil[13389]: statistics: max cache size 1 at Nov 13 18:21:16
Nov 13 18:25:24 postfix/smtpd[14507]: connect from unknown[193.189.117.150]
Nov 13 18:25:25 postfix/smtpd[14507]: lost connection after AUTH from unknown[193.189.117.150]
Nov 13 18:25:25 postfix/smtpd[14507]: disconnect from unknown[193.189.117.150]
Nov 13 18:28:45 postfix/anvil[14509]: statistics: max connection rate 1/60s for (smtp:193.189.117.150) at Nov 13 18:25:24
Nov 13 18:28:45 postfix/anvil[14509]: statistics: max connection count 1 for (smtp:193.189.117.150) at Nov 13 18:25:24
Nov 13 18:28:45 postfix/anvil[14509]: statistics: max cache size 1 at Nov 13 18:25:24
Nov 13 18:29:34 postfix/smtpd[15574]: connect from unknown[193.189.117.150]
Nov 13 18:29:34 postfix/smtpd[15574]: lost connection after AUTH from unknown[193.189.117.150]
Nov 13 18:29:34 postfix/smtpd[15574]: disconnect from unknown[193.189.117.150]
Nov 13 18:32:54 postfix/anvil[15594]: statistics: max connection rate 1/60s for (smtp:193.189.117.150) at Nov 13 18:29:34
Nov 13 18:32:54 postfix/anvil[15594]: statistics: max connection count 1 for (smtp:193.189.117.150) at Nov 13 18:29:34
Nov 13 18:32:54 postfix/anvil[15594]: statistics: max cache size 1 at Nov 13 18:29:34
Nov 13 18:33:37 postfix/smtpd[16619]: connect from unknown[193.189.117.150]
Nov 13 18:33:37 postfix/smtpd[16619]: lost connection after AUTH from unknown[193.189.117.150]
Nov 13 18:33:37 postfix/smtpd[16619]: disconnect from unknown[193.189.117.150]
Nov 13 18:36:57 postfix/anvil[16621]: statistics: max connection rate 1/60s for (smtp:193.189.117.150) at Nov 13 18:33:37
Nov 13 18:36:57 postfix/anvil[16621]: statistics: max connection count 1 for (smtp:193.189.117.150) at Nov 13 18:33:37
Nov 13 18:36:57 postfix/anvil[16621]: statistics: max cache size 1 at Nov 13 18:33:37
Nov 13 18:37:44 postfix/smtpd[17681]: connect from unknown[193.189.117.150]
Nov 13 18:37:44 postfix/smtpd[17681]: lost connection after AUTH from unknown[193.189.117.150]
Nov 13 18:37:44 postfix/smtpd[17681]: disconnect from unknown[193.189.117.150]

Die Frage ist eher, was diese Kinderei soll? Um einen DDOS Angriff (also eine Dienstblockade) einzuleiten, sind diese Angriffe zu wenig – um ein Passwort zu erraten ist die Frequenz zu niedrig. Lassen wir ihn spielen und fragen mal in ein paar Millionen Jahre nach, ob er das Passwort rausgefunden hat.

Was sind Probleme für Admins aus solchen Attacken?

Einfach blacklisten

Nunja, solche Rechner auf eine blacklist zu setzen ist kein großer Akt. Aber was kann dies für Auswirkungen haben?

Für ein Unternehmen, Privatmenschen oder Organisationen, die Verbindungen in die Asiatische Region pflegen müssen(!) ist ein blacklisting ihrer Korrespondenzpartner keine wirkliche Option. Gerade auch, weil sich gerade nicht(!), ein eindeutiges “böses” subnet herausbildet – dies wäre zu einfach.
Sitzen die Angreifer wirklich in dieser Region oder werden sie nur benutzt? Interessant wäre hier das Sicherheitsniveau z.B. chinesischer Rechner zu betrachten. Nach Statistiken die ich gelesen haben (Quellen nicht mehr auffindbar) ist das Betriebssystem Windows XP noch sehr viel weiter verbreitet, als in westlichen Regionen. D.h. aber auch, dass ein Sicherheitsniveau entsprechend niedrig sein kann und diese Rechner entsprechend als Script- Schleuder benutzt werden.
Angriffe aus den blacklisted Subnetzen verlagern sich in andere Subnetze. D.h. eine neue Analyse muss gestartet und eventuell Abwehrmaßnahmen angepasst werden.
Sowohl die Angriffe als auch die Verteidigungsmaßnahmen fressen Ressourcen, insoweit, dass sie z.B. Datenabfluss einleiten und damit Rechenpower abrufen oder Dienste überfordern, Manpower binden, die dieses unterbinden sollen.

Von Kontinent zu Kontinent

Meine Beobachtungen sind folgender Art. Nachdem ich die auffälligen Rechner in verschiedenen Subnetzen (/16, /24) blacklisted hatte, war zu beobachten, dass sich die Ausgangsbasis der Angriffe mit selben Inhalt/Ziel auf andere Kontinente verlagerte, um von dort ausgeführt zu werden.

Wenn ursprünglich China, Ukraine, und Frankreich die Hauptmasse der Angriffe stellte, kamen plötzlich verstärkt Angriffe aus Südamerika (Peru, Argentinien, Brasilien) und den USA, die im Log verzeichnet wurden. Es konnte eine eindeutige Verlagerung und Ausführung der gleichen Angriffe auf einen anderen Kontinent beobachtet werden. Interessant ist hier auch der Zeitraum. Diese Verlagerung ist nicht innerhalb von Wochen, sondern innerhalb von Tagen(!) zu beobachten.

Ein Beispiel? Gerade habe ich auf den submission port 587 alle 4 Minuten einen Zugriffsversuch im log beobachtet (tail -f -n 30 mail.log). Ich habe mir den Spass gemacht und gleich den Adressbereich des aktuellen Angreifers in der Firewall geblockt. Interessant war, dass, ohne Unterbrechung, die Adresse des Angreifers und quer über alle Kontinente wechselte. Die Handschrift blieb die gleiche. Die Adressen habe ich über utrace.de auf ihre geografische Zuordnung geprüft und durch diese Überprüfung kam in etwa folgende Wanderung heraus: Amerika, Ost- Europa, Nahost, Südamerika, Afrika, Indien, Südamerika – wo gehört Jakarta hin? Nach 10mal blocken, also ca. nach 40 Minuten, war dann 10 Minuten Pause und das Spiel begann wieder in Indien. So sensationell ist das natürlich nicht, aber eines wird wohl klar: Firewall Regeln, die nach Regionen filtern sind für die Katz’.

Admina kann sich gut eine IT-Zentrale vorstellen, in der ein böser Admin die Fehlermeldungen seiner scripte wg. blacklisting oder sonstigen Verteidigungstechniken auswertet und dann z.B. auf das Subnetz “Brasilien” umschaltet. Immerhin hat höchstwahrscheinlich jemand den bösen Admin Geld für eine gewisse Leistung gezahlt und Verträge müssen eingehalten werden. Spass beiseite, aber solche Aktionen machen keine Scriptkiddie‘s.

Interresant wäre es hier, mit einigen Scripten und Gigabyte an Logs, die weitergehende Systematik der Angreifer auszuwerten. Wird nach einen bestimmten System auf andere Kontinente umgeschaltet oder erfolgt eine zufällige Wahl? Vielleicht nach Alphabet: Argentinien, Brasilien, Canada, Deutschland, Espania, France, Griechenland – Spass beiseite! Was sind das für Angriffs- Rechner? Unterliegen die einen (regionalen/IP-technischen) Muster oder haben die nur alle die selbe Sicherheitslücke? Von welchen (selben) Rechner sind alle diese Angriffs-Rechner zuvor angesteuert worden oder haben die gleiche infektiöse Mail bekommen? Klar sollte sein: Solche Angriffe sind kein Zufall und haben ein Muster! Das ich mit solchen Fragen das Ei nicht neu erfinde ist mir klar – interessieren würde es mich trotzdem.

Hier nochmal ein anderer Log- Auszug, an dem, durch den Python Eintrag in der letzten Spalte, nochmal deutlich wird, dass hier ein script abläuft. Interessant ist auch, dass diesmal viele Adressen aus der deutschen Region dabei sind. Die Ferien sind eben vorbei. Spass beiseite:

50.63.172.12 - - [31/Aug/2015:18:14:47 +0200] "GET /mysql HTTP/1.1" 301 458 "-" "Python-urllib/2.6"
50.63.172.12 - - [31/Aug/2015:18:14:48 +0200] "GET /sql HTTP/1.1" 301 454 "-" "Python-urllib/2.6"
50.63.172.12 - - [31/Aug/2015:18:14:51 +0200] "GET /sqlite/main.php HTTP/1.1" 301 478 "-" "Python-urllib/2.6"
50.63.172.12 - - [31/Aug/2015:18:14:55 +0200] "GET /sqlitemanager/main.php HTTP/1.1" 301 492 "-" "Python-urllib/2.6"
37.58.105.19 - - [01/Sep/2015:06:00:47 +0200] "GET /mysqldumper HTTP/1.1" 301 470 "-" "Python-urllib/2.7"
37.58.105.19 - - [01/Sep/2015:06:00:48 +0200] "GET /mysql HTTP/1.1" 301 458 "-" "Python-urllib/2.7"
37.58.105.19 - - [01/Sep/2015:06:00:48 +0200] "GET /sql HTTP/1.1" 301 454 "-" "Python-urllib/2.7"
37.58.105.19 - - [01/Sep/2015:06:00:50 +0200] "GET /mysql HTTP/1.1" 301 458 "-" "Python-urllib/2.7"
37.58.105.19 - - [01/Sep/2015:06:00:50 +0200] "GET /sql HTTP/1.1" 301 454 "-" "Python-urllib/2.7"
37.58.105.19 - - [01/Sep/2015:06:00:52 +0200] "GET /sqlite/main.php HTTP/1.1" 301 478 "-" "Python-urllib/2.7"
37.58.105.19 - - [01/Sep/2015:06:00:54 +0200] "GET /sqlitemanager/main.php HTTP/1.1" 301 492 "-" "Python-urllib/2.7"
203.190.36.59 - - [01/Sep/2015:15:07:58 +0200] "GET //mysql/scripts/setup.php HTTP/1.1" 301 494 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:07:59 +0200] "GET //mysqladmin/scripts/setup.php HTTP/1.1" 301 504 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:08:09 +0200] "GET //websql/scripts/setup.php HTTP/1.1" 301 496 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:08:15 +0200] "GET //mysqladmin/ HTTP/1.1" 301 470 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:08:21 +0200] "GET //mysql/scripts/setup.php HTTP/1.1" 301 494 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:08:21 +0200] "GET //mysqladmin/scripts/setup.php HTTP/1.1" 301 504 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:08:32 +0200] "GET //websql/scripts/setup.php HTTP/1.1" 301 496 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:09:17 +0200] "GET //sqlmanager/scripts/setup.php HTTP/1.1" 301 504 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:09:18 +0200] "GET //mysqlmanager/scripts/setup.php HTTP/1.1" 301 508 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:09:23 +0200] "GET //sqlweb/scripts/setup.php HTTP/1.1" 301 496 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:09:24 +0200] "GET //websql/scripts/setup.php HTTP/1.1" 301 496 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:09:25 +0200] "GET //mysqladmin/scripts/setup.php HTTP/1.1" 301 504 "-" "-"
203.190.36.59 - - [01/Sep/2015:15:09:27 +0200] "GET //mysql-admin/scripts/setup.php HTTP/1.1" 301 506 "-" "-"
184.106.70.151 - - [01/Sep/2015:20:53:14 +0200] "GET /mysqldumper HTTP/1.1" 301 470 "-" "Python-urllib/2.6"
184.106.70.151 - - [01/Sep/2015:20:53:17 +0200] "GET /mysql HTTP/1.1" 301 458 "-" "Python-urllib/2.6"
184.106.70.151 - - [01/Sep/2015:20:53:18 +0200] "GET /sql HTTP/1.1" 301 454 "-" "Python-urllib/2.6"
184.106.70.151 - - [01/Sep/2015:20:53:22 +0200] "GET /mysql HTTP/1.1" 301 458 "-" "Python-urllib/2.6"
184.106.70.151 - - [01/Sep/2015:20:53:23 +0200] "GET /sql HTTP/1.1" 301 454 "-" "Python-urllib/2.6"
184.106.70.151 - - [01/Sep/2015:20:53:29 +0200] "GET /sqlite/main.php HTTP/1.1" 301 478 "-" "Python-urllib/2.6"
184.106.70.151 - - [01/Sep/2015:20:53:32 +0200] "GET /sqlitemanager/main.php HTTP/1.1" 301 492 "-" "Python-urllib/2.6"
94.228.220.10 - - [01/Sep/2015:22:52:58 +0200] "GET /mysqldumper HTTP/1.1" 301 470 "-" "Python-urllib/2.7"
94.228.220.10 - - [01/Sep/2015:22:53:14 +0200] "GET /mysql HTTP/1.1" 301 458 "-" "Python-urllib/2.7"
94.228.220.10 - - [01/Sep/2015:22:53:21 +0200] "GET /sql HTTP/1.1" 301 454 "-" "Python-urllib/2.7"
94.228.220.10 - - [01/Sep/2015:22:53:37 +0200] "GET /mysql HTTP/1.1" 301 458 "-" "Python-urllib/2.7"
94.228.220.10 - - [01/Sep/2015:22:53:41 +0200] "GET /sql HTTP/1.1" 301 454 "-" "Python-urllib/2.7"
94.228.220.10 - - [01/Sep/2015:22:53:56 +0200] "GET /sqlite/main.php HTTP/1.1" 301 478 "-" "Python-urllib/2.7"
94.228.220.10 - - [01/Sep/2015:22:54:03 +0200] "GET /sqlitemanager/main.php HTTP/1.1" 301 492 "-" "Python-urllib/2.7"

Erstmal sammeln

Natürlich sind solche Angriffe – und als solchen will ich solche Aktionen sehen! – kein Selbstzweck. Natürlich kann mit übernommenen Rechnern Geld gemacht oder anderen (Konkurrenten) geschadet werden – also muss so ein Angriff weitergehen als nur ports abzuklopfen.

Gerade heute habe ich ein schönes Beispiel auf einen Server gesehen:

[03/Apr/2016:07:20:40 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "GET /?author=1 HTTP/1.1" 54021
[03/Apr/2016:07:20:42 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "GET /?author=2 HTTP/1.1" 54021
[03/Apr/2016:07:20:44 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "GET /?author=3 HTTP/1.1" 54021
[03/Apr/2016:07:20:46 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "GET /?author=4 HTTP/1.1" 54021
[03/Apr/2016:07:20:48 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "GET /?author=5 HTTP/1.1" 54021
[03/Apr/2016:07:20:50 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "GET /?author=1 HTTP/1.1" 54021
[03/Apr/2016:07:20:51 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "POST /wp-login.php HTTP/1.1" 5854
[03/Apr/2016:07:20:53 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "POST /wp-login.php HTTP/1.1" 119
[03/Apr/2016:07:20:55 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "POST /wp-login.php HTTP/1.1" 119
[03/Apr/2016:07:20:55 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "POST /wp-login.php HTTP/1.1" 119
[03/Apr/2016:07:20:56 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "POST /wp-login.php HTTP/1.1" 119
[03/Apr/2016:07:20:57 +0200] 23.110.213.90 TLSv1 ECDHE-RSA-AES128-SHA "POST /wp-login.php HTTP/1.1" 119

In diesen log- Auszug sieht man, wie der Angreifer erstmal abcheckt, welche Autoren im WordPress blog schreiben. Dazu ruft er die angebotenen Autorenseiten (author=1 bis 5) auf, springt dann zurück auf author=1. Die URL des WordPress blogs zeigt auf diesen Seiten, den Anmeldenamen – also nicht den Anzeigenamen! – des Autors an.

Genau diesen Namen nutzt der Angreifer, um dann das wp-login.php script mit Anmeldeversuche zu nerven – in der Annahme, damit eine gültige Anmeldung am blog zu erreichen. Die Passwörter für die Anmeldeversuche bilden wahrscheinlich Passwortlisten oder Wörterbücher. Der Vermerk POST und GET in dem log Auszug, machen seine Aktionen (Infoabruf und Formulareingabe) nochmal deutlich.

Natürlich ist diese Aktion keine Seltenheit und begegnet uns stündlich in irgendwelchen logs. Allerdings soll es nochmal deutlich machen, wie wichtig die Verschleierung von Informationen ist!

Welche Info bekommt ein Angreifer allein durch den Besuch einer Webseite?

Er kennt IP-Adresse(n), mögliche Loginnamen, im Seitenquelltext sieht er (un-)genutzte Plugins und findet eventuell welche mit Sicherheitslücken oder Plugins, die weitere Infos (Server- Status Meldungen, Zähler, eingesetzte Verschlüsselungs- Algorithmen, usw.) über den Rechner ausgeben. Über eine Anfrage durch ein Kontaktformular bekommt er vielleicht als Antwort weitere Email Adressen, über die dann auf die Namenslogik des Rechnerbetreibers geschlossen werden kann. Weitere IP-Adressen von Rechnern die den angegriffenen Rechner betreuen, geben eine weitere Option um an Informationen heranzukommen. Manche Email Programme setzen im Header einer Email leider einen X-Originating Eintrag. Selbst (technische) Artikel in einen blog können dem Angreifer einen Hinweis auf die Konfiguration des hostenden Rechners geben. Besonders schön finde ich auch Bilder aus Rechenzentren, die sehr genau die Verkabelung einer Lokation im Internet ‘dokumentieren’. Männers, bitte!

Viele Infos sind im Betrieb eines Rechners ständig vorrätig und nicht immer zu verbergen. Allerdings sollte einem Rechner- Betreiber (egal ob Server oder Client!) immer klar sein, dass darüber Profile über ein mögliches Ziel zusammen gestellt werden können, die es dem Betreiber verdammt schwer machen, einen konzentrierten Angriff stand zuhalten.

Schwarmtechnik

Ein Beispiel? Nachdem mein Maillog zwei Tage groß war, versuchte ich eine Siebung. Die Annahme war bisher: Alle IP- Adressen von Angreifern sperren. Naja, naheliegend. Was aber, wenn sich die eigentlich bösen, die einen ständigen Angriff ausüben (also Passwort- Datenbanken quer durchtesten am login) und vielleicht sogar steuernde Funktionen haben, in einem Schwarm von billigen Angreifern verstecken? Irgendwelche billig befallenen PC’s, überall auf der Welt, die ohne große Bedenken vom Angreifer geopfert werden können und den Schwarm um die wirklichen Angreifer bilden? Kein (vernünftiger) Admin würde ALLE gelogten IP-Adressen blocken. Nach 10 Einträgen würden die meisten Adminas aufgeben. Die Wahrscheinlichkeit, dass die eigentlich bösen Angreifer – oder zumindest einer von diesen – bei so einer Vorgehensweise des Admins durchkommen, ist scheinbar relativ hoch.

Und so überflog ich das log und schrieb mir die IP- Adressen raus, die offensichtlich mehr als drei mal erschienen. Die Seite utrace.de sagte mir, von welchen Kontinent der Angreifer stammt. Wie immer von Allen. Ein less mail.log | grep 106.120. listete mir alle Einträge aus dem maillog, die 106.120. beinhalteten. Adressen mit 106.120. waren mir sofort in’s Auge gesprungen. Und prompt hatte ich kilometer-weise Anmeldeversuche von einer IP- Adresse die mit 106.120. begann. Letztlich fand ich vier Adressen, die überproportional oft im log erschienen, aber im Schwarm von Einmal-logins fast unsichtbar waren. Mit dem blocken dieser vier Adressen an der Firewall war erst ein mal Schluss mit Angriffen. Manchmal ist weniger eben mehr!

Alles blacklisten und verschlüsseln

Natürlich folgt jetzt die Frage jedes unbedarften Lesers: Lösung? Machen wir uns nichts vor: Eine endgültige Lösung ist nicht in Sicht! Mit dem Briefkasten kamen die Werbeblättchen, mit dem Telefon die Telefon- Umfragen und mit dem Internet die (bösen) Hacker – ich denke, der unberechtigte Zugang zu Daten ist eine Eigenheit der Internet- Technik, die nicht endgültig beseitigt werden kann. Alleine schon deswegen, weil Menschen damit Geld machen können.

Ein blacklisting dieser Rechner ist aber auf jeden Fall zu empfehlen. Immerhin werden diese Kameraden auch nach Erfolg bewertet und wenn es immer schwieriger wird, von ein paar Millionen Rechner noch einige Hunderttausend zu bekommen, sitzen einiger dieser Kameraden vielleicht auf einen ganz dünnen Ast.

Um diesen Ast noch schneller zu sägen, könnten wir auch einfach systematisch Verschlüsselung einsetzen. Jede Login Seite, jedes Passwort, jede Verbindung zum Server – eine Totale Verschlüsselung. Warum? Die Kosten. Einfach die Kosten für die Angreifer in die Höhe treiben. Sicherlich werden sie in der Lage sein – gerade die ‘staatlichen’ Stellen – die Verschlüsselungen zu knacken, aber sie brauchen dafür auch mehr Rechenpower. Also noch ein Rechenzentrum oder noch ein Bot- Netz, dass sie für Entschlüsselung abstellen müssen. Ach, menno! Die Kosten steigen.

Letztlich ist es natürlich eine Frage welche Motivationen hinter diesen Angriffen stehen: Bei politisch- motivierten Zugriffen kann es anders aussehen …

Aber interessant wäre es zu beobachten, welche Entwicklungen diese Angriffe gemacht haben und welche ‘Lehren’ daraus gezogen wurden: Standen zu Beginn im Wesentlichen “Spassviren” (proof-of-concept, Desktop ‘schmilzt’, ‘Fehlermeldung’ beim Hochfahren von Windows) und später, dass Abschalten/Defekten von Betriebssystemen oder Programmen (also eine Art Sabotage) im Vordergrund , steht in unserer aktuellen technischen Etappe eindeutig die Gewinnung von Informationen im Vordergrund! Natürlich ganz stark vereinfacht. Und diese Erkenntnis kann schon einen Handlungsrahmen auf verschiedenen Ebenen vorgeben:

Politisch: einen wirklichen Datenschutz etablieren, z.B. Sicherung der IT in Staatlichen Stellen, Einschränkung des Daten- Handels von Kommunalen Ämtern, freie Routerwahl und Verschlüsselung fördern, usw..
Technische Grundsätze überdenken: White statt Blacklisten. Alles ist Böse, nur die Guten kommen durch! Eine IT (-Sicherheit), die keine Daten sammelt, …
IT-Administrativ: Was hat phpMyAdmin auf einen Internet-angebundenen Webserver zu suchen? Ein Sicherheits- Konstrukt für Administratoren (Zertifizierungen, Betriebliche Standards), Forcierung einer Ablösung von Internet- Standards (http, smtp) die noch aus Zeiten stammen, in der IT- Sicherheit kein Thema war.
Kulturell: Unterrichtsfach Informatik als Pflichtfach! In Bildungseinrichtungen eine IT Offensive starten, mit einen eindeutigen Schwerpunkt auf IT- Sicherheit, z.B. in der Ausbildung des Fachinformatikers.

Und zum Schluss …

… das Ende. Aber um es nochmal Rund zu machen: Ich will mit diesen Beitrag nur eine kleine grundsätzliche Betrachtung anbieten, die eine notwendige Sicherheits- Diskussion unterstützt. Wenn Maschinen in Krankenhäuser und Wasserkraftwerke über das Internet abgeschaltet, Menschen anhand von Big Data aussortiert und durch den Zugriff auf Finanzdaten verschuldet werden, sehe ich gerade Administratoren in einer besonderen Verpflichtung sich solchen Fragen zu stellen. Immerhin reden wir hier nicht von einer Grippe, die wieder vergeht, sondern von einem Umfeld, dem sich ein Admin – vielleicht sogar beruflich – ständig stellen muss. Auch in der Verantwortung für andere Menschen.

Info: OWASP veröffentlicht Handbuch zum Schutz gegen automatisierte Angriffe

Autor: Mathias R. Ludwig

MCSE, MCITP, MCDBA, RHCT, CompTIA, ITILv3, AdA, VWA Ökonom, Dipl.SozArb., Kfz-Mechaniker, Panzer-Mechaniker/-Fahrer (HptGefr), Stanislaw Lem und Linux Fan, Feuerpferd.

Der Pilgermaske Blog