web-dev-qa-db-fra.com

Existe-t-il un journal natif pour les commandes ssh sortantes?

Sur un serveur Ubuntu 16.04, mon fournisseur d’accès a averti que mon adresse IP avait été utilisée pour attaquer d’autres hôtes. Les éléments suivants sont joints:

May 23 22:42:07 shared02 sshd[23972]: Invalid user ircd from <my-ip>
May 23 22:42:07 shared02 sshd[23972]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<my-ip>
May 23 22:42:09 shared02 sshd[23972]: Failed password for invalid user ircd from <my-ip> port 54952 ssh2
May 23 22:42:09 shared02 sshd[23972]: Received disconnect from <my-ip> port 54952:11: Normal Shutdown, Thank you for playing [preauth]
May 23 22:42:09 shared02 sshd[23972]: Disconnected from <my-ip> port 54952 [preauth]

J'ai consulté le journal à l'adresse /var/log/auth.log et découvert qu'une attaque par dictionnaire était en cours depuis au moins 10 jours sur mon propre serveur, et qu'un mot de passe utilisateur faible avait été déchiffré à un moment donné.

Je suppose que le bot attaquant a utilisé cet accès pour attaquer d'autres cibles, c'est pourquoi j'ai reçu l'avertissement précédent. Cependant, je ne sais pas où cette activité aurait pu être enregistrée. Existe-t-il un fichier contenant ces informations de manière native dans les systèmes Ubuntu?

Aussi, comme question de bonus, j'ai remarqué que le bot essayait de se connecter en tant que root à partir de cet utilisateur, mais pour autant que je sache, il n'a pas essayé de lancer une commande Sudo, pourquoi ne l'aurait-il pas?

2
Angry Cub

En règle générale, non, il n'y a pas de journaux sur les événements sortants, car il est supposé que quelqu'un les a demandés.

En fonction de la connexion de votre attaquant et de la manière dont il a lancé son attaque, il peut y avoir des entrées dans divers fichiers d’historique (par exemple, ~/.bash_history), mais il n’y aura rien dans syslog si vous n’ajoutez pas de règles spécifiques pour le consigner. Si vous le souhaitez, vous pouvez configurer la journalisation des connexions sortantes, bien que certaines précautions soient prises pour ne consigner que ce que vous voulez faire. Un tel exemple est disponible sur le forum Fedora et exploite iptables.

En ce qui concerne votre question de connexion root. En règle générale, les attaquants se moquent bien d’obtenir un accès root. Ils veulent seulement qu'un autre serveur exécute leurs scripts d'attaque. root fait partie du dictionnaire utilisé pour les attaques d'utilisateurs, sauf dans les rares cas où un compte root est activé avec un mot de passe faible. De plus, rien ne garantit qu'un utilisateur est dans /etc/sudoers et vous perdez un temps précieux à tenter de voir si un utilisateur dispose d'un accès (inutile) Sudo.

0
Kaz Wolfe