Comment sécuriser votre serveur : un guide en 5 étapes

Nathanaël Cherrier -

Il y a plusieurs raisons pour lesquelles un développeur souhaiterait gérer ses propres serveurs. Les serveurs, en particulier les VPS (Virtual Private Server), sont des ressources devenues très abordables. Ils nous permettent de tester, builder, héberger nos projets et de faire encore plein d'autres choses.

Quelle que soit l'utilisation que l'on fait d'un serveur, celui-ci doit être protégé, car une intrusion malhonnête pourrait avoir de graves répercussions. Dans cet article, je vous explique comment sécuriser un VPS simplement en 5 étapes.

☝️
Je pars du principe que vous venez d'acheter votre VPS et que vous ne vous y êtes encore jamais connecté. Mais, la plupart des étapes sont réalisables sur un serveur déjà en fonctionnement.

1/ Mettre votre système à jour

Cela peut vous sembler basique, mais l'une des premières raisons pour lesquelles on trouve des failles sur les serveurs web est l'obsolescence du système. Ne pas mettre à jour son système régulièrement est un vrai danger pour notre business.

Même si vous venez de demander l'installation de votre VPS à votre hébergeur, vous gagnerez à actualiser votre système avant de passer à la suite de cet article. En effet, les hébergeurs utilisent souvent des sauvegardes ou des snapshots pour créer de nouveaux serveurs. Il y a donc de fortes chances pour que les paquets de votre système aient besoin de mise à jour.

Exécuter les commandes suivantes :

$ sudo apt update
$ sudo apt upgrade -y

2/ Changer le mot de passe root

Je ne suis pas sûr que cela soit utile de l'expliquer. Changez votre mot de passe root.

$ sudo su
$ passwd
New password: 
Retype new password: 
passwd: password updated successfully
$ exit

Le compte root est le compte du « super-administrateur ». Il a tous les droits. S'il y a un compte que l'on refuse de laisser aux mains des hackers, c'est bien celui-là.

Mais changer le mot de passe du compte root n'est pas suffisant. Vous verrez que nous allons un peu plus loin dans la suite de l'article.

3/ Créer un nouvel utilisateur

Une autre astuce pour éviter les problèmes sur votre serveur : n'utilisez pas root. Il y a au moins deux raisons à cela :

  • tout le monde à un utilisateur root sur sa machine par défaut. C'est facile à trouver pour un hackeur
  • root possède tous les droits sur la machine. Si une personne trouve le mot de passe du compte root, il peut tout faire sur la machine
☝️
Certains hébergeurs, pour limiter ce problème, change le nom du compte root. Ne pensez pas que vous êtes protégé pour autant ! Comme expliqué plus haut, à cause de l'automatisation de leur processus, ils donnent souvent les mêmes noms à tous les clients. Il suffit donc de savoir qui est votre hébergeur pour savoir comment il fonctionne, et donc savoir comment attaquer votre machine.

La meilleure solution pour contrer ce problème reste donc d'utiliser un compte différent pour la gestion de votre machine. Pour ce faire, utilisez la commande suivante : 

$ adduser nomDeVotreUser
Adding user `nomDeVotreUser' ...
Adding new group `nomDeVotreUser' (1001) ...
Adding new user `nomDeVotreUser' (1001) with group `nomDeVotreUser' ...
Creating home directory `/home/nomDeVotreUser' ...
Copying files from `/etc/skel' ...
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for nomDeVotreUser
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []: 
        Work Phone []: 
        Home Phone []: 
        Other []:
Is the information correct? [Y/n]

Après avoir répondu à toutes les questions de l'utilitaire, indiquons au système que ce nouvel utilisateur pourra effectuer des actions dédiées au super utilisateur sans en être un.

L'idée est de pouvoir dire « je ne suis pas super utilisateur, ne me donne aucun droit » mais temporairement, lorsque la situation l'exige, dire au système « en fait, c'est moi le super utilisateur, laisse-moi effectuer cette action ».

$ adduser nomDeVotreUser sudo
sudo adduser nomDeVotreUser sudo
Adding user `nomDeVotreUser' to group `sudo' ...
Adding user nomDeVotreUser to group sudo
Done.

Maintenant, vous pourrez taper sudo command depuis votre nouveau compte utilisateur sans recevoir un refus du système. Vous pouvez aussi vous connecter en SSH directement avec cet utilisateur.

4/ Modifier les accès SSH

À présent que seul vous connaissez le mot de passe du compte root et que vous ne l'utilisez plus pour vous connecter au serveur, il est temps d'aller un peu plus loin.

Quels sont les problèmes que l'on pourrait rencontrer ? Le brut force. Vous n'utilisez plus le compte root mais il est toujours utilisable. Utiliser des mots de passe générés aléatoirement jusqu'à ce qu'il y en ait un qui marche, est une méthode qui fonctionne encore aujourd'hui.

La méthode fonctionnerait d'ailleurs tout autant sur le second compte que nous avons créé plus haut.

Pour remédier à cela, nous allons modifier quelque peu la configuration SSH pour nous connecter avec une clé RSA plutôt qu'un mot de passe. Pour pouvoir vous connecter avec une clé, il vous faut tout d'abord une clé.

Générons donc la nôtre sur notre ordinateur local (pas le serveur).

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
  • -t permet d'indiquer le type de clé que l'on veut créer. Nous voulons une clé RSA
  • -b permet d'indiquer la taille de la clé. J'ai l'habitude de mettre 4 096 pour qu'elle soit deux fois plus longue, complexe et solide que celles de 2 048 bites par défaut. Mais, vous pouvez mettre la taille que vous voulez. Dites-vous juste que selon la puissance de votre ordinateur, plus vous demanderez une clé longue plus ça prendra du temps de la générer.
  • -C permet d'y ajouter un commentaire pour faciliter votre organisation

La commande vous demandera une passphrase. C'est-a-dire une phrase qu'il faudra indiquer pour pouvoir utiliser la clé. Un genre de mot de passe pour protéger la clé. Vous pouvez ne pas en mettre, mais il est fortement recommandé d'en mettre une.

Une fois la clé générée, vous retrouverez deux nouveaux fichiers sur votre machine locale. 

$ ls ~/.ssh
id_rsa    id_rsa.pub
  • id_rsa est votre clé privée. À ne communiquer sous aucun prétexte. Elle ne doit pas sortir de votre machine et vous permet de déchiffrer les données que l'on vous envoie.
  • id_rsa.pub est la version publique de votre clé. À communiquer à ceux avec qui vous souhaitez communiquer. Elle ne permet pas de déchiffrer les données, mais seulement de les chiffrer. En d'autres termes, elle permet d'écrire des messages que seule votre clé privée peut déchiffrer.

Comme je viens de le dire, la clé privée ne bougera pas de votre machine. Toutefois, pour pouvoir communiquer avec le serveur, il faut que le serveur ait votre clé publique. Il faut donc que nous lui envoyions.

Pas besoin d'ouvrir le fichier et de copier-coller quoi que ce soit, il y a une commande pour ça :

$ ssh-copy-id -i ~/.ssh/id_rsa nomDeVotreUser@ipDuServeur

Cette commande va créer le dossier ~/.ssh dans le compte de votre utilisateur sur le serveur. Ensuite, il va créer le fichier ~/ssh/authorized_keys dans lequel il ajoutera la clé publique liée à la clé privée id_rsa.

Normalement, cette commande envoie toutes les clés publiques de votre machine locale sur le serveur. Pour éviter cela, nous utilisons -i afin de lui indiquer quelle clé envoyer.

Vous pouvez maintenant vous connecter sans mots de passe au serveur en faisant ssh nomDeVotreUser@ipDuServeur. Seule la passphrase vous sera demandée si vous en avez indiqué une.

Comme il est possible de se connecter sans mots de passe, il ne nous reste plus qu'à désactiver la connexion avec mots de passe. Ainsi, le risque de brute force sera éliminé. Pour cela, sur le serveur, modifiez les lignes suivantes du fichier /etc/ssh/sshd_config pour qu'elles aient ces valeurs :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Avec ces réglages, il sera impossible de se connecter avec le compte root que l'on connaisse son mot de passe ou pas. Tous les autres comptes seront inaccessibles avec un mot de passe, mais accessibles si l'on possède la bonne clé RSA.

Dernier détail, le port standard utilisé par SSH est le 22. C'est-à-dire que tout le monde connait ce port. Pour rendre l'accès un peu plus compliqué, une bonne pratique consiste à change ce port pour une valeur entre 1 024 et 6 665.

Dans le même fichier /etc/ssh/sshd_config, modifier la ligne suivante avec la valeur de votre choix :

Port 5489

Pour valider ces changements, il faut relancer l'agent SSH comme suit :

$ sudo systemctl restart ssh

Votre serveur ressemble maintenant un peu plus à une forteresse. ssh nomDeVotreUser@ipDuServeur ne fonctionnera plus. Vous devrez, en plus de l'utilisateur et de l'IP, indiquer le port que vous avez choisi précédemment. Le mot de passe ne sera pas demandé, il faudra la clé RSA pour pouvoir se connecter.

$ ssh nomDeVotreUser@ipDuServeur -p 2345 -i ~/.ssh/id_rsa 
Enter passphrase for key '~/.ssh/id_rsa':
☝️
J'en conviens que pour plus de sécurité, nous avons largement sacrifié la simplicité et l'utilisabilité de cette commande. Mais, il est possible de la simplifier de nouveau grâce au fichier ~/.ssh/config.

5/ Activer un firewall

Le firewall permet de contrôler qui peut se connecter à votre serveur et comment. L'idée est d'éviter de laisser des fenêtres ouvertes dans notre forteresse. Nous allons donc spécifier explicitement ce que nous autorisons comme connexion à notre serveur.

La plupart des distributions Linux possèdent iptables et ufw installés par défaut. Moi, j'utilise UFW. Je vais donc vous expliquer les règles de base que j'applique pour la sécurité de mes serveurs. Pour en savoir plus sur le fonctionnement de cet outil, je vous conseille cet article de DigitalOcean.

On commence par désactiver le firewall le temps de faire nos modifications : 

$ sudo ufw disable

Ensuite, je change les règles par défaut pour que toutes les connexions entrantes soient refusées et toutes les connexions sortantes autorisées :

$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

Ensuite, nous allons autoriser les connexions SSH. Sinon, nous n'aurons plus moyen de nous connecter au serveur.

$ sudo ufw allow 2345/tcp

Changez 2345 par le port que vous avez choisi pour SSH à l'étape précédente.

⚠️
UFW connait les ports par défaut des services et propose des aides comme ufw allow ssh. Mais ne l'utilisez pas pour SSH justement, car vous n'utilisez plus le port 22 par défaut. Vous risqueriez de bloquer toutes les connexions SSH puisque SSH n'écoute plus le port 22. 

Maintenant, nous pouvons activer le firewall.

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Comme nous n'utilisons plus le port par défaut de SSH, si vous avez encore des connexions utilisant le port 22 (sur un autre terminal par exemple), UFW vous prévient que vous risquez de perdre votre connexion.

☝️
Vous pouvez vérifier que vos règles soient correctes avant d'activer le firewall grâce à la commande ufw status verbose.

Désormais, vous avez toutes les bases pour sécuriser vos serveurs. Il y a bien sûr beaucoup d'autres choses que l'on peut implémenter pour sécuriser un serveur, mais avec les 5 étapes de cet article, vous aurez un serveur beaucoup moins vulnérable aux attaques.

J'ai également préparé pour ceux qui le souhaitent un print qui reprend toutes les commandes de cet article, un glossaire et une explication des changements du fichier sshd_config. Rien de plus que ce qu'il y a dans cet article, mais l'idée est d'avoir un résumé des commandes (cheatsheet) pour rapidement sécuriser votre serveur.

Si vous êtes membre premium du blog, connectez-vous et téléchargez-le ci-dessous. Sinon, vous pouvez retrouver « VPS/serveur security cheatsheet » sur la boutique pour l'acheter sans devenir membre premium :

Acheter la cheatsheet

La version anglaise du PDF est à retrouver directement sur la boutique.