Suis-je paranoïaque ?

Lorsque l'on s'intéresse à la sécurité informatique, on se demande toujours si l'on n'en fait pas un peu trop. Après tout je ne possède qu'un petit serveur personnel qui fait tourner quelques sites web et qui me sert à stocker des données diverses. Rien à voir avec les ordinateur du FBI, de la CIA ou de je ne sais quel super-ordinateur d'une compagnie pétrolière.

J'ai donc dans un premier temps estimé le risque réellement encouru par ma machine en étudiant le contenu des fichiers de log de l'authentification (/var/log/auth.log*). J'ai notamment recherché les messages de type Invalid user et Failed password qui concernent les tentatives d'intrusion par brute force :

$ grep "Invalid user" /var/log/auth.log*
...
/var/log/auth.log:Feb 19 09:21:06 persephone sshd[609]: Invalid user marine from 211.7.45.195
/var/log/auth.log:Feb 19 09:21:11 persephone sshd[611]: Invalid user marine from 211.7.45.195
/var/log/auth.log:Feb 19 09:21:15 persephone sshd[613]: Invalid user marine from 211.7.45.195
...
$ grep "Failed password" /var/log/auth.log*
...
/var/log/auth.log:Feb 19 09:21:08 persephone sshd[609]: Failed password for invalid user marine from 211.7.45.195 port 33591 ssh2
/var/log/auth.log:Feb 19 09:21:13 persephone sshd[611]: Failed password for invalid user marine from 211.7.45.195 port 34941 ssh2
/var/log/auth.log:Feb 19 09:21:17 persephone sshd[613]: Failed password for invalid user marine from 211.7.45.195 port 35827 ssh2
...

Et là j'ai un peu commencé à flipper ! 8 471 messages concernant une tentative de connexion avec un nom d'utilisateur invalide et 11 213 messages concernant une tentative de connexion avec un mauvais mot de passe, sur deux jours. J'ai développé un petit script python afin d'analyser ces tentatives d'intrusion.

Statistiques sur les noms d'utilisateur

En tout ce n'est pas moins de 3 158 noms d'utilisateurs différents qui ont été testé, dont moins d'1% correspondent à des noms d'utilisateurs existant réellement sur le système. Parmi les noms d'utilisateurs attaqués, on trouve les classiques Unix/Linux : root, postgresql, mysql, news, games, ...

Nombre d'attaques par nom d'utilisateurs (18 et 19 Fév. 2010)

Statistiques sur les dates

Sur deux jours il n'y a pas tellement d'intérêt à observer une évolution, et comme le montre le graphique ci-dessous, il n'y a pas tellement de période de la journée propice à une attaque.

Nombre d'attaques par horaire (18 et 19 Fév. 2010)

Statistiques sur les attaquants

Finalement, ce qui est assez surprenant, mais tant mieux pour moi, c'est que la liste des attaquants soit assez stable. Il s'agit certainement de script-kiddies des US, de Colombie, Chine...

IPNb. tentatives
173.1.4.1962416
18.239.6.72154
190.144.99.981901
222.247.37.1411642
67.23.14.188 1157
160.80.97.45789
212.174.28.15304
124.137.4.142292
88.191.74.61 173
202.140.41.206168
59.108.230.13066
202.98.244.2026
222.68.194.6921
86.34.201.3016
202.165.177.20316
202.108.77.13915
88.44.214.14215
81.7.171.4115
88.191.69.6011
203.150.104.1828
211.7.45.195 6
200.69.106.1471
80.13.112.501

Ce qui m'a surpris c'est que certaines venaient du très prestigieux MIT, du Centro di Calcolo e Documentazione de l'Universita' degli Studi di Roma "Tor Vergata" ou encore du réseau dédibox. Le nombre d'attaques étant important et l'origine identifiée, je me suis fendu d'un petit mail à destination des administrateurs. Pour tous les autres, une petite règle iptables permet de leur barrer la route :

$ sudo iptables -A INPUT -p tcp -s XXX.XXX.XXX.XXX --destination-port 22 -j DROP

Renforcer le point d'entrée : SSH

Toutes ces attaques ont été opérées sur mon serveur SSH. Autant dire qu'il s'agit du premier point à sécuriser.

La première chose à faire est d'aller renforcer un petit peu la sécurité côté serveur en modifiant quelques valeurs dans le /etc/ssh/sshd_config :

  • LoginGraceTime descendu à 30 secondes : au bout de 30 secondes si la connexion ne s'est pas concrétisée, le lien est rompu.
  • PermitRootLogin passé à no : l'utilisateur root ne peut pas se connecter par SSH, il s'agit du compte le plus attaqué (largement).
  • PermitEmptyPasswords passé à no : on ne sait jamais, un utilisateur suicidaire pourrait choisir de ne pas mettre de mot de passe !

Ensuite je me suis rendu compte que mon serveur SSH souffrait du problème de clés vulnérables (bug Debian). Il est possible d'identifier les clés vulnérables à l'aide de l'outil dédié :

$ sudo ssh-vulnkey -a

La clé RSA d'authentification de mon serveur (/etc/ssh/ssh_host_rsa_key.pub) étant vulnérable, je l'ai remplacée :

$ sudo ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
...

Voilà une première étape de sécurisation... mais il y aurait encore certainement à faire.