"bashd" Prozess mit über 100% CPU

[Yannici]

Hallo zusammen,

ich habe ein Problem mit meiner Debian Installation bzw. mit einem gewissen Dienst.
Habe auf meinem Server einen Prozess mit dem Namen "bashd". Dachte erst es sei ein Bash-Script das ausgeführt wird, aber
ich komme mit der Analyse nicht ganz weiter. Auch über Google finde ich mit dem Stichwort bashd leider nicht.

Meistens läuft das so ab: Wenn ich den Server neustarte und alle Dienste (Webserver, Mailserver, FTP etc.) hochgefahren sind funktioniert
auch alles so ca. 3-4 Tage. Erst nach diesen 3-4 Tagen kann es sein, dass ich auf eine Webseite zugreifen will und merke, dass diese nicht lädt.
Wenn ich es dann noch schaffe mich auf den Server zu verbinden (was bisher nicht immer geklappt hat), sehe ich mit dem top command einen Prozess mit o.g. Namen.
Der läuft fast andauernd auf über 100% (wie auch immer das gehen soll). Wenn ich den Prozess abschieße (kill), wird für einen Bruchteil von Sekunden die CPU wieder frei und ich kann z.B.
schnell ein Paket installieren o.ä. Dann startet aber der Prozess wieder mit einer neuen Prozess-ID und läuft wieder auf 100%.



Ich bin ziemlich am Ende. Habe mit strace versucht zu debuggen, leider kommt dann nur eine Ausgabe:

Code: Alles auswählen

getegid32( <...detached>

(Das detached logischerweise, weil ich dann mich wieder vom Prozess loslöse).

Komme nicht weiter und hoffe ihr könnt mir helfen.

MfG
Yannici

[DeletedUserReAsG]

Du könntest mit lsof schauen, was dieser Prozess so offen hat. Mit über 100% kann ein Prozess laufen, wenn er mehrere Threads hat.

OT: könntest du bitte auf Bilder zur Darstellung von Textausgaben verzichten?

[swirlen]

auf über 100% (wie auch immer das gehen soll).

1 kern 100%
2 kerne 200%
3 kerne 300%
etc pp

[Yannici]

Du könntest mit lsof schauen, was dieser Prozess so offen hat. Mit über 100% kann ein Prozess laufen, wenn er mehrere Threads hat.

OT: könntest du bitte auf Bilder zur Darstellung von Textausgaben verzichten?

Danke für die Antwort.
Ich habe lsof einmal ausgeführt. Leider bringt der nur folgende Ausgabe:

Code: Alles auswählen

COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF       NODE NAME
bashd   23229 root  cwd    DIR 146,105    12288  817765846 /usr/sbin
bashd   23229 root  rtd    DIR 146,105     4096  811081520 /
bashd   23229 root  txt    REG 146,105  2979640  817770118 /usr/sbin/bashd
bashd   23229 root    0r   CHR     1,3      0t0 3161968640 /dev/null
bashd   23229 root    1w   CHR     1,3      0t0 3161968640 /dev/null
bashd   23229 root    2w   CHR     1,3      0t0 3161968640 /dev/null

Das hilft mir aber auch nicht weiter.

1 kern 100%
2 kerne 200%
3 kerne 300%
etc pp

Das macht Sinn, danke ^^

Ich war nun auch mal so frech und hab die Datei "bashd" in /usr/sbin gelöscht. Das hilft nicht, denn die Datei wird einfach wieder erstellt?!

[DeletedUserReAsG]

Das hilft mir aber auch nicht weiter.

… immerhin weiß man jetzt, wo das Binary dazu ist. Ich würde das nun nicht als „nicht weiterhelfen“ bezeichnen.

Vorausgesetzt, du benutzt keine Fremdquellen und hast auch nix an der Paketverwaltung vorbeiinstalliert, würde ich annehmen, die Kiste wurde übernommen. Es gibt kein Paket mit dieser Datei in den offiziellen Repos.

[Yannici]

Ja du hast Recht.
Ich habe wohl irgendwo eine Sicherheitslücke. Habe sicherheitshalber auch alle Passwörter zu jedem möglichen User geändert.
Denn: Der bashd-Prozess nutzt die CPU zum Mining. Da hat wohl jemand es geschafft eine Shell einzuschleusen. Die habe ich auch gefunden. In der Shell wurde ein Cronjob angelegt zum immer wieder Starten des Prozesses und falls die Binary nicht existiert, wurde sie aus einem Git-Verzeichnis wieder heruntergeladen.

Ziemlich fies. Ich hoffe ich habe mit den Passwortänderungen das Einschleusen verhindert. Ansonsten muss ich evlt. mal meine Firewall-Einträge anschauen.
Hat sonst jemand eine Idee zur Sicherheit?

[DeletedUserReAsG]

Ich hoffe ich habe mit den Passwortänderungen das Einschleusen verhindert.

Aller Wahrscheinlichkeit nach nicht. Derjenige hatte Rootrechte auf deinem System – das ganze System ist als kompromittiert zu betrachten, und neu aufzusetzen. Mit den Rechten geht alles: vom Säubern der Logs bis zum Installieren und Verstecken (mindestens) einer Backdoor.

Ich würde dennoch ein Image des Systems ziehen, sofern ausreichend Platz vorhanden, oder zumindest die Logs sichern und mal gucken, ob da Anhaltspunkte auf den Einfallsweg zu finden sind. Mit etwas Glück war’s nur ein Scriptkiddy, das nicht mehr konnte als seine im Dunkelnetz erworbenen Toolz zu klicken und sich nicht weiter um die Logs gekümmert hat.

Wenn du nach Sicherheit fragst: zu allererst mal davon abgehen, Passwörter für den Login zu verwenden. Keys sind state of teh art. Aber meist ist das initiale Einfallstor irgend ’ne komplexere PHP-Software mit diversen Schwachstellen – hattest du da was laufen? Wordpress, Joomla, irgend’ne Shopsoftware, Webmin, Plesk, …?

[scientific]

Puh...

Ob du da wirklich alles entdeckt hast?

Hast du ein Fremdrepo? Hast du aus einer Fremdquelle ein Paket installiert?
Installier mal apt-file.
Dann

Code: Alles auswählen

 apt-file update

Und dann suche mit

Code: Alles auswählen

 apt-file search $CRONJOBNAME

ob der cronjob über ein Paket reingekommen ist.

Wenn ich ein solcherart kompromittietes System hätte, würd ich nach ein wenig Forensik das System auf jeden Fall neu aufsetzen!!

Lg scientific

[Yannici]

Wenn du nach Sicherheit fragst: zu allererst mal davon abgehen, Passwörter für den Login zu verwenden. Keys sind state of teh art. Aber meist ist das initiale Einfallstor irgend ’ne komplexere PHP-Software mit diversen Schwachstellen – hattest du da was laufen? Wordpress, Joomla, irgend’ne Shopsoftware, Webmin, Plesk, …?

Wordpress habe ich am laufen ja, aber auch selbstgeschriebene PHP-Software. Die meisten der Scripte liegen aber hinter einer passwortgeschützten .htaccess (+ .htpasswd).
Das Wordpress wiederrum ist aber frei sichtbar. Dachte Wordpress ist so etabliert, dass die Sicherheit da doch relativ gut ist?

Ich würde dennoch ein Image des Systems ziehen, sofern ausreichend Platz vorhanden, oder zumindest die Logs sichern und mal gucken, ob da Anhaltspunkte auf den Einfallsweg zu finden sind. Mit etwas Glück war’s nur ein Scriptkiddy, das nicht mehr konnte als seine im Dunkelnetz erworbenen Toolz zu klicken und sich nicht weiter um die Logs gekümmert hat.

Die Logs werden in dem gefundenen Shell ebenfalls geleert. Die Mining-Url die verwendet wurde ist eine Chinesische Mining-Webseite.

Hast du ein Fremdrepo? Hast du aus einer Fremdquelle ein Paket installiert?

Ja, z.B. Jenkins, NodeJS (2.2), dovecot, openjdk und passenger.

ob der cronjob über ein Paket reingekommen ist.

Habe ich gemacht, keine Datei gefunden zu dem Cronjob Namen.

Ich werde es evtl. nochmal 3-4 Tage weiterlaufen lassen und schauen, ob der Server wieder unter Beschuss gerät. Dann neu aufsetzen.
Achja, hier das Script das wahrscheinlich verwendet wurde. Jeden einzelnen Schritt habe ich zurückgebaut: https://raw.githubusercontent.com/mineb ... install.sh

[Tintom]

Dachte Wordpress ist so etabliert, dass die Sicherheit da doch relativ gut ist?

Etabliert != Sicherheit !

Ich werde es evtl. nochmal 3-4 Tage weiterlaufen lassen und schauen, ob der Server wieder unter Beschuss gerät. Dann neu aufsetzen.

Warum erst nach 3-4 Tagen? Du hast doch gesehen, dass dein System erfolgreich übernommen wurde und du keine Ahnung hast warum. So etwas ist grob fahrlässig!

[Lord_Carlos]

wurde sie aus einem Git-Verzeichnis wieder heruntergeladen.

Wenn es von GitHub oder aehnliches geladen wird, dann wuerde ich es da melden.

[Yannici]

Warum erst nach 3-4 Tagen? Du hast doch gesehen, dass dein System erfolgreich übernommen wurde und du keine Ahnung hast warum. So etwas ist grob fahrlässig!

Wenn das Problem wirklich Wordpress oder andere PHP-Software ist, dann macht es doch wenig Sinn den Server neu aufzusetzen und mit denselben Dingen
neu zu installieren oder? Da wäre doch der Zugriff dann doch wieder genauso möglich ...
Natürlich wäre ein Neuaufsetzen am Besten, aber es kostet Zeit und bedeutet Aufwand.

Wenn es von GitHub oder aehnliches geladen wird, dann wuerde ich es da melden.

Ja aus einem Github User-Repository. Mach ich.

Mein root-User Passwort war übrigens auch nicht das Gelbe vom Ei, möglich dass sich darüber Zugang verschafft wurde? Wie läuft so ein SSH-Login ab? Gibt es da eine eingebaute Maximale Grenze von Versuchen o.ä?

Edit:
Das auth.log besagt wohl eindeutiges: Der Angreifer hat mein root-Passwort geknackt mithilfe von tausenden SSH-Login-Versuchen. Und das von vielen verschiedenen Servern aus. Das aktualisierte (und vor allem von der Länge verdreifachtes) Passwort des root-Users sollte also evtl. solche Angriffe jedenfalls erschweren. Zudem habe ich fail2ban installiert, was mir bei 3 gescheiterten Login-Versuchen eine E-Mail sendet und den Angreifer sperrt.

[DeletedUserReAsG]

Wenn du’s nicht, entgegen aller Empfehlungen, geändert hast, ist der Root-Login via ssh verboten. Macht aber nichts, wenn der Angreifer sich über eine Webapplikation zunächst Zugriff mit den Rechten des httpd verschafft hat – von dort kann er in Ruhe probieren, dein Root-Passwort zu erraten. Oder eine lokale Schwachstelle ausnutzen, um letztlich UID0 zu bekommen. Deinem Nachtrag zufolge hast du den Root-Login erlaubt, und das auch noch via Passwort. Nun ja … „selbst schuld“ klingt etwas gemein, trifft aber in dem Fall den Kern der Sache. Kurz zum Mitmeißeln: der Root-Login via ssh sollte allenfalls, wenn überhaupt, mit Schlüssel möglich sein. Niemals mit Passwort.

[scientific]

@niemand wurdest du nicht unlängst von einem User hier massiv angefeindet, der als Servernovize den rootlogin per ssh mit passwort zulassen wollte?

Dem würd ich diesen Thread hier zeigen...

[Yannici]

Das ist vom Provider so standardmäßig eingestellt (Strato). Und als ich mit dem Betreiben des V-Servers begonnen habe war ich noch blutiger Anfänger was Linux bzw. Debian betrifft. Dass mal etwas passieren würde, weil ich ein Anfänger bin habe ich mir schon fast gedacht. Dass die Auswirkung ein Anfänger zu sein so krass sein kann habe ich etwas unterschätzt. Aber ohne die Erfahrung zu machen lernt man halt auch nicht dazu

Werde also als erste Maßnahme den Login abschalten und nur noch per Schlüssel authentifizieren lassen.

[Dogge]

Werde also als erste Maßnahme den Login abschalten und nur noch per Schlüssel authentifizieren lassen.

Wenn du sicher weißt, dass jemand Zugang hatte würde ich erst mal neu aufsetzen. Woher willst du nicht wissen welche Hintertüren der Angreifer schon alle geöffnet hat um wieder vorbeizukommen?

[Tintom]

Warum erst nach 3-4 Tagen? Du hast doch gesehen, dass dein System erfolgreich übernommen wurde und du keine Ahnung hast warum. So etwas ist grob fahrlässig!

Wenn das Problem wirklich Wordpress oder andere PHP-Software ist, dann macht es doch wenig Sinn den Server neu aufzusetzen und mit denselben Dingen
neu zu installieren oder? Da wäre doch der Zugriff dann doch wieder genauso möglich ...
Natürlich wäre ein Neuaufsetzen am Besten, aber es kostet Zeit und bedeutet Aufwand.

Die Frage ist: Kannst du alles exakt nachvollziehen was der Angreifer gemacht hat? Die Antwort ist nein. Somit kannst du nicht sicher sein, ob der Angreifer dir noch andere Schadsoftware untergeschoben hat, die du (noch) nicht entdeckt hast. Ich nehme an, dass du die AGB gelesen hast, bevor du den Server bestellt hast?

6.6 Der Kunde ist verpflichtet, seine Systeme und Programme so einzurichten, dass weder die Sicherheit, die Integrität, noch die Verfügbarkeit von Systemen, Netzen und Daten von STRATO oder Dritten beeinträchtigt werden.
[...]
6.11 Die Nutzung der STRATO Dienste zur Verbreitung von Schadprogrammen oder missbräuchlich agierenden Botnetzen, zur Versendung von Spam-Nachrichten oder für Phishing, für Marken- und Urheberrechtsverletzungen, bzw. -piraterie, betrügerische oder irreführende Praktiken, Produktfälschung oder sonstige Verhaltensweisen, die gegen anwendbares Recht verstoßen, ist untersagt.

Allein diese beiden Punkte kannst du mit einem kompromittierten System nicht mehr sicherstellen und haftest gegenüber dem Hoster und Dritten für daraus entstandenem Schaden.

Die einzig sinnvolle Reihenfolge ist das System vom Netz nehmen, ein Image für weitere Analysen ziehen (kannst du dir in diesem Fall sparen weil du die Lösung ja schon gefunden hast) und das System neu aufsetzen. Letzteres im im Zweifel immer günstiger als Haftungsansprüche Dritter durch eine SPAM/Porno/sonstwas-Schleuder!

[Yannici]

Ich werde den Server definitiv neu aufsetzen. Das mit den AGBs ist natürlich korrekt und ich will ja auch sicher gehen, dass mein Server wieder von fremden Zugriffen frei ist.
Wie ich sehe versucht der Angreifer auch jetzt noch mein neues Root Passwort zu "bruteforcen". Nachdem ich neu aufgesetzt habe kann ich das ja wiederrum verhindern indem
ich nur noch Logins per Schlüssel erlaube, korrekt?

Dann mach ich mich morgen da dran ...

[owl102]

Das ist vom Provider so standardmäßig eingestellt (Strato).

Natürlich ist es so voreingestellt. Wie hättest du ansonsten zur Ersteinrichtung auf den Server kommen sollen?

[Yannici]

Natürlich ist es so voreingestellt. Wie hättest du ansonsten zur Ersteinrichtung auf den Server kommen sollen?

Damals wie gesagt als blutiger Anfänger überhaupt keine Gedanken darüber gemacht.

[Tintom]

Wie ich sehe versucht der Angreifer auch jetzt noch mein neues Root Passwort zu "bruteforcen". Nachdem ich neu aufgesetzt habe kann ich das ja wiederrum verhindern indem
ich nur noch Logins per Schlüssel erlaube, korrekt?

Mal ganz simpel gefragt: Warum muss root sich überhaupt per ssh einloggen können? Gibt es dafür einen zwingenden Grund? Wenn nein, Root-Login per ssh deaktivieren.