Sécurité des serveurs : les mesures à prendre en premier

La sécurité des serveurs se raconte le plus souvent comme une liste de menaces. Ce n’est pas ce dont on a besoin devant une machine qui vient d’être livrée. Ce qu’il faut, c’est un ordre d’opérations : quoi faire à la première heure, quoi faire à la première semaine, et quoi vérifier ensuite tous les mois. Voici cette séquence, avec les fichiers, les valeurs et les délais qui s’appliquent réellement.

La première heure : fermer la porte d’entrée

Un serveur exposé sur Internet reçoit des tentatives de connexion automatisées dès qu’il répond. Ce ne sont pas des attaques ciblées, c’est un balayage permanent qui teste des identifiants courants sur toutes les adresses disponibles. Trois réglages suppriment l’essentiel de cette surface.

1. Supprimer l’authentification par mot de passe

C’est la mesure qui rapporte le plus, et elle est binaire : tant qu’un mot de passe suffit à ouvrir une session, une attaque par force brute reste possible. Avec une clé publique, elle ne l’est plus. Dans /etc/ssh/sshd_config, deux directives font le travail :

PasswordAuthentication no
PermitRootLogin no

Déposez votre clé publique et testez la connexion dans une seconde session avant de fermer la première. C’est la précaution qui évite de se verrouiller dehors, et elle ne coûte rien.

2. Ne laisser ouvert que ce qui sert

Le principe est d’interdire par défaut et d’autoriser au cas par cas, jamais l’inverse. Un pare-feu qui bloque une liste de ports connus laisse passer tout ce que la liste ignore.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 443/tcp
ufw enable

Une base de données n’a presque jamais besoin d’écouter sur une interface publique : liez-la à 127.0.0.1. Le rôle exact d’un pare-feu et ses limites sont détaillés dans notre article sur le rôle des pare-feu dans un réseau d’entreprise.

3. Faire tomber les tentatives répétées

fail2ban lit les journaux et bannit une adresse qui échoue trop souvent. Trois paramètres gouvernent son comportement, dans jail.local :

Paramètre	Ce qu’il règle	Valeur livrée par défaut
maxretry	Le nombre d’échecs tolérés	5
findtime	La fenêtre dans laquelle ces échecs sont comptés	10 minutes
bantime	La durée du bannissement	10 minutes

Dix minutes suffisent à décourager un balayage automatisé, qui passe à l’adresse suivante. Sur un serveur qui n’accueille que des administrateurs connus, allonger bantime à plusieurs heures ne gêne personne.

La première semaine : les mises à jour et le chiffrement

Automatiser les correctifs de sécurité

La quasi-totalité des compromissions réelles exploite une faille déjà corrigée en amont. Le délai entre la publication d’un correctif et son application est donc la vraie mesure du risque, et ce délai ne se raccourcit pas à la main.

Sur Debian et Ubuntu, unattended-upgrades applique les mises à jour de sécurité sans intervention. Réservez les mises à jour majeures, celles qui changent une version de PHP ou de base de données, à une fenêtre choisie et testée : une automatisation trop large casse la production un dimanche matin.

Chiffrer le transit, avec les bonnes versions

Un certificat ne suffit pas : les versions anciennes du protocole restent souvent actives derrière lui. TLS 1.0 et TLS 1.1 sont formellement dépréciés depuis mars 2021 par la RFC 8996, et doivent être désactivés au profit de TLS 1.2 et 1.3.

Le point de vigilance concret est l’expiration. Un certificat Let’s Encrypt est valide 90 jours. Le renouvellement automatique se déclenche bien avant l’échéance, mais il échoue silencieusement si une règle de pare-feu, une redirection ou un changement de DNS l’empêche de valider le domaine. Ce sont les mêmes mécanismes que ceux décrits dans notre article sur la propagation des DNS. Vérifiez donc que le renouvellement a effectivement eu lieu, plutôt que de supposer qu’il a eu lieu.

Avoir une sauvegarde dont vous avez testé la restauration

Une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une hypothèse. Face à un rançongiciel, c’est la seule mesure qui compte vraiment, et elle exige trois conditions : une copie hors du serveur, une copie qu’un compte compromis ne peut pas effacer, et une restauration réellement essayée. La mise en place pas à pas est décrite dans notre guide sur les sauvegardes automatiques d’un serveur.

Ensuite, tous les mois : cinq vérifications

• Les comptes. Supprimez les accès des personnes parties. C’est la faille la plus banale et la plus durable.
• Les ports ouverts. Comparez ce qui écoute à ce que vous avez autorisé. Un service installé pour un test reste en écoute pendant des années.
• Les journaux d’authentification. Vous ne cherchez pas les échecs, il y en aura toujours. Vous cherchez les réussites inattendues.
• La restauration. Restaurez une sauvegarde au hasard sur une machine de test.
• Les certificats. Vérifiez la date d’expiration effective, pas la configuration du renouvellement.

Le délai que la réglementation vous laisse

Si le serveur héberge des données personnelles, la sécurité cesse d’être un sujet purement technique. En cas de violation de données, l’article 33 du RGPD impose de notifier l’autorité de contrôle dans un délai de 72 heures après en avoir pris connaissance. Ce délai suppose de savoir ce qui a été exposé, donc de disposer de journaux exploitables avant l’incident et non après.

La CNIL publie un guide de la sécurité des données personnelles qui détaille les mesures attendues fiche par fiche. C’est la référence à citer dans une procédure interne, parce qu’elle fait autorité en France là où un billet de blog n’en a aucune.

Trois mesures qui rassurent sans protéger

La réserve mérite d’être posée, parce que ces trois mesures figurent dans presque toutes les listes de conseils et qu’aucune ne fait ce qu’on lui prête.

• Changer le port SSH. Cela réduit le bruit dans les journaux, ce qui a une vraie valeur pratique. Cela ne protège de rien : un balayage de ports retrouve le service en quelques secondes.
• Le pare-feu comme rempart unique. Un pare-feu contrôle qui peut parler à quoi. Il ne voit pas une injection SQL passer dans une requête légitime sur le port 443, parce que cette requête est autorisée.
• Le VPN comme garantie. Un tunnel protège le transport entre deux points. Il ne durcit pas la machine à l’arrivée, et nous précisons ce qu’il couvre exactement dans notre article sur sécuriser sa connexion avec un VPN.

La sécurité d’un serveur ne se joue pas sur un outil, mais sur un ordre : réduire la surface, appliquer les correctifs vite, pouvoir restaurer. Le reste est du réglage. Le choix du système d’exploitation intervient d’ailleurs plus tard qu’on ne le croit, et nous le comparons dans notre article serveur Linux ou Windows.

Questions fréquentes sur la sécurité d'un serveur

Par quoi commencer pour sécuriser un serveur ?

Par supprimer l’authentification SSH par mot de passe au profit d’une clé publique, et par un pare-feu qui interdit tout en entrée sauf les ports réellement nécessaires. Ces deux mesures retirent l’essentiel de la surface exposée aux attaques automatisées.

Changer le port SSH améliore-t-il la sécurité ?

Très peu. Cela réduit le volume de tentatives inscrites dans les journaux, ce qui les rend plus lisibles, mais un balayage de ports retrouve le service en quelques secondes. La mesure utile est la clé publique, pas le déplacement du port.

Combien de temps un certificat Let's Encrypt reste-t-il valide ?

90 jours. Le renouvellement automatique intervient avant l’échéance, mais il peut échouer sans alerte si une règle de pare-feu ou un changement de DNS empêche la validation du domaine. Il faut donc contrôler la date d’expiration réelle.

Quel délai le RGPD impose-t-il en cas de violation de données ?

72 heures après avoir pris connaissance de la violation pour notifier l’autorité de contrôle, selon l’article 33 du règlement. Tenir ce délai suppose des journaux exploitables mis en place avant l’incident.

Un pare-feu suffit-il à protéger un serveur web ?

Non. Un pare-feu décide qui peut atteindre quel service. Il ne distingue pas une requête malveillante d’une requête légitime sur un port qu’il autorise, comme le 443. Il faut donc aussi corriger les vulnérabilités applicatives.