Compromission de système Linux

Le brute force

Il suffit que vous ouvriez le port TCP SSH (c'est vrai aussi pour des produits bien connus comme phpmyadmin) sur une machine pour l'administrer à distance pour que cela attire comme des abeilles sur du miel, plein de méchants pirates pas gentils. C'est facilement repérable en analysant le journal des connexions sur votre machine :

# tail /var/log/auth.log
...
Aug 31 03:48:07 serveur sshd[16687]: Invalid user root from 80.190.246.181
Aug 31 03:48:08 serveur sshd[16690]: Invalid user root2 from 80.190.246.181
Aug 31 03:48:09 serveur sshd[16698]: Invalid user admin from 80.190.246.181
Aug 31 03:48:09 serveur sshd[16699]: Invalid user user from 80.190.246.181
...

Explication : le pirate, après avoir fait un scan de ports sur les adresses ip correspondant à vos machines, tente ensuite un "brute force", il essaie grâce à une moulinette et un dictionnaire de logins et de mots de passe, de voir si une connexion est possible.

Compromission

Si SSH et/ou vos comptes Unix sont mal configurés, un utilisateur mal intentioné peut en profiter. Cela nous est arrivé, heureusement sur une machine de test hébergée pour une société extérieure. La connexion s'est faite sur un compte non privilégié et la machine a elle-même été utilisée pour réaliser des brutes forces sur d'autres machines, puisque ces grands courageux n'agissent jamais en direct, il seraient trop rapidement repérés.

Barbut_dw

Le répertoire /tmp a été utilisé pour y déposer une joyeuseté du nom de barbut_dw, un cheval de Troie du type Trojan/IRC bot  :

# ls -l /tmp/barbut_dw
-rwxr-xr-x  1 www-data           wheel  44424  2 Jul 19:26 barbut_dw

# file /tmp/barbut_dw
barbut_dw: Mach-O executable ppc

# lsof -p (mettre le PID de l'outil)
COMMAND     PID  USER   FD   TYPE    DEVICE  SIZE/OFF     NODE NAME
barbut_dw 36240 www-data  cwd    DIR      14,1       850  7564395 / private/tmp
barbut_dw 36240 www-data  txt    REG      14,1     44424 22050945 / private/tmp/barbut_dw

Analyse

Afin de pouvoir analyser le problème et en tirer l'expérience nécessaire, si cela est possible, il convient de déconnecter le serveur du réseau et s'y logger en console afin de faire le point (éviter de redémarrer la machine car en général, le répertoire /tmp est purgé !) :
1. utiliser la commande w pour voir qui est conncté actuellement
2. analyser /var/log/auth.log
3. analyser le résultat de la commande lastlog
4. bloquer le/les compte(s) incriminé(s) dans les fichiers /etc/passwd et /etc/shadow
5. utiliser des outils de détection :
http://www.chkrootkit.org
http://www.rootkit.nl/projects/rootkit_hunter.html

Ensuite, il est vivement conseillé de reformater la machine.

Conclusion

Notre bilan a été que le serveur SSH (Openssh) de cette machine de test avait été laissé avec la configuration par défaut, ce qui n'est pas une bonne chose du tout. Un prochain billet concernera la configuration à appliquer sur Openssh pour une meilleure sécurité.