Ich finde meinen Server immer mit einer CPU-Auslastung von 100 % und es handelt sich um einen Prozess mit einem mehrdeutigen Namen, der irgendwo im Ordner /etc/ versteckt ist und unter root ausgeführt wird (immer ein anderer Ordner). Als ich ihn das erste Mal fand, suchte ich nach ihm und bestätigte, dass es sich um einen Miner handelte, beendete den Prozess kill -9 PID
und löschte den Ordner. Aber ich fand ihn noch zweimal und beschloss, ihn erneut zu entfernen, aber auch die Passwörter für das Konto zu ändern, das ich für den SSH-Zugriff auf den Server verwende, und auch für root, aber ich fand ihn gerade wieder.
Gibt es eine Möglichkeit, herauszufinden, wie ein Ordner dorthin gelangt ist? Auf meinem Server muss es doch noch etwas geben, das regelmäßig nach diesen Dateien sucht und sie, wenn es sie nicht findet, erneut herunterlädt oder extrahiert.
Der Miner schickte Datenverkehr an die folgende Adresse: ip162.ip-5-135-85.eu, die zuhttps://aeon.miner.rocks/
Antwort1
Erwägen Sie eine Neuinstallation des Servers.
Überprüfen Sie die folgenden Orte:
crontab -l
nach der Verwendungsudo -su
crontab -l
mit Ihrem Administrator-Benutzer- Inhalt von
/etc/rc.local
und/etc/apt/sources.list
die Verzeichnisse
/etc/systemd/system /usr/lib/systemd/system /lib/systemd/system
für Dienste, die Sie nicht kennen.
Das werden die Hauptschuldigen sein.
aeon-stak-cpuzheck /bin/
für ein aeon-stak-cpu
.
Machen Sie ein locate aeon
. Dadurch werden möglicherweise weitere Verzeichnisse geöffnet.
Ich kann jedoch keine Schadsoftware finden. Aeon wird über die Befehlszeile installiert, daher gehe ich davon aus, dass jemand eine Verbindung zu Ihrem Computer hat.
Antwort2
So, ich bin der Sache endlich auf den Grund gegangen.
Zunächst hatte ich nginx als Root laufen, was wahrscheinlich der ursprüngliche Einstiegspunkt war. Clamscan hatte eine Datei namens info.php gefunden und markiert, die in /var/www versteckt war, was wahrscheinlich der Grund war, warum sie sich zunächst Zugriff verschafft hatten.
Ich habe immer wieder SSH-Prozesse für root@notty gesehen, obwohl ich zunächst nicht wusste, was notty bedeutet, und als ich mir netstat ansah, war es definitiv keine meiner Sitzungen. Aber ich habe die Passwörter in völlig zufällige geändert, also konnte es nicht sein, dass sie die Passwörter kannten. Ich habe mir alle /home/[user]/.ssh-Ordner meiner Benutzer angesehen und denselben SSH-Schlüssel in der Datei authorized_keys gefunden.
Ich habe den Schlüssel entfernt und auch den Benutzer für Nginx geändert und hatte seitdem keine Probleme mehr.