Sécuriser un serveur Linux en 2026 : la checklist complète

Un serveur Linux exposé sur Internet reçoit ses premières tentatives de connexion quelques minutes après sa mise en ligne. Ce ne sont pas des humains qui vous visent personnellement : ce sont des robots qui balaient Internet en continu, testent des mots de passe, cherchent des fichiers oubliés et exploitent les failles dès qu'elles sont publiées.

La bonne nouvelle : la grande majorité de ces attaques échouent contre un serveur correctement configuré et surveillé. Voici la checklist que nous appliquons, organisée par priorité.

1. Les accès : fermer les portes évidentes

L'accès SSH est la première cible. Trois réglages suppriment l'essentiel du risque :

1. Authentification par clé uniquement. Désactivez les mots de passe (PasswordAuthentication no). Une clé ne se devine pas.
2. Pas de connexion root directe. Connectez-vous avec un utilisateur nominatif puis élevez vos droits avec sudo (PermitRootLogin no ou prohibit-password).
3. Bannissement automatique. Une adresse IP qui échoue plusieurs fois de suite doit être bloquée automatiquement pendant un temps donné, puis plus longtemps si elle récidive.

Changer le port SSH réduit le bruit dans les journaux, mais ne remplace aucun des trois points ci-dessus.

À vérifier aussi :

• la liste des clés dans ~/.ssh/authorized_keys de chaque compte : chaque clé doit avoir un propriétaire identifié ;
• les comptes ayant un shell de connexion et les membres du groupe sudo ;
• les accès d'anciens prestataires ou collaborateurs.

2. Le réseau : n'exposer que le nécessaire

Listez ce qui écoute réellement sur votre serveur :

sudo ss -tlnp

Chaque port ouvert vers l'extérieur doit avoir une raison d'être. Une base de données, un cache ou une interface d'administration n'ont presque jamais besoin d'être joignables depuis Internet : liez-les à 127.0.0.1 et passez par un tunnel SSH si besoin.

Activez ensuite un pare-feu avec une politique « tout refuser par défaut », puis ouvrez uniquement SSH, HTTP et HTTPS.

3. Les mises à jour : la règle qui évite la plupart des incidents

La majorité des compromissions exploitent des failles déjà corrigées au moment de l'attaque. Le correctif existait ; il n'avait simplement pas été installé.

• Activez les mises à jour de sécurité automatiques du système (unattended-upgrades sur Debian et Ubuntu).
• Redémarrez quand le noyau a été mis à jour.
• Surveillez le nombre de mises à jour de sécurité en attente : s'il augmente, quelque chose bloque.

4. Les versions applicatives : l'angle mort

Les mises à jour automatiques du système ne touchent pas vos applications. Votre framework web, vos dépendances npm, Python ou PHP restent à la version installée lors du dernier déploiement.

C'est là que se cachent les failles les plus dangereuses. En décembre 2025, la faille React2Shell (CVE-2025-55182) permettait d'exécuter du code à distance sur des applications utilisant les React Server Components. Les serveurs qui n'avaient pas mis à jour leur framework étaient exploitables en une requête.

Il faut donc comparer régulièrement les versions installées aux bases publiques de vulnérabilités. Nous détaillons la méthode dans notre article sur les CVE et les dépendances vulnérables.

5. Le web : bloquer les sondes courantes

Votre serveur web reçoit en permanence des requêtes vers /.env, /.git/, /wp-login.php ou /phpmyadmin, même si vous n'utilisez rien de tout cela. Bloquez ces chemins, limitez le nombre de requêtes par adresse IP et cachez la version du serveur web.

Ajoutez les en-têtes de sécurité de base : Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options et une Content-Security-Policy adaptée.

6. Les fichiers : détecter ce qui change

Un attaquant qui a pris pied sur votre serveur cherche à y rester. Il ajoute une clé SSH, crée un compte, installe une tâche planifiée ou modifie un service. Surveiller l'intégrité de quelques fichiers sensibles suffit à détecter la plupart de ces persistances :

• /etc/passwd, /etc/shadow, /etc/sudoers et /etc/sudoers.d/
• /etc/ssh/sshd_config et les fichiers authorized_keys
• les crontabs et les services systemd

7. Les malwares : analyser régulièrement

Sur un serveur web, l'antivirus sert surtout à repérer les webshells et les fichiers déposés via un formulaire d'upload ou une faille applicative. Une analyse quotidienne, à basse priorité, des répertoires web, des dossiers temporaires et des répertoires utilisateurs suffit dans la plupart des cas. Voir notre article : un antivirus sur un serveur Linux, est-ce utile ?

8. Les performances : un signal de sécurité sous-estimé

Un processus inconnu qui consomme tout le CPU est souvent un mineur de cryptomonnaie installé par un attaquant. Un disque qui se remplit brutalement peut signaler une exfiltration ou des journaux qui explosent sous une attaque. Surveillez CPU, mémoire et disque, et sachez quels processus sont normaux. Détails dans ce que le CPU, la RAM et le disque révèlent d'une intrusion.

9. Les sauvegardes : votre dernière ligne de défense

• Sauvegardes automatiques, chiffrées, stockées hors du serveur.
• Au moins une copie qu'un attaquant ayant les droits root ne peut pas effacer.
• Une restauration testée au moins une fois par trimestre. Une sauvegarde jamais restaurée n'est qu'une hypothèse.

10. La surveillance : lire ce que dit votre serveur

Toutes les mesures précédentes produisent des signaux : tentatives bloquées, alertes, fichiers modifiés, versions vulnérables. Ces signaux ne servent à rien si personne ne les lit.

C'est le point qui manque le plus souvent dans les PME : les journaux existent, mais personne n'a le temps de les analyser. La solution est de résumer ces signaux et de les envoyer là où l'équipe travaille déjà, par exemple sur Slack. Voir comment recevoir ses alertes de sécurité sur Slack.

La checklist en un coup d'œil

Questions fréquentes

Combien de temps faut-il pour sécuriser un serveur Linux ?

Comptez une demi-journée pour un administrateur expérimenté sur un serveur neuf. Le plus difficile n'est pas la configuration initiale, c'est la surveillance dans la durée.

Un VPS chez un hébergeur est-il déjà sécurisé ?

Non. L'hébergeur sécurise son infrastructure ; la configuration du système, des accès et des applications reste de votre responsabilité.

Faut-il un expert sécurité à temps plein ?

Pour une PME, rarement. Il faut surtout une configuration de base solide et un outil qui vous prévient quand quelque chose change.

FondateurMode applique une grande partie de cette checklist en une commande : antivirus, bannissement automatique des IP, versions vulnérables, intégrité des fichiers, surveillance des performances, et un rapport quotidien rédigé par l'IA sur Slack ou par e-mail. Essayez-le gratuitement 14 jours.