Quelques bonnes pratiques de sécurisation d’un serveur Linux, partie 1

closeCet article a été publié il y a 9 ans 3 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Le billet d’aujourd’hui sert à la fois aux nouveaux arrivants dans le domaine de l’administration de serveur Linux et aux routiers qui chercheraient un pense-bête. En effet, rien de tel qu’un petit oubli pour rendre sa machine open-bar, et pourtant, il n’y a rien de très compliqué à faire la plupart du temps.

Attention : toutes les manipulations présentées n’ont été testées que sous Debian, il sera peut-être nécessaire d’adapter plus ou moins légèrement pour votre distribution favorite.

Le serveur SSH

S’il est un composant important dans un serveur, c’est le logiciel qui nous permet d’y accéder à distance. Le serveur qui héberge ce blog ne fait pas exception. Mais le paramétrage de base est vraiment, vraiment peu sécurisé. En effet, le serveur OpenSSH écoute sur le port 22, et accepte les simples connexions par mot de passe sur tous les utilisateurs, y compris root, l’administrateur du système. Le tout sans limitations sur le nombre d’essais pour saisir un mot de passe.

Je reparlerais de la limitation du nombre d’essais plus loin, car ce point est regroupé avec d’autres. Donc, première chose, pas obligatoire, mais assez répandue parce que ça calme les script-kiddiots, changer le port d’écoute. En effet, le port 22 est dit standard, et donc vous trouverez une flopée de serveurs SSH qui écoutent sur ce port. Ce n’est pas une tare, après tout, si le Web fonctionne tel qu’il est aujourd’hui c’est parce que tous les serveurs Web de la planète écoutent sur le port 80 et répondent au protocole HTTP. On opère cette modification dans le fichier /etc/ssh/sshd_config :

SI vous voulez tout de suite tester la modification, vous pouvez enregistrer, et redémarrer le serveur SSH. Ça ne coupera pas la connexion actuelle, mais ça demandera à toute connexion future de passer par le « nouveau » port. D’ailleurs, je conseille de garder la connexion initiale d’ouverte, et de tester les modifications avec une nouvelle connexion en parallèle. Comme ça si ça ne fonctionne pas comme attendu, on a toujours la connexion d’ouverte pour corriger le tir avant de se retrouver exclus.

Une autre très mauvaise habitude qu’on garde souvent (et je suis le premier, même si je me soigne), c’est la connexion à SSH directement en tant qu’administrateur. C’est très, très mauvais, parce qu’un attaquant peut alors tenter directement l’accès par celui-ci, et aura portes ouvertes s’il passe à travers. Donc interdire la connexion de root à SSH est une bonne chose à faire, et ça se fait toujours dans le fichier /etc/sshd_config :

D’autres petits réglages renforceront la sécurité du serveur SSH :

On a donc déjà bien verrouillé notre serveur SSH. Et les plus habitués auront remarqué que j’ai laissé de côté un aspect crucial : la connexion au moyen de clés de chiffrement.

On peut aussi éventuellement restreindre l’accès à seulement certains utilisateurs :

Les clés SSH, pour se passer (temporairement) de mot de passe

En effet, plutôt que d’utiliser le couple « login/password », on peut utiliser le couple « login/clé ». Pour rappel, ce mécanisme fait appel à un jeu de clés asymétriques de chiffrement : la clé privée est utilisée par l’utilisateur pour s’authentifier sur une machine, qui dispose de sa clé publique pour valider l’identité. Asymétrique, parce qu’il est impossible de recréer la clé privée à partir de la clé publique.

On peut créer ce jeu de clés soit sur le serveur, soit sur votre machine. Je vous laisse lire cet article du wiki homeserver.diy qui détaille la manipulation à la fois pour Windows et pour Linux.

Vous avez créé votre jeu de clés et ajouté la clé publique à l’utilisateur de votre serveur ? Bien, après l’avoir testée, vous pouvez désactiver l’utilisation des mots de passe dans SSH :

SSH est donc maintenant bien plus restreint et robuste, passons à la suite.

Désactivation du compte root

Hein ? Oui, on est maintenant obligé de passer par un utilisateur standard pour se connecter à distance à notre machine, mais une fois à l’intérieur, on peut toujours disposer du compte root. Si on doit partager l’administration avec d’autres personnes, partager simplement le compte root n’est pas très avisé. On préfèrera alors passer par sudo, comme je l’ai décrit dans cet article.

Mais je n’avais pas abordé la possibilité de verrouiller le compte root, pour empêcher son utilisation directe. La commande est alors simple :

C’est déjà mieux. Maintenant, l’étape suivante : le blocage du brute-force.

Limiter les tentatives de connexion avec Fail2ban

J’ai déjà abordé Fail2ban dans le cadre de la sécurisation de WordPress, et dans sa configuration par défaut, il s’attarde aussi sur les tentatives de connexion en scrutant le fichier /var/log/auth.log. Voyons voir le fichier /etc/fail2ban/jail.conf tout d’abord :

Bon déjà, on a un souci, le port, qu’on a modifié. Il suffit de le remplacer par celui sélectionné plus haut. Il faut ensuite vérifier le filtre sshd.conf, dans le dossier filter.d  :

C’est bon, ça fonctionnera pour tous les utilisateurs, la première ligne cherchant les échecs de connexions quelque soit le login, ouf.

Éviter le FTP, mangez du SFTP

Si votre objectif est de fournir un outil de transfert de fichiers, pensez plutôt à utiliser le SFTP. Il repose sur SSH qu’on a déjà bien retravaillé, mais pour faire du transfert/de la gestion de fichiers seul. Et on peut « contraindre » les utilisateurs dédiés aux transferts dans une arborescence en particulier. Et surtout, faire en sorte qu’ils ne puissent faire que du SFTP, et pas du SSH (pas de possibilité d’exécuter des commandes arbitraires, ni se balader dans tous les dossiers du serveur).

Retournons dans notre fichier /etc/ssh/sshd_config, et commençons par y modifier cette ligne :

On va ensuite ajouter quelques raffinements à la fin du fichier de configuration. Si l’on veut des dossiers séparés pour chaque utilisateur, on utilisera la directive Match User :

Il va sans dire qu’il faudra configurer correctement l’utilisateur, notamment avec la commande suivante :

Petite explication rapide :

  • -d permet de définir le dossier de l’utilisateur créé
  • -s permet de définir le shell, ici /bin/false est un shell bidon qui ne donne sur rien

On oubliera pas évidemment de créer le dossier en question ni de lui créer son jeu de clés ainsi que de le l’installer correctement.

Si l’on veut un dossier commun à tous les utilisateurs, on crée un groupe, mettons sftp-users :

Et dans la configuration SSH, on utilisera la directive Match Group :

Lors de la création des utilisateurs, la commande sera un peu différente, puisqu’on ajoutera l’utilisateur au groupe créé à l’aide de l’option -g :

Et c’est qu’un début

On s’est surtout concentré sur le serveur SSH, qui est le premier point d’entrée de notre serveur. C’est surtout, avec le pare-feu, l’un des composants communs à tous les usages que l’on peut faire d’une telle machine. Les épisodes suivants traiteront donc d’autres domaines, tels que les serveurs Web (et composants annexes : fpm, mysql/mariadb…), et d’autres qui pourraient faire partie de cette série. Je n’ai encore rien de définitif, juste qu’il y aura d’autres articles 🙂

PS : La partie 2 est à votre disposition, bonne lecture 😉

7 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
NHiX
NHiX
03/04/2015 20:33

Vraiment intéressant merci beaucoup pour tes notions de sécurité 🙂
vivement la seconde partie

janus57
janus57
09/04/2015 07:42

Bonjour, est-ce que changer le port SSH est vraiment une bonne idée (Cf : https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/) ? Car bon si déjà on met fail2ban autant le faire bosser, perso je laisse SSH sur 22 et je modifie le bann pour qu’il soit banni sur l’intégralité sur serveur et non juste le port 22, comme ça si le robot a pour idée de scanner/bruteforcer un autre port que le 22 il se fait éjecter directement (1tentative après bann, vive les clés). Sinon perso je suis pas fan de sudo, je préfère me connecter en user normale puis passer en root avec un… Lire la suite »

Kero
Kero
24/04/2016 14:13
Répondre à  janus57

Clairement que c’est une bonne idée ! La changement de port évite une grosse partie des bots a la con qui scan non stop sur le 22 et vont pas plus loin. 🙂

martinus
martinus
03/06/2017 09:14

Et si on veut transférer des fichiers de A à B directement sans passer par une machine tierce C quelle est la bonne pratique si les MDP sont désactivés ?