Sécurité d’un serveur Linux : guide complet de durcissement (hardening)

Durcissement de l’accès SSH : désactiver root, utiliser les clés, changer le port

Le protocole SSH est la porte d’entrée principale de votre serveur. Par défaut, il écoute sur le port 22, une cible numéro un pour les robots qui tentent des connexions automatisées en continu. Durcir cet accès est donc votre priorité absolue. Avant toute modification, créez un utilisateur non-root disposant des droits sudo : vous aurez ainsi un point d’accès sécurisé pour administrer la machine sans jamais être bloqué dehors.

• Créer un utilisateur sudo : première étape obligatoire avant toute autre modification.
• Désactiver la connexion root : le compte root possède tous les privilèges, un risque majeur.
• Utiliser des paires de clés SSH : bien plus robustes que les mots de passe face aux attaques.
• Changer le port SSH : quitter le port 22 déjoue les tests automatisés systématiques.
• Désactiver l’authentification par mot de passe : n’autoriser que les échanges par clés cryptographiques.

Pour configurer les clés, générez une paire sur votre poste local, puis copiez la clé publique vers le serveur. Remplacez ensuite votre mot de passe par cette clé : les tentatives de force brute deviennent alors inutiles, car une clé cryptographique ne se devine pas. Enfin, modifiez le fichier de configuration `/etc/ssh/sshd_config` pour appliquer ces réglages, puis redémarrez le service SSH pour valider vos changements.

Pare-feu : configuration d’UFW, IPTables et firewalld la première ligne de défense

Le pare-feu constitue la première ligne de défense de votre serveur. Sa règle fondamentale est simple : bloquer tout trafic sauf autorisation explicite. Pour un serveur web, seuls les ports 80 et 443 (HTTP/HTTPS) doivent rester ouverts vers l’extérieur, en plus du port SSH que vous avez déjà sécurisé. Cette approche par défaut refusée réduit considérablement votre surface d’exposition.

Trois outils s’offrent à vous selon votre distribution. IPTables est le pare-feu logiciel historique et le plus complet pour Debian. UFW, son interface simplifiée, convient parfaitement aux débutants. Firewalld, privilégié sur RHEL et Fedora, gère des zones dynamiques. Quelle que soit l’option choisie, définissez d’abord une politique de sécurité claire avant de configurer vos règles.

La journalisation est cruciale : UFW et firewalld s’intègrent à journald et rsyslog pour tracer les tentatives bloquées. Auditez régulièrement ces journaux pour ajuster votre configuration et détecter les comportements anormaux. Un pare-feu bien réglé, couplé à une surveillance attentive, dissuade la majorité des attaques automatisées.

Mises à jour système et gestion des correctifs : réduire les vulnérabilités connues

Laisser un serveur sans mises à jour de sécurité revient à le laisser entrouvert : 57% des compromissions externes proviennent de systèmes non à jour. Les correctifs colmatent les failles connues avant qu’un attaquant ne les exploite. Voici comment organiser cette tâche essentielle selon votre distribution.

Automatiser les mises à jour de sécurité

Sur Debian et Ubuntu, l’outil unattended-upgrades installe automatiquement les correctifs de sécurité critiques pendant la nuit. Une fois configuré, il ne nécessite plus d’intervention manuelle. Pour ceux qui préfèrent une alternative éprouvée, cron-apt planifie des mises à jour régulières et envoie un rapport par email. Sur les systèmes critiques où un redémarrage est impossible, KernelCare Enterprise de TuxCare applique les correctifs du noyau sans redémarrage, éliminant les fenêtres de vulnérabilité liées aux temps d’arrêt.

Gérer les correctifs selon le gestionnaire de paquets

• DEB (apt) : commandes apt update puis apt upgrade pour les paquets Debian et Ubuntu
• RPM (dnf) : dnf update sur Fedora, RHEL et CentOS pour synchroniser le système
• RPM (yum) : yum update pour les anciennes versions de distributions Red Hat
• RPM (zypper) : zypper update sur openSUSE et SUSE Enterprise pour les correctifs groupés

Quel que soit l’outil choisi, la priorité reste la même : appliquer les correctifs de sécurité dès leur publication. Pour vérifier qu’aucune mise à jour n’a été négligée, consultez régulièrement les bulletins de sécurité de votre distribution et croisez-les avec la liste des paquets installés. Si vous utilisez des dépôts tiers, redoublez de vigilance : chaque paquet supplémentaire élargit la surface d’attaque et nécessite un suivi tout aussi rigoureux.

Dans un contexte où les cyberattaques se multiplient, protéger son entreprise des ransomwares devient une priorité absolue. Un serveur durci est une première barrière, mais il doit s’accompagner de sauvegardes régulières et de plans de réponse aux incidents pour limiter l’impact d’une éventuelle compromission.

Gestion des comptes, de sudo et de l’accès root : appliquer le moindre privilège

Le compte root dispose d’un accès total au système, ce qui en fait une cible privilégiée des attaques par force brute. Appliquer le principe du moindre privilège consiste à donner à chaque utilisateur uniquement les droits nécessaires rien de plus. Cette approche limite considérablement les dégâts en cas de compromission, un principe clé de la sécurité informatique pme.

Créer un utilisateur administrateur et protéger sudo

Pour renforcer la sécurité de votre serveur, envisagez également de sécuriser vos connexions distantes avec une solu, , une stratégie de sauvegarde de données fiable est tout aussi essentielle, tion vpn sécurisée, qui chiffre le trafic et protège vos données sensibles.

– Créer un compte non-root : un utilisateur classique pour les tâches courantes, sans privilèges.
– Accorder sudo : ajouter cet utilisateur au groupe sudo (Debian/Ubuntu) ou wheel (RHEL/CentOS) pour des élévations ponctuelles.
– Interdire le login root : après validation du nouveau compte, bloquer toute connexion directe en root.
– Protéger su : limiter son utilisation au groupe admin via la directive pam_wheel.so pour éviter les changements de compte non contrôlés.
– Restreindre sudo : configurer sudoers pour autoriser uniquement les commandes indispensables, jamais une session complète.

Appliquer une politique de mots de passe robuste

Une fois les comptes créés, la robustesse des identifiants devient votre première barrière. Un mot de passe de 10 caractères minimum, combinant majuscules, minuscules, symboles et chiffres, est la recommandation universelle. Simplifiez-vous la vie et renforcez votre sécurité en utilisant un gestionnaire de mots de passe comme KeePassXC : il génère et stocke des identifiants complexes uniques pour chaque système.

Pour garantir l’application de cette politique, éditez le fichier /etc/login.defs pour définir la longueur minimale et la durée de validité. Activez ensuite l’authentification à deux facteurs (2FA) pour les connexions critiques : même avec un mot de passe volé, l’attaquant reste bloqué sans le second facteur. Enfin, n’oubliez pas d’auditer régulièrement les comptes : supprimez les comptes inactifs et changez les mots de passe après tout départ d’un collaborateur.

Limiter la surface d’attaque : Fail2ban, suppression des services et contrôle d’accès obligatoire

Protection proactive contre les attaques par force brute avec Fail2ban

• Bannissement automatique : Fail2ban bannit les IP fautives après plusieurs échecs d’authentification.
• Analyse des logs : la solution se base sur les logs serveur pour détecter les comportements suspects.
• Alternative moderne : Fail2ban remplace DenyHosts, obsolète et non maintenu depuis 2014.
• Intégration systemd : l’outil moderne s’intègre nativement avec systemd pour une gestion simplifiée.

La force brute reste la méthode d’attaque la plus simple et la plus courante contre les serveurs exposés. Même avec des mots de passe robustes, chaque tentative de connexion échouée représente un risque. Fail2ban agit comme un gardien : après un nombre défini d’échecs, il bloque l’adresse IP incriminée au niveau du pare-feu pour une durée configurable.

L’outil surveille en continu les fichiers de logs de services comme SSH, Apache ou Postfix. Lorsqu’il détecte une série de tentatives suspectes, il crée automatiquement une règle de blocage. Cette approche proactive réduit considérablement l’exposition aux attaques automatisées qui balayent constamment Internet à la recherche de faiblesses.

Réduire la surface d’attaque : services inutiles et contrôle d’accès obligatoire

Chaque service actif sur un serveur représente une porte potentielle pour un intrus. Plus vous installez de paquets, plus votre surface d’attaque s’agrandit : des services superflus signifient du code superflu et donc des risques de sécurité supplémentaires. La règle d’or consiste à n’exécuter que le strict nécessaire. Les ports 80 et 443, indispensables pour les connexions HTTP et HTTPS, doivent rester ouverts, mais tout autre port inutilisé doit être fermé.

Pour compléter cette réduction, les systèmes de contrôle d’accès obligatoire (MAC) ajoutent une couche de protection essentielle. SELinux, développé pour les distributions RHEL, CentOS et Fedora, contrôle précisément l’accès des processus aux fichiers. AppArmor, plus simple à configurer, utilise des profils par application sur Debian et Ubuntu. Ces outils confinent chaque service : même si un processus est compromis, il ne peut pas accéder aux ressources hors de son périmètre autorisé.

La mise en place de contrôles d’accès obligatoire est une pratique recommandée par les référentiels de conformité comme les CIS Benchmarks, qui proposent deux niveaux de durcissement progressif, ou le guide ANSSI-BP-028, structuré en quatre niveaux de sécurité croissants. Ces frameworks fournissent une feuille de route claire pour renforcer méthodiquement votre serveur.

Surveillance, audits de sécurité et sauvegardes : détecter, auditer, restaurer

Surveillance des logs et outils d’audit pour détecter les intrusions

Même un serveur parfaitement durci peut subir une intrusion. La surveillance continue des logs et des audits réguliers permettent de détecter une anomalie avant qu’elle ne se transforme en catastrophe. Voici les outils essentiels à mettre en place :

• Logwatch : analyse les logs et envoie chaque jour un récapitulatif par email
• Rkhunter : détecte les backdoors et intrusions via des empreintes MD5
• Lynis : audite la sécurité et attribue un score de durcissement sur 100
• OpenSCAP : vérifie la conformité avec les référentiels ANSSI-BP-028 et CIS

Lynis est particulièrement utile pour un audit rapide : il scanne l’ensemble du système, identifie les faiblesses de configuration et produit un score de durcissement sur une échelle de 100. Un score faible indique les axes d’amélioration prioritaires.

Pour la conformité réglementaire, OpenSCAP s’appuie sur des profils prédéfinis : le guide ANSSI-BP-028 propose 4 niveaux de progression selon le degré de sensibilité du serveur, tandis que les CIS Benchmarks organisent leurs recommandations en 2 niveaux (Level 1 pour l’hygiène essentielle, Level 2 pour les environnements à haute sécurité). Enfin, l’outil ClamAV complète le dispositif en analysant les logiciels malveillants sur le serveur.

Sauvegardes régulières et plan de reprise après intrusion

La meilleure configuration de sécurité ne garantit jamais une protection absolue. C’est pourquoi les sauvegardes régulières et un plan de reprise documenté constituent votre dernier rempart.

Utilisez Rsync pour automatiser des sauvegardes locales ou distantes vers un stockage externe. Ces copies doivent être effectuées quotidiennement et testées régulièrement : une sauvegarde jamais restaurée n’est pas une sauvegarde fiable.

Pour la sécurité de vos mots de passe et de vos secrets d’infrastructure, un gestionnaire comme KeepassXC permet de stocker des mots de passe complexes 10 caractères minimum avec symboles, majuscules et minuscules sans avoir à les mémoriser.

Enfin, documentez un plan de reprise d’activité (PRA) : il doit détailler la procédure de restauration complète, les responsables à contacter et les délais de rétablissement. Testez ce plan au moins une fois par trimestre pour garantir qu’une restauration rapide reste possible après une compromission.

Installation minimale : réduire l’exposition dès l’origine

La sécurité d’un serveur Linux se joue dès son installation. Chaque paquet supplémentaire représente du code exécutable, donc autant de failles potentielles. Un serveur dédié à une tâche précise doit contenir uniquement les paquets nécessaires à cette mission : moins il y a de logiciels, plus la surface d’attaque est réduite. Cette approche minimaliste s’inscrit dans la logique du guide ANSSI-BP-028, qui structure la progression en 4 niveaux de durcissement, et des CIS Benchmarks, répartis en 2 niveaux de conformité.

Installer depuis des sources fiables (dépôts officiels de la distribution) est tout aussi crucial : les référentiels tiers introduisent des dépendances non vérifiées et des vulnérabilités supplémentaires. Privilégiez les images systèmes officielles et, lors de l’installation, refusez les groupes de paquets superflus (serveur mail, imprimante, environnement graphique). Pensez aussi à désactiver les services activés par défaut qui ne sont pas indispensables au fonctionnement attendu. Cette rigueur initiale, couplée à des audits périodiques pour supprimer les paquets devenus inutiles, vous garantit un socle sain et durable.