14
Ist mein Linux Server mit dem Windigo Botnet infiziert?
Da das Windigo Botnet sein Unwesen treibt, wird es mal wieder Zeit seinen eigenen Linux-Server genauer zu überprüfen. Hier die einzelnen Schritte zum Testen des Servers:
Überprüfe als erstes, ob überhaupt ein SSH-Server installiert ist. Hat Dein Linux System keinen SSH-Daemon und auch keinen "ssh"-Befehl funktioniert das Testscript natürlich nicht. Dann starte die Überprüfung mit Punkt 4.
Der Test Nummer 3 sollte nicht auf einem System ausgeführt werden, der OpenSSH mit dem X.509-Patch von Roumen Petrov einsetzt. Dieser Patch fügt dem SSH-Daemon die Unterstützung für X.509-PKI-Zertifikate hinzu und enthält seit September 2013 eine -G Option. Normalerweise gibt es sonst die Option -G nicht (nur bei den infizierten Systemen meldet -G durch einen Fehler in der Programmierung einen Status). Daher direkt zum Punkt 4 gehen.
Gebe im angemeldeten Zustand folgenden Befehl ein:
laut Sicherheitsforschern bei Eset testen, ob der Server schon Teil des Windigo-Botnets ist.
Wenn "System infected" erscheint, sollte der Admin das Ergebnis natürlich validieren. Prüfe wie groß die Datei libkeyutils.so auf deinem System ist. Diese liegt normalerweise unter /usr/lib/ oder nur /lib/ und sollte unter 20 KB groß sein.
Man kann die Datei mit Hilfe des "locate"-Befehls im Linux-System finden:
Alternativ, wenn "locate" nicht installiert ist, funktioniert es auch mit dem "find" Befehl:
Bei mir erscheinen dann zwei Dateien (Ubuntu 12.04 LTS):
Die erste Datei "/lib/x86_64-linux-gnu/libkeyutils.so.1.4" ist nur ein Link auf "libkeyutils.so.1.4".
Mit dem dir Befehl kann man sich die Größe anzeigen lassen:
Die Datei ist bei mir 17 KB groß. Normalerweise ist die lib ca 10 bis 20 KB groß.
Ist die Datei aber um die 30 KB groß, seid ihr wahrscheinlich mit dem Windigo Bot infiziert.
Dabei wird im Shared Memory die Größe und das Vorhandensein des SSH-Daemon geprüft.
Als root anmelden und folgenden Befehl eingeben (versuche den größten Prozess mit dem User root zu finden):
Dann schaue für diesen Prozess nach, welcher Dienst den Shared Memory erzeugt hat.
Stimmt der Dienst mit dem sshd überein?
Verwendet der sshd-Dienst Shared Memory, ist größer als 3 MB und hat die Zugriffsrechten 666 dann ist der Server höchstwahrscheinlich mit dem Windigo Bot infiziert (Genauer: mit Linux/Ebury).
Weitere Infos zum Ebury-Rootkit findet ihr hier: BSI-Warnung: Zahlreiche deutsche Server mit Ebury-Rootkit infiziert.
Als Root in der Bash folgende Befehle eingeben:
Bei beiden Befehlen sollte ein: curl: (6) Couldn't resolve host 'myserver' erscheinen. Erfolgt aber statt dessen:
Dann könnt ihr davon ausgehen, das Euer System mit dem Linux/Cdorked infiziert ist.
Als Root in der Bash folgende Befehle eingeben:
Erscheint "System infected" kann man sich das mit lsof genauer anschauen:
Dann sollte man das System weiter prüfen:
Wenn kein "pgrep" installiert ist funktioniert auch folgendes:
Erscheint nichts, sieht es gut aus. Erscheint aber ein "/tmp/ " (mit Leerzeichen) dann ist Euer System höchstwahrscheinlich mit dem Perl/Calfbot infiziert.
Die Autoren der Windigo Studie kommen nur zu einem Ergebnis: "We advise for a full reinstall of the compromised server from verified sources" - auf gut deutsch: Setzt den Server komplett neu auf. Es gibt keinen anderen Weg.
Das Windigo Netzwerk besteht aus mehreren Infektionen und Bots: Linux/Ebury, Linux/Cdorked, Linux/Onimiki und Perl/Calfbot (der Mail Spambot). Die Angriffsstellen sind der SSH-Daemon, die Webserver Apache, Lighttpd, Nginx und der Linux Kernel. Es gab sogar infizierte Install-Images von einem Offiziellen CentOS Mirror. Bekannt wurde das Netzwerk zum ersten Mal im Jahre 2011 mit der erfolgreichen Infizierung der Linux-Kernel Seite kernel.org.
Hier findet ihr eine 68-seitige Studie (englisch, im PDF-Format), die den Windigo Bot und das Netzwerk dahinter im Detail beschreibt.
Viel Spaß beim Testen!
P.S. wir sind clean
Gruß
Frank
1) Läuft auf meinem Linux-System überhaupt Ist ein SSH-Daemon?
Überprüfe als erstes, ob überhaupt ein SSH-Server installiert ist. Hat Dein Linux System keinen SSH-Daemon und auch keinen "ssh"-Befehl funktioniert das Testscript natürlich nicht. Dann starte die Überprüfung mit Punkt 4.2) Ich habe eine SSH Version mit dem X.509-Patch von Roumen Petrov
Der Test Nummer 3 sollte nicht auf einem System ausgeführt werden, der OpenSSH mit dem X.509-Patch von Roumen Petrov einsetzt. Dieser Patch fügt dem SSH-Daemon die Unterstützung für X.509-PKI-Zertifikate hinzu und enthält seit September 2013 eine -G Option. Normalerweise gibt es sonst die Option -G nicht (nur bei den infizierten Systemen meldet -G durch einen Fehler in der Programmierung einen Status). Daher direkt zum Punkt 4 gehen.3) SSH-Server vorhanden und kein X.509-Patch - jetzt folgt der eigentliche Test:
Gebe im angemeldeten Zustand folgenden Befehl ein:ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"
4) libkeyutils.so überprüfen
Wenn "System infected" erscheint, sollte der Admin das Ergebnis natürlich validieren. Prüfe wie groß die Datei libkeyutils.so auf deinem System ist. Diese liegt normalerweise unter /usr/lib/ oder nur /lib/ und sollte unter 20 KB groß sein.Man kann die Datei mit Hilfe des "locate"-Befehls im Linux-System finden:
locate libkeyutils.so
find / -name libkeyutils.so* -ls
/lib/x86_64-linux-gnu/libkeyutils.so.1
/lib/x86_64-linux-gnu/libkeyutils.so.1.4
Mit dem dir Befehl kann man sich die Größe anzeigen lassen:
dir /lib/x86_64-linux-gnu/libkeyutils.so.1.4
-rw-r--r-- 1 root root 14360 Okt 17 2011 /lib/x86_64-linux-gnu/libkeyutils.so.1.4
Die Datei ist bei mir 17 KB groß. Normalerweise ist die lib ca 10 bis 20 KB groß.
Ist die Datei aber um die 30 KB groß, seid ihr wahrscheinlich mit dem Windigo Bot infiziert.
5) Shared Memory Inspection - eine Test für Linux/Ebury
Dabei wird im Shared Memory die Größe und das Vorhandensein des SSH-Daemon geprüft.Als root anmelden und folgenden Befehl eingeben (versuche den größten Prozess mit dem User root zu finden):
ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch
0x00000000 0 root 644 80 2
0x00000000 32769 root 644 16384 2
0x00000000 65538 root 644 280 2
0x000010e0 465272836 root 666 3282312 0
# ipcs -m -p
------ Shared Memory Creator/Last-op PIDs --------
shmid owner cpid lpid
0 root 4162 4183
32769 root 4162 4183
65538 root 4162 4183
465272836 root 15029 17377
# ps aux | grep <pid>
root 11531 0.0 0.0 103284 828 pts/0 S+ 16:40 0:00 grep 15029
root 15029 0.0 0.0 66300 1204 ? Ss Jan26 0:00 /usr/sbin/sshd
Weitere Infos zum Ebury-Rootkit findet ihr hier: BSI-Warnung: Zahlreiche deutsche Server mit Ebury-Rootkit infiziert.
6) Der Linux/Cdorked Test
Als Root in der Bash folgende Befehle eingeben:$ curl -i http://myserver/favicon.iso | grep "Location:"
oder nur
$ curl -i http://myserver/favicon.iso
Location: http://google.com/
7) Der Perl/Calfbot Test (der Spambot)
Als Root in der Bash folgende Befehle eingeben:flock --nb /tmp/... echo "System clean" || echo "System infected"
lsof /tmp/...
pgrep -x "crond" | xargs -I ‘{}’ ls -la "/proc/{}/exe"
ps -ef | grep crond | grep -v grep | awk '{print $2}'
8) Mein System ist infiziert - Was nun?
Die Autoren der Windigo Studie kommen nur zu einem Ergebnis: "We advise for a full reinstall of the compromised server from verified sources" - auf gut deutsch: Setzt den Server komplett neu auf. Es gibt keinen anderen Weg.9) Wie hat sich mein Server infiziert?
Das Windigo Netzwerk besteht aus mehreren Infektionen und Bots: Linux/Ebury, Linux/Cdorked, Linux/Onimiki und Perl/Calfbot (der Mail Spambot). Die Angriffsstellen sind der SSH-Daemon, die Webserver Apache, Lighttpd, Nginx und der Linux Kernel. Es gab sogar infizierte Install-Images von einem Offiziellen CentOS Mirror. Bekannt wurde das Netzwerk zum ersten Mal im Jahre 2011 mit der erfolgreichen Infizierung der Linux-Kernel Seite kernel.org.10) Weitere Informationen über das Windigo Netzwerk und seine Funktionsweise
Hier findet ihr eine 68-seitige Studie (englisch, im PDF-Format), die den Windigo Bot und das Netzwerk dahinter im Detail beschreibt.Viel Spaß beim Testen!
P.S. wir sind clean
Gruß
Frank
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 233200
Url: https://administrator.de/contentid/233200
Printed on: April 19, 2024 at 09:04 o'clock
14 Comments
Latest comment
2
Meiner nach einem 30sec Schock da der erste Test positiv war auch.
Ich gebe noch ein Plus da hier der Informationsgehalt der Meldung besser als bei den anderen Meldungen zum Thema ist.
Ich gebe noch ein Plus da hier der Informationsgehalt der Meldung besser als bei den anderen Meldungen zum Thema ist.
2
Zitat von @wiesi200:
Meiner nach einem 30sec Schock da der erste Test positiv war auch.
Ich gebe noch ein Plus da hier der Informationsgehalt der Meldung besser als bei den anderen Meldungen zum Thema ist.
Meiner nach einem 30sec Schock da der erste Test positiv war auch.
Ich gebe noch ein Plus da hier der Informationsgehalt der Meldung besser als bei den anderen Meldungen zum Thema ist.
Den Patch übersehen?
Abgesehen davon: Schocks (und aus den Latschen kippende Admins) helfen bei einem Befall am wenigsten
Zitat von @falscher-sperrstatus:
> Zitat von @wiesi200:
>
> Meiner nach einem 30sec Schock da der erste Test positiv war auch.
>
> Ich gebe noch ein Plus da hier der Informationsgehalt der Meldung besser als bei den anderen Meldungen zum Thema ist.
Den Patch übersehen?
Abgesehen davon: Schocks (und aus den Latschen kippende Admins) helfen bei einem Befall am wenigsten
> Zitat von @wiesi200:
>
> Meiner nach einem 30sec Schock da der erste Test positiv war auch.
>
> Ich gebe noch ein Plus da hier der Informationsgehalt der Meldung besser als bei den anderen Meldungen zum Thema ist.
Den Patch übersehen?
Abgesehen davon: Schocks (und aus den Latschen kippende Admins) helfen bei einem Befall am wenigsten
Nur einfach den Befehl blind in's Shell kopiert, ohne mir Gedanken zu machen das es bei mir den Befehl ssh nicht gibt.
Der SSH Server reagiert bei Centos auf sshd
Da ich von keinen SSH Zugriff auf unseren Router bzw. durch unseren Router lasse war ich schon etwas geschockt wo das herkommen mag.
Ich hab unseren Webserver direkt im Haus stehen, da reicht mir der zugriff vom internen Netz.
Hallo @wiesi200,
das Windigo Botnet ist recht komplex und sehr vielseitig. Ich habe mir gerade die 64-seitige Studie dazu angeschaut (siehe oben Punkt 8) und musste feststellen, dass man sich nicht nur über den SSH-Server damit infizieren kann. Die Kette der Möglichkeiten ist sehr lang (SSH-Daemon, die Webserver Apache, Lighttpd, Nginx und der Linux Kernel, CentOS Install Image von einem infizierten Mirror). Ich habe daher drei weitere Tests hinzugefügt (Punkt 5,6,7).
Ich empfehle jedem Linux Admin die oben genannten 5 Tests durchzuführen. Erst dann kann man wieder beruhigt schlafen. Nur weil man keinen SSH-Daemon auf dem Server installiert hat, heißt das leider noch nicht, dass man nicht infiziert ist.
P.S. Es ist übrigens das erste Mal das Linux Server in diesem Ausmaß (aktuell über 11.000 Server) infiziert wurden. Die Techniken dazu kommen teilweise aus der Windows-Welt (z.B. das modifizierte libkeyutils.so Modul). Wie auch immer, tilgen wir ihn aus der Linux-Welt!
Gruß
Frank
das Windigo Botnet ist recht komplex und sehr vielseitig. Ich habe mir gerade die 64-seitige Studie dazu angeschaut (siehe oben Punkt 8) und musste feststellen, dass man sich nicht nur über den SSH-Server damit infizieren kann. Die Kette der Möglichkeiten ist sehr lang (SSH-Daemon, die Webserver Apache, Lighttpd, Nginx und der Linux Kernel, CentOS Install Image von einem infizierten Mirror). Ich habe daher drei weitere Tests hinzugefügt (Punkt 5,6,7).
Ich empfehle jedem Linux Admin die oben genannten 5 Tests durchzuführen. Erst dann kann man wieder beruhigt schlafen. Nur weil man keinen SSH-Daemon auf dem Server installiert hat, heißt das leider noch nicht, dass man nicht infiziert ist.
P.S. Es ist übrigens das erste Mal das Linux Server in diesem Ausmaß (aktuell über 11.000 Server) infiziert wurden. Die Techniken dazu kommen teilweise aus der Windows-Welt (z.B. das modifizierte libkeyutils.so Modul). Wie auch immer, tilgen wir ihn aus der Linux-Welt!
Gruß
Frank
2
Kann jetzt gut schlafen
Danke
Danke
Moin,
Klasse Artikel
Bei Punkt 4) würde sich m.E. ein
besser machen, da das auch dann geht wenn locate nicht installiert ist. find ist wohl standard bei allen Distris.
lg,
Slainte
PS: auch hier alles sauber
Klasse Artikel
Bei Punkt 4) würde sich m.E. ein
find / -name libkeyutils.so* -lslg,
Slainte
PS: auch hier alles sauber
1
Hi!
Guter Artikel auch ein +1 von mir....Hier auch clean...Kunden werden turnusmässig mitgetestet...
Yes z.B. bei Arch ist das Paket per Default nicht installiert....
mrtux
Guter Artikel auch ein +1 von mir....Hier auch clean...Kunden werden turnusmässig mitgetestet...
Zitat von @SlainteMhath:
besser machen, da das auch dann geht wenn locate nicht installiert ist. find ist wohl standard bei allen Distris.
besser machen, da das auch dann geht wenn locate nicht installiert ist. find ist wohl standard bei allen Distris.
Yes z.B. bei Arch ist das Paket per Default nicht installiert....
mrtux
Hallo @SlainteMhath,
Ja, gute Idee. Ich bin halt von Ubuntu etwas verwöhnt
Ich habe es oben im Beitrag ergänzt.
Gruß
Frank
find / -name libkeyutils.so* -ls
Ja, gute Idee. Ich bin halt von Ubuntu etwas verwöhnt
Ich habe es oben im Beitrag ergänzt.
Gruß
Frank
2. Ich bin halt von Ubuntu etwas verwöhnt
Ubuntu? Ich dachte das Tutorial war für Server gedacht?*wegrenn*
Schönes WE
Slainte
2Zitat von @SlainteMhath:
> . Ich bin halt von Ubuntu etwas verwöhnt
Ubuntu? Ich dachte das Tutorial war für Server gedacht?
> . Ich bin halt von Ubuntu etwas verwöhnt
Ubuntu? Ich dachte das Tutorial war für Server gedacht?
man kann auch mit Ubuntu Server bauen. Muß halrt den ganzen Klickibunti-Quatsch weglassen. .
Aber eine Liste von Utilities, die ich immer gleich in ein linux system dazuinstalliere und dazu gehört u.a. slocate. von daher ist es unerheblich, ob die Distribution das per default installiert oder nicht.
lks
Hi!
Soweit ich mich noch erinnere ist bei der Ubuntu Server Variante gar kein - oder zumindest - nicht so viel Klickibunti dabei....
Naja der Admin scheut ja erstmal von Haus aus...lästige (schwitz Kurve gerade noch geschafft...) Arbeit. Lästig in sofern, dass manche Systools oftmals von Distribution zu Distribution wild in den Paketen umher gewürfelt werden und sogar manchmal im Laufe der Zeit verlagert werden. Gerade bei Rolling-Releases kann das schon mal vorkommen, dass die Tools mehrmals mit den Jahren auf (Paket-) Wanderschaft gehen. Auch bei Distributionen, bei denen krasse Schritte eher unüblich sind, kann sowas vorkommen. So wie sich die Debianer lange Zeit nicht auf ein neues Init einigen konnten. Momentan ist bei Debian glaub systemd der Favorit und bei Ubuntu ist es immer noch upstart, soweit ich es gerade noch in Erinnerung habe...Das kann sich aber auch mal ändern und dann ist fast immer Handarbeit beim Update angesagt...
mrtux
Zitat von @Lochkartenstanzer:
man kann auch mit Ubuntu Server bauen. Muß halrt den ganzen Klickibunti-Quatsch weglassen. .
man kann auch mit Ubuntu Server bauen. Muß halrt den ganzen Klickibunti-Quatsch weglassen. .
Soweit ich mich noch erinnere ist bei der Ubuntu Server Variante gar kein - oder zumindest - nicht so viel Klickibunti dabei....
daher ist es unerheblich, ob die Distribution das per default installiert oder nicht.
Naja der Admin scheut ja erstmal von Haus aus...lästige (schwitz Kurve gerade noch geschafft...) Arbeit. Lästig in sofern, dass manche Systools oftmals von Distribution zu Distribution wild in den Paketen umher gewürfelt werden und sogar manchmal im Laufe der Zeit verlagert werden. Gerade bei Rolling-Releases kann das schon mal vorkommen, dass die Tools mehrmals mit den Jahren auf (Paket-) Wanderschaft gehen. Auch bei Distributionen, bei denen krasse Schritte eher unüblich sind, kann sowas vorkommen. So wie sich die Debianer lange Zeit nicht auf ein neues Init einigen konnten. Momentan ist bei Debian glaub systemd der Favorit und bei Ubuntu ist es immer noch upstart, soweit ich es gerade noch in Erinnerung habe...Das kann sich aber auch mal ändern und dann ist fast immer Handarbeit beim Update angesagt...
mrtux
Hi,
wie @mrtux schon erwähnte, gibt es von Ubuntu eine Server-Version. Diese ist sehr gut, sehr einfach zu pflegen, sehr verbreitet und sie hat so rein gar nichts mit der Desktop Version zu tun -> daher kein Klickibunti-Quatsch! Alle Administrator.de Server laufen auf einer Ubuntu LTS Version.
Gruß
Frank
wie @mrtux schon erwähnte, gibt es von Ubuntu eine Server-Version. Diese ist sehr gut, sehr einfach zu pflegen, sehr verbreitet und sie hat so rein gar nichts mit der Desktop Version zu tun -> daher kein Klickibunti-Quatsch! Alle Administrator.de Server laufen auf einer Ubuntu LTS Version.
Gruß
Frank
Zitat von @Frank:
verbreitet und sie hat so rein gar nichts mit der Desktop Version zu tun -> daher kein Klickibunti-Quatsch! Alle
Administrator.de Server laufen auf einer Ubuntu LTS Version.
verbreitet und sie hat so rein gar nichts mit der Desktop Version zu tun -> daher kein Klickibunti-Quatsch! Alle
Administrator.de Server laufen auf einer Ubuntu LTS Version.
Ich habe schon "Server" mit dem Desktop gesehen. Deswegen mein Einwurf.
lks
PS. Ich selber habe auch diverse LTS im Servereinsatz. Demnächst werden wieder ein paar 10.04-er fällig zum Updaten, wenn die 14.04-er stabil genug sein sollten.
