Sécurisez vos serveurs à peu de frais

Bonjour à tou(te)s,

J'ai récemment eu le déplaisir d'avoir à me pencher sur un problème de sécurité et peut être suis je resté un peu trop longtemps hors de l'actualité des attaques informatiques ces derniers temps mais j'ai été frappé, en vérifiant toutes mes machines, à quel point les attaques brut-force sur SSH sont à la mode.
Cela veut dire que si vous avez une machine avec un login facilement devinable (genre «admin» mais «toto» fait très bien l'affaire) et un mot de passe également devinable alors votre machine est en danger.

Point numéro 1 - Préférez SFTP à FTP
Cela vous permet d'éviter d'avoir des mots de passe en clair sur le réseau. Si vraiment vous devez utiliser FTP alors je vous conseille «vsftpd» (mais il en existe surement d'autres) qui permet de créer des comptes non attachés à un utilisateur Unix.

Point numéro 2 - On ne se logge jamais en Root via SSH
root est un utilisateur privilégié et dans la grande majorité des cas, cet utilisateur s'appelle ... «root». Ce login est donc déjà connu par les attaquants. Dans le fchier «/etc/ssh/sshd_config» changer le paramètre «PermitRootLogin» à «no» et vous voila en sécurité de ce coté là.

Point numéro 3 - Seul un utilisateur a le droit de faire SU
On ne le répètera jamais assez, «Root est là pour permettre aux utilisateurs de travailler», c'est à dire qu'à moins que permettre aux utilisateurs de travailler soit votre travail, alors ne travaillez pas en root (jamais, jamais, jamais). En général un seul utilisateur possède le droit de passer root. Pour cela, il suffit soit de l'ajouter dans le groupe root (mais je vous conseille de créer un groupe «admins») et de changer le fichier «/etc/pam.d/su» en rajoutant la ligne suivante (commentée sur Debian) :

auth       required   pam_wheel.so group=admins

C'est à dire que dans le pire des cas, si un assaillant arrive à pénétrer dans votre système et à obtenir le mot de passe root, il ne pourra pas s'en octroyer les droits avant d'avoir trouvé quel utilisateur est la clé (et donc re casser du mot de passe).

Point numéro 4 - Utilisez les mots de passe cachés (shadow password)
C'est maintenant un grand classique sur l'ensemble des distributions Unix mais ça mérite d'être rappelé. Si un vilain pénètre un compte non privilégié de votre machine son premier souci va être de s'octroyer des privilèges. Pour cela, il a au moins 4 possibilités
- utiliser une faille du noyau (pas évident si vous êtes à jour)
- utiliser une faille de la distribution (pas évident si vous utilisez une distri connue)
- utiliser une faille laissée par ... vous :o) du genre un sudo ou un setuid bit sur un script writeable... (sans garantie)
- casser le mot de passe root (ça peut être très long).

La plus facile est de casser le mot de passe root. Si le fichier contenant les hachages des mots de passe est lisible par tout le monde alors c'est très facile de le copier ailleurs et de prendre son temps pour casser le cryptage. Si le système de mots de passe caché est en place alors ils ne sont pas accessible par l'attaquant autrement qu'en passant par le système d'authentification local pour tenter de casser le mot de passe. Cela prend du temps et surtout c'est visible (100% du cpu ça ne devrait pas passer inaperçu).

Bien sûr, pour que tout cela soit efficace, il faut :

Point numéro 5 - choisissez des mots de passe difficiles
Vous ne pouvez rendre votre serveur invulnérable. En général toutes les techniques de sécurité visent à rendre la tâches des attaquants plus longue et plus compliquée afin de les décourager voire de les démasquer. Le point central de la sécurité de vos machines est le système d'authentification et celui ci repose sur des chaînes secrètes de caractères appelés «mots de passe» (je sais, c'est fou). Un bon mot de passe est donc un mot de passe non devinable, c'est à dire un mot de passe qui n'est pas dans un dictionnaire. Cela contraint nos attaquants à utiliser la méthode brutale pour casser les mots de passe : tout essayer. Du coup, la question est : Mais qu'est ce qui complique la vie des casseurs de mots de passe ?

- Utiliser des minuscules et des majuscules
- Utiliser des chiffres
- Utiliser des caractères non alphanumériques.

Si vous utilisez au moins 2 des 3 critères énumérés ci dessus alors vos mots de passes sont à peu près bons. Pour ceux qui (comme moi) manquent d'imagination dans l'élaboration de vos mots de passe, je vous conseille le très imaginatif logiciel «apg».
Petite note intéressante: vous pouvez stocker des mots de passes dans un fichier (base de données, autres utilisateurs du système) à condition que lire ce fichier ne soit pas plus le moyen le plus facile d'obtenir ces informations pour un attaquant. Je vous conseille pour cela, un fichier placé dans le répertoire root lisible que par celui ci et crypté à l'aide de Vim (howto) avec le mot de passe ... de root :o)

Point numéro 6 - Faites tourner SSH sur un autre port si vous le pouvez
Les machines en internes ne sont accédées que par vous (ou votre équipe) ? Les logciels qui utilisent SSH (sftp, scp etc) sont bien écrits et penvent se connecter sur un autre port ? Alors cette solution va vous éviter 99% des soucis. Pour cela, une seule adresse, le fichier «sshd_config».

Point numéro 7 - Bannissez les enquiquineurs
En fait, ce qui est rageant, c'est une fois que notre machine est hackée et qu'on l'autopsie c'est de se dire «si j'avais vu les logs au moment ou c'est arrivé, on en serait pas là». Oui mais on ne peut pas (veut pas) être loggé partout tout le temps sinon je change de métier. Donc ce qui serait bien, c'est un système qui dit «quelqu'un qui insiste trop vite ou trop longtemps a des intentions perfides». Cela existe bien évidemment, j'ai découvert au détour d'un blog l'outil «denyhosts». Un simple «apt-get install denyhosts»  et vous voila à l'abri des script kiddies.

Point numéro 8 - Conclusion : une machine en sécurité est une machine éteinte
Tout ça pour dire que la sécurité parfaite n'existe pas car plus un système est sécurisé moins il offre de liberté à ses utilisateurs légitimes. Il convient donc de trouver le «juste milieu» de sécurité à appliquer en fonction de la criciticité de ce qui se trouve sur vos serveurs. Les astuces simples présentées ici contribueront, j'espère, à les protéger à peu de frais.