Sécuriser un serveur web Linux en quelques étapes simple

Dans cet article nous allons voir comment sécuriser au minimum un serveur web sous Debian et Ubuntu server. Penchons nous sur la gestion des accès SSH, l'ouverture des ports, l'installation d'un certificat SSL pour le https, et 2 principaux outils visant à contrer les attaques par force brute et le second pour prévenir l'infection par rootkit.

Lorsque l'on administre un serveur web, que ce soit à la maison ou au bureau, une étape cruciale permet de maintenir votre serveur dans un environnement sain, la sécurité et l'intégrité de ce dernier, avant sa mise en production son ouverture sur le web. Un serveur web doit être (re)vérifié et testé avant d'être mis en ligne, il convient également de renforcer au maximum les accès administrateurs (root) en se débarrassant des mots de passe, et en privilégiant un accès par une paire de clés publiques/privées, et protégée par une phrase de passe. En combinant cela avec l'utilisation Keepass afin de générer des mots de passe long et complexes, mais également afin de stocker et gérer ces derniers, vous augmenterez considérablement les tentatives d'accès par brute force.

Bien que le protocole SSH soit sécurisé dans son essence, tous les échanges utilisant ce protocole sont chiffrés, une couche de sécurité supplémentaire n'est pas de trop. Vous pouvez associer vos connexions distantes à un VPN, toutes les ressources extérieures à votre réseau local domestique ou professionnel.

Passons au tutoriel.

Ce tuto est destiné aux serveurs sous Debian ou Ubuntu server, et peu importe le serveur web que vous utilisez, Nginx ou Apache. De même, cet article est basé à partir d'un pc client sous Ubuntu desktop, pour les utilisateurs sous Windows, la gestion et génération des clés privées/publiques peut se faire depuis l'application Putty ou en installant le sous-système Linux WSL puis en téléchargeant Ubuntu et/ou Debian depuis le Microsoft Store.

Vous travaillez sous macOS ? Lancez votre terminal et suivez ce tuto.

Modifier le port SSH

Le port par défaut utilisé pour se connecter en SSH est le numéro 22 udp/tcp, les hackers le savent très bien. La première manipulation consiste à modifier le port par défaut en lui attribuant un numéro supérieur à 1024, les ports 1 à 1024 sont réservés et ne peuvent pas être utilisés pour une autre finalité que celle qui leur est dédiée.

Voici la marche à suivre pour modifier le port par défaut :

1. Connectez-vous à votre serveur en ssh de la manière suivante :
   ssh nom_utilisateur@nom_hote_ou_adresse_ip
2. Ajoutez une règle au pare-feu de façon à autoriser le trafic sur le nouveau port SSH avec cette commande :
   sudo ufw allow nouveau_numero_port/tcp
   (remplacez nouveau_numero_port par un numéro de port compris entre 1024 et 65536)
3. Ouvrez le fichier de conf SSH sshd_config avec l'éditeur de votre choix :
   nano /etc/ssh/sshd_config
   ou avec vi en lieu et place de nano
4. Recherchez la ligne commençant par Port 22, notez qu'il se peut qu'elle soit commentée avec un # en début de ligne. Supprimez le # et remplacez 22 par la valeur que vous avez choisi dans le point #2.
5. Dès lors, enregistrez vos modifications et redémarrez le service SSH :
   sudo service sshd restart

C'est fait, vous avez modifié le port d'écoute SSH, vous devrez désormais indiquez le nouveau port SSH lors de vos futurs connexions à distance à votre serveur, en ajoutant l'argument -p qui permet d'indiquer un numéro de port dans la commande. Exemple, vous avez choisi le port 4242 comme étant le nouveau port SSH de votre serveur, votre nom d'utilisateur est bobmarley et votre machine se trouve dans votre réseau local avec l'ip 192.168.1.100 :

ssh -p 4242 bobmarley@192.168.1.100

Cette manipulation présente un grand intérêt si votre machine n'est pas sur une DMZ et que vous n'avez que les ports essentiels d'ouverts, donc à minima le port 80 (http) et le port 443 (https). Vous pouvez installer Portsentry afin de limiter, voire même bloquer le scan de ports. Si votre serveur est hébergé à votre domicile, dans 99,9% des cas vous n'avez pas besoin de le mettre sur une DMZ, ce qui présente un risque critique de sécurité. Contentez-vous simplement d'ouvrir les ports dont vous avez besoin et pas plus, et ce afin de conserver des portes fermées aux pirates.

Gestion des accès SSH avec une paire de clé privée/publique

La meilleure manière d'accéder à distance à votre serveur via SSH n'est pas forcément en utilisant votre mot de passe user et/ou root, mais plutôt en utilisant un accès par clé SSH. Cela consiste à générer une paire de clé privée et publique, la clé publique est stockée sur votre serveur distant et la clé privée est stockée localement sur votre ordinateur avec lequel vous vous connecterez à distance. Par la même occasion il est également possible (et recommandé) de désactiver l'accès par mot de passe pour ne permettre qu'un accès via clé privée/publique.

ATTENTION : notez que la clé privée qui sera générée est strictement confidentielle et ne doit jamais être communiquée ou partagée.

Avantages :

• Simplification des accès, plus besoin de renseigner votre mot de passe lors de votre connexion SSH
• Si votre mot de passe utilisateur était compromis, la clé privée (stockée localement) reste requise pour y accéder
• Possibilité d'utiliser cette même clé sur plusieurs serveurs différents, pratique pour les admins qui administrent plusieurs serveurs. Plutôt que de retenir et sauvegarder dans KeepassXC plusieurs mots de passe différent, envoyez la clé publique sur tous vos serveurs pour vous y connecter facilement à l'aide de votre clé privée stockée sur votre ordinateur.

Inconvénients :

• Nécessite un peu de temps pour la mise en place selon le nombre de serveurs à gérer
• La vulnérabilité de la clé privée en cas de mauvaise gestion ou perte dudit fichier, pensez à gérer vos accès à l'aide KeepassXC

Commençons par la création des clés :

1. Ouvrez votre Terminal et tapez cette commande :
   ssh-keygen
   Dans cette commande aucune option n'est renseignée, donc par défaut la commande créera une clé RSA de 2048 bits, ce qui est correct.
   Pour obtenir une clé RSA de 3072 ou 4096 bits, tapez :
   ssh-keygen -b 3072 ou ssh-keygen -b 4096
2. Il vous sera ensuite proposé de saisir une passphrase, je vous recommande vivement d'en créer une complexe et de la stocker dans KeepassXC. Ainsi, si votre fichier de clé privée venait à être compromis suite à sa perte ou vol d'un pc portable, le malandrin ne pourra pas se connecter à vos serveurs sans la passphrase car par défaut, si vous ne renseignez pas de passphrase il suffira de lancer la commande de connexion SSH pour accéder au(s) serveur(s).

Une fois créée, les clés sont stockés dans le répertoire .ssh de l'utilisateur. Vous aurez deux fichiers, dont un avec l'extension .pub, c'est ce fichier que nous enverrons sur tous nos serveurs distants, la clé privée reste sur votre ordinateur.

Poursuivons par l'envoie de la clé publique sur le serveur :

Il faut maintenant envoyer la clé publique vers vos serveurs afin de pouvoir s'y authentifier, dans l'environnement Linux il existe une commande vous permettant d'envoyer la clé facilement :

ssh-copy-id user@server

Par exemple, vous souhaitez ajouter cette clé sur votre serveur dédié hébergé chez OVH, Kimsufi, Scaleway, AWS dont l'IP est par exemple 42.42.42.42 et sous l'utilisateur toto :

ssh-copy-id toto@42.42.42.42

ATTENTION : dans la 1ére partie plus haut nous avons modifié le port SSH, la commande en l'état ne passera pas, il faudra donc spécifier le nouveau port SSH que vous avez choisi plus haut.

ssh-copy-id -p num_port user@server

Exemple :

ssh-copy-id -p 4242 toto@42.42.42.42
Remplacez 4242 par la valeur précédemment mise en place.

C'est fait, vous pouvez tester le bon fonctionnement en vous connectant de nouveau à votre serveur distant :

ssh -p 4242 toto@42.42.42.42

Si l'opération s'est bien déroulée, vous n'avez pas eu besoin de renseignez votre mot de passe.

Protection contre les attaques par force brutes

Les hackers utilisent des robots chargés de scanner le web à la recherche de nouveaux périphériques, et en y testant bon nombre de ressources, notamment les attaques par force brute qui consiste à tester plusieurs combinaisons de login et mots de passe. Les serveurs peu protégés, notamment avec des mots de passe tels que 123456789 ou encore pa$$word et j'en passe tombe très rapidement au combat.

L'idée est de donc de bannir les IP's qui testent votre serveur et/ou qui échouent dans la combinaison du mot de passe, et vous seriez (peut-être) surpris de voir le nombre d'attaques auxquels un serveur est confronté, même votre tout petit blog sans aucune valeur commerciale. Gardez à l'esprit que vous pourriez vous aussi vous faire bannir de votre propre serveur dans le cas où vous utiliseriez la connexion par mot de passe et que vous vous trompiez de mot de passe, hormis si vous utilisez une connexion SSH par clé publique/privée comme expliqué plus haut dans cet article.

Pour cela, il existe un outil très pratique et très connu, Fail2ban. Il peut-être exploité dans sa config par défaut, mais le mieux étant de peaufiner légèrement sa configuration pour y configurer à minima : l'envoie de mail, modifier le nombre de tentative de connexion possible, la durée des bannissements mais aussi lui spécifier le nouveau numéro de port SSH.

Passons à son installation :

apt install fail2ban

Une fois installé, nous allons modifier son fichier de conf qui se nomme jail.conf :

nano /etc/fail2ban/jail.conf
Sous nano, après avoir ouvert le fichier utilisez Ctrl+ w pour localiser un mot clé.

• Localisez bantime et revoyez sa valeur à la hausse.
• Localisez max retry et revoyez sa valeur à la baisse. Si vous utilisez bien une connexion par clé publique/privée vous pouvez la mettre à 0. Attention quand même lorsque vous passez en root sur une Debian ou l'utilisation de sudo sous ubuntu, assurez-vous de bien conserver vore mot de passe utilisateur sous ubuntu et root sous Debian.
• Localisez destemail et renseignez votre adresse e-mail pour la réception des rapports.
• Localisez sender (juste en dessous de destemail) et renseignez l'adresse d'expéditeur de votre choix. Pratique lorsque vous administrez plusieurs serveurs, renseignez un nom vous permettant notamment d'identifier le serveur dont il est question.
• Localisez la section [sshd] et renseignez votre nouveau port SSH précedemment configuré dans la ligne port = ssh, supprimez SSH et remplacez par la valeur correspondante.

Vous pouvez enregistrer votre fichier et redémarrer le service fail2ban :

sudo service fail2ban restart

Protection contre les rootkits et portes dérobées

L'arme favorite des hackers, les rootkits. Il s'agit d'un logiciel malveillant sous forme d'exploit conçu pour permettre un accès non autorisé à un ordinateur, un serveur, réseau. Ils sont souvent très difficiles à détecter et peuvent se loger dans un système durant un certain temps, se faire tout petit et ne jamais déclencher d'alerte. Une fois un rootkit confortablement installé dans le système, le hacker prend le contrôle du ou des systèmes et peut à distance déclencher une série d'attaques, ou tout simplement installer davantage de ressources malveillantes à votre insu. Ces derniers sont de plus en plus sophistiqués et non détectable sans une série de vérifications très poussées.

Les rootkits les plus dangereux sont ceux qui s'intègrent dans le noyau, ils se mettent en route avant même le démarrage du système d'exploitation, ils sont plus communément appelés bootkits.

L'idée est donc d'installer un programme chargé de les détecter et de les supprimer, RKhunter (Rootkit Hunter, traqueur de rootkit en français). A ces fins, il compare le hash SHA256, SHA512, SH1 et MD5 des fichiers importants avec les hash connus, qui sont accessibles à partir d'une base de données en ligne. Il alerte également l'utilisateur lorsqu'il trouve des permissions qu'il juge anormales, des fichiers cachés, des chaînes suspectes dans le kernel, etc.

Passons à son installation :

sudo apt install rkhunter

Peaufinons quelques réglages :

nano /etc/default/rkhunter

REPORT_EMAIL="votre_adresse_e-mail"
CRON_DAILY_RUN="yes"

Commandes RKhunter :

Vérifier la dernière version :
sudo rkhunter --versioncheck

Mettre à jour le programme :
sudo rkhunter --update

Lister les différents tests effectués :
sudo rkhunter --list

Effectuer une vérification :
sudo rkhunter --checkall

Conclusion

Après avoir suivi ce tuto et appliqué les recommandations, vous avez déjà fait un grand pas dans la sécurisation de votre serveur web. D'autres aspects n'ont pas été abordés dans cet article, et notamment l'installation d'un certificat SSL Let's Encrypt qui est primordial pour chiffrer vos échanges. Vous pouvez en installer gratuitement et en quelques clics à l'aide du merveilleux outil qu'est Certbot.

Cette liste de manipulation n'est pas exhaustive et ne protégera pas votre serveur à 100%, mais vous en limiterez drastiquement la portée.

Et pour finir, notez que le risque 0 n'existe pas et que des vulnérabilités peuvent être présentes dans les outils eux-mêmes.

Une erreur à signaler ? Contact.