Dès qu'un serveur Linux est connecté à Internet, il devient une cible. Pas nécessairement une cible visée personnellement par un attaquant déterminé : le plus souvent, ce sont des robots qui scannent en continu des plages d'adresses IP entières, à la recherche de services mal configurés, de comptes protégés par des mots de passe faibles ou de logiciels dont une faille connue n'a pas encore été corrigée. Ce type d'attaque opportuniste ne demande aucune sophistication de la part de l'attaquant : il suffit qu'un seul point faible existe pour qu'il soit trouvé, souvent en quelques heures seulement après la mise en ligne d'une machine.

La bonne nouvelle, c'est que se protéger de l'immense majorité de ces attaques ne demande pas d'outils sophistiqués non plus. Le durcissement d'un serveur repose sur une poignée de contrôles simples, mais appliqués systématiquement et sans exception. Cet article détaille ces contrôles dans l'ordre où il est logique de les mettre en place, en expliquant à chaque fois le raisonnement qui les justifie.

Comprendre ce que l'on protège

Avant de configurer quoi que ce soit, il est utile de se poser une question simple : qu'est-ce qui, sur ce serveur, représenterait un problème si un attaquant y accédait ? Des données clients, des identifiants d'accès à d'autres systèmes, la capacité à faire transiter du trafic malveillant, ou simplement la disponibilité du service pour vos utilisateurs. Cette réflexion détermine le niveau d'exigence à appliquer : un serveur de test isolé sans donnée sensible n'a pas les mêmes besoins qu'un serveur de production hébergeant des données personnelles. Le durcissement n'est jamais une fin en soi, il doit rester proportionné à ce qu'il protège.

Gestion des comptes et des accès

L'accès administrateur est le premier point à sécuriser, car c'est la porte d'entrée la plus directe vers le contrôle total de la machine. Trois règles simples réduisent déjà considérablement le risque :

Désactiver la connexion SSH directe en tant que root. Le compte root existe sur toutes les distributions Linux, ce qui en fait la première cible de toute tentative de connexion automatisée. En désactivant son accès direct (PermitRootLogin no dans la configuration SSH) et en imposant de passer par un compte nominatif puis sudo, on élimine d'un coup l'essentiel des tentatives de bruteforce, tout en conservant une trace claire de qui a effectué quelle action.

Privilégier l'authentification par clé plutôt que par mot de passe. Une clé SSH est virtuellement impossible à deviner par une attaque par force brute, contrairement à un mot de passe, même complexe. Une fois les clés en place et testées, désactivez l'authentification par mot de passe (PasswordAuthentication no) : un attaquant ne disposant pas de la clé privée correspondante ne pourra tout simplement pas se connecter, quel que soit le nombre de tentatives.

Limiter les droits sudo au strict nécessaire. Chaque compte disposant de droits d'administration est un point d'entrée potentiel supplémentaire. Un compte compromis avec des droits sudo complets équivaut à un accès root compromis. Accordez les droits au cas par cas, pour les commandes réellement nécessaires, plutôt que par habitude ou par facilité.

Le changement du port SSH par défaut (22) est parfois présenté comme une mesure de sécurité : en réalité, il ne fait que réduire le bruit dans les journaux en évitant les scans les plus basiques. Ce n'est pas une protection en soi, seulement un complément qui n'a de sens qu'associé aux mesures précédentes.

Réduire les services exposés

Chaque service en écoute sur le réseau est une surface d'attaque potentielle : une application web, une base de données accessible depuis l'extérieur, un service d'administration oublié après une phase de test. Le principe à appliquer est celui du moindre privilège appliqué aux services : un serveur ne doit faire tourner que ce dont il a réellement besoin pour remplir sa fonction.

Concrètement, cela implique un inventaire régulier des services actifs (la commande ss -tulpn permet de lister les ports en écoute) et la désinstallation de tout ce qui n'est plus utilisé. Un serveur web n'a par exemple aucune raison d'exposer un service de base de données directement sur Internet : celui-ci devrait rester accessible uniquement depuis le réseau interne ou via un tunnel sécurisé.

Un pare-feu comme ufw (simple d'usage) ou nftables (plus complet) vient compléter cette réduction de surface, en n'autorisant explicitement que les ports réellement nécessaires : 

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

Cette configuration illustre le principe : tout est bloqué par défaut, et seuls les ports explicitement justifiés (ici, SSH et HTTPS) sont ouverts. Chaque règle ajoutée doit pouvoir être justifiée par un besoin réel.

Mises à jour et gestion des correctifs

Une part importante des compromissions de serveurs exploite des vulnérabilités déjà connues et déjà corrigées par l'éditeur, mais dont le correctif n'a simplement pas encore été appliqué. Maintenir un serveur à jour n'est pas une tâche secondaire : c'est l'un des contrôles les plus efficaces qui soient, précisément parce qu'il neutralise des failles déjà documentées et donc faciles à exploiter automatiquement.

Sur les distributions basées sur Debian ou Ubuntu, le paquet unattended-upgrades permet d'automatiser l'installation des correctifs de sécurité sans intervention manuelle. Sur les environnements où une automatisation complète n'est pas souhaitable pour des raisons de disponibilité, il faut à défaut planifier un processus régulier et documenté de vérification et d'application des mises à jour, plutôt que de s'en remettre à la mémoire de l'administrateur.

Journalisation et supervision

Un serveur durci reste une cible ; l'objectif n'est pas de rendre toute attaque impossible, mais de la rendre suffisamment difficile et surtout détectable. Une supervision minimale mais effective repose sur trois éléments : la centralisation des journaux (pour ne pas dépendre d'une machine potentiellement compromise pour analyser l'incident qui l'a touchée), des alertes sur les événements anormaux (tentatives de connexion répétées, créations de comptes, changements de configuration), et un outil comme fail2ban, qui bannit automatiquement les adresses IP à l'origine de tentatives de connexion répétées et échouées.

Sauvegardes : le filet de sécurité

Même avec l'ensemble de ces contrôles en place, aucune protection n'est absolue. Des sauvegardes régulières, testées et si possible stockées hors du serveur lui-même, constituent la dernière ligne de défense : elles transforment un incident potentiellement catastrophique (perte de données, ransomware) en un désagrément opérationnel maîtrisable. Une sauvegarde jamais testée n'offre en réalité aucune garantie : seul un test de restauration effectif confirme qu'elle est exploitable le jour où elle sera nécessaire.

« La sécurité d'un serveur ne se résume pas à un outil unique : c'est la somme de petites décisions de configuration appliquées avec rigueur et dans la durée. »

Ce qu'il faut retenir

Résumés, ces contrôles forment une check-list simple mais efficace : accès administrateur restreint et par clé, services limités au strict nécessaire, pare-feu configuré en mode « tout refuser sauf exception », mises à jour appliquées régulièrement, journalisation centralisée avec alertes, et sauvegardes testées. Aucun de ces éléments n'est individuellement sophistiqué, mais c'est leur application systématique et conjointe qui rend un serveur significativement plus résistant aux attaques opportunistes, qui représentent la grande majorité des menaces réellement rencontrées sur des machines exposées à Internet.

Ces contrôles ne remplacent cependant pas un audit complet et documenté. Un outil comme Lynis, que je détaille dans un autre article, permet d'aller plus loin en passant en revue systématiquement la configuration du système et en priorisant les actions de durcissement restantes selon leur impact réel.