Liste de contrôle pour le durcissement des serveurs Linux
15 min de lecture - 8 mai 2026

Liste de contrôle étape par étape pour durcir un serveur Linux. Couvre SSH, les pare-feu, les correctifs, les autorisations de fichiers, SELinux/AppArmor et l'enregistrement des audits
Liste de contrôle pour le renforcement de la sécurité des serveurs Linux
Une installation Linux par défaut n'est pas une installation Linux sécurisée. Les erreurs de configuration telles que l'accès SSH root ouvert, les pare-feu faibles et les logiciels non mis à jour sont à l'origine de la majorité des violations de sécurité. Les nouveaux serveurs sont soumis à des analyses automatisées quelques minutes seulement après leur mise en ligne ; le renforcement de la sécurité doit donc être effectué avant toute autre chose.
Cette liste de contrôle couvre les étapes essentielles : verrouillage de SSH, configuration des pare-feu, application des correctifs, renforcement des permissions de fichiers, activation des contrôles d'accès obligatoires et mise en place de la journalisation d'audit.
Sécurisez SSH
SSH est votre principal point d'accès et la première cible des attaquants. La configuration par défaut (authentification par mot de passe, connexion root, port 22) correspond exactement à ce que recherchent les scanners automatisés.
Générez une paire de clés Ed25519, qui offre une sécurité et des performances supérieures à celles du RSA :
ssh-keygen -t ed25519Une fois que la connexion par clé fonctionne, mettez à jour /etc/ssh/sshd_config:
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers yourname
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2Remplacez le port par défaut 22 par un port moins évident. Cela n'arrêtera pas un attaquant déterminé, mais cela réduira considérablement le bruit généré par les scans automatisés.
Testez toujours les modifications depuis un deuxième terminal avant de fermer votre session actuelle. Exécutez sudo sshd -t pour vérifier qu'il n'y a pas d'erreurs de syntaxe, puis systemctl reload sshd pour appliquer les modifications sans interrompre les connexions actives.
Ajoutez l'authentification à deux facteurs
La 2FA signifie qu'un attaquant a besoin à la fois de votre clé SSH et d'un accès physique à votre appareil. Installez le module PAM Google Authenticator :
sudo apt install libpam-google-authenticator # Debian/Ubuntu
sudo dnf install google-authenticator # RHEL/FedoraExécutez google-authenticator pour chaque utilisateur afin de générer une clé secrète et des codes de récupération. Conservez les codes de récupération hors ligne.
Ajoutez cette ligne à /etc/pam.d/sshd:
auth required pam_google_authenticator.soPuis mettez à jour /etc/ssh/sshd_config:
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactiveGardez une session active ouverte pendant le test. Les codes TOTP dépendent de l'heure système exacte, assurez-vous donc que NTP est en cours d'exécution.
Configurer les pare-feu et Fail2Ban
Utilisez un pare-feu au niveau de l'hôte même si votre serveur se trouve derrière un pare-feu réseau. Le principe est simple : bloquez par défaut tout le trafic entrant, puis n'autorisez que ce dont vous avez besoin.
Pour Ubuntu/Debian (UFW) :
ufw default deny incoming
ufw default allow outgoing
ufw limit ssh
ufw enablePour RHEL/Rocky/AlmaLinux (Firewalld) :
firewall-cmd --set-default-zone=public
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=https
firewall-cmd --reloadRenforcez la pile réseau du noyau en ajoutant ces éléments à /etc/sysctl.conf:
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1Installez Fail2Ban
Fail2Ban surveille les tentatives de connexion et bloque les adresses IP après plusieurs échecs. Créez /etc/fail2ban/jail.local (ne modifiez pas jail.conf directement, les mises à jour l'écraseront) et configurez-le pour bloquer les adresses IP pendant une heure après trois tentatives infructueuses en l'espace de 10 minutes. Définissez le backend approprié pour votre pare-feu (banaction = ufw ou banaction = nftables).
Services d'audit et suppression des protocoles hérités
Vérifiez ce qui est à l'écoute avec ss -tlnp et ce qui est en cours d'exécution avec systemctl list-units --type=service --state=running. Désactivez tout ce dont vous n'avez pas besoin : Bluetooth, CUPS, avahi-daemon, rpcbind.
Supprimez les protocoles hérités qui transmettent des données en clair :
| Protocole obsolète | Port(s) | Alternative sécurisée |
|---|---|---|
| Telnet | 23 | SSH |
| RSH / Rlogin | 512, 513, 514 | SSH |
| FTP | 21 | SFTP / FTPS |
| TFTP | 69 | SFTP / SCP |
| NIS | Variable | LDAP / Kerberos |
Sous Debian/Ubuntu : sudo apt-get --purge remove xinetd nis tftpd telnetd rsh-server. Sur les systèmes basés sur RHEL : yum erase xinetd ypserv tftp-server telnet-server rsh-server. Vérifiez la suppression avec ss -tulpn.
Appliquez les correctifs et automatisez les mises à jour
La mise à jour de votre système est le moyen le plus rapide de combler les failles de sécurité connues. Exécutez les mises à jour immédiatement après le provisionnement :
apt update && apt upgrade -y # Debian/Ubuntu
dnf update -y # RHEL/RockyEnsuite, automatisez les correctifs de sécurité. Sur Debian/Ubuntu, installez unattended-upgrades et configurez-le pour qu'il n'applique que les correctifs de sécurité. Sous RHEL/Rocky, installez dnf-automatic et définissez upgrade_type = security dans /etc/dnf/automatic.conf.
Configurez des notifications par e-mail pour les résultats des mises à jour. Désactivez les redémarrages automatiques sur les serveurs de production (Automatic-Reboot = false) afin que les redémarrages aient lieu pendant les fenêtres de maintenance planifiées. Pour les environnements à haute disponibilité, envisagez l'application de correctifs à chaud avec Canonical Livepatch (Ubuntu) ou kpatch (RHEL).
Renforcer la sécurité des systèmes de fichiers et des autorisations
Commencez par auditer les binaires SUID et SGID. Ces fichiers s'exécutent avec des privilèges élevés et constituent des cibles de choix pour les attaques :
find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -lsRenforcez les permissions sur les fichiers critiques : /etc/shadow devrait être 600, /etc/passwd devrait être 644, /etc/ssh/sshd_config devrait être 600. Définissez un umask de 027 dans /etc/profile pour empêcher que les nouveaux fichiers ne soient accessibles en lecture à tous.
Recherchez et corrigez les fichiers accessibles en écriture par tous à l'aide de find / -xdev -type f -perm -0002 -ls. Pour les répertoires qui doivent rester accessibles en écriture à tous (comme /tmp), appliquez le bit sticky : chmod 1777 /tmp.
Options de montage sécurisées
Modifier /etc/fstab pour restreindre les opérations autorisées sur les partitions critiques :
| Partition | Options de montage | Objectif |
|---|---|---|
/tmp | nodev, nosuid, noexec | Empêche l'exécution de logiciels malveillants dans une zone accessible en écriture par tous |
/var/tmp | nodev, nosuid, noexec | Mêmes protections que /tmp |
/dev/shm | nodev, nosuid, noexec | Sécurise la mémoire partagée |
/home | nodev, nosuid | Bloque les binaires setuid et les nœuds de périphériques |
/var/log | nodev, nosuid, noexec | Protège l'intégrité des journaux |
Testez les modifications avec mount -o remount avant de redémarrer pour éviter les problèmes de démarrage.
Activer les contrôles d'accès obligatoires
SELinux et AppArmor ajoutent des restrictions au niveau du noyau concernant les actions autorisées aux processus. Utilisez celui fourni avec votre distribution : SELinux pour RHEL/CentOS/Fedora, AppArmor pour Ubuntu/Debian/SUSE. Passer de l'un à l'autre entraîne des problèmes de compatibilité.
SELinux : vérifiez l'état avec getenforce. Commencez en mode permissif (setenforce 0) pendant au moins deux semaines pour observer le comportement de la charge de travail sans rien perturber. Surveillez les violations avec ausearch -m avc -ts recent. Utilisez audit2why pour diagnostiquer les blocages et audit2allow -M [module_name] pour créer des modules de stratégie. Une fois que les journaux sont propres, passez en mode « enforcing » avec setenforce 1, puis rendez-la permanente dans /etc/selinux/config.
AppArmor : vérifiez les profils actifs avec aa-status. Installez apparmor-utils pour les commandes de gestion. Démarrez les profils en mode « complain » avec aa-complain, puis passez en mode d'application aa-enforce une fois que vous êtes sûr de vous. Utilisez aa-genprof pour créer des profils pour des applications personnalisées.
Configurer la journalisation et la surveillance des audits
Sans journalisation, les incidents ne laissent aucune trace. Installez auditd:
sudo apt-get install auditd audispd-pluginsAjoutez des surveillances du système de fichiers pour les fichiers critiques :
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identitySuivez l'exécution de toutes les commandes au niveau root :
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commandsChargez des règles avec augenrules --load et ajoutez -e 2 à la fin de votre fichier de règles pour rendre la configuration inviolable (les modifications nécessitent un redémarrage).
Surveillance de l'intégrité des fichiers avec AIDE
AIDE détecte les modifications non autorisées des fichiers en comparant l'état actuel à une base de référence valide. Installez-le, initialisez la base de données avec aideinit, puis déplacez le fichier obtenu vers /var/lib/aide/aide.db.gz. Configurez une tâche cron quotidienne pour exécuter aide --check et d'envoyer les résultats par e-mail aux administrateurs.
Centralisez les journaux
Les journaux locaux sont inutiles si un attaquant disposant d'un accès root les supprime. Transférez les journaux vers un serveur distant en temps réel à l'aide de rsyslog avec un chiffrement TLS. Ajoutez à /etc/rsyslog.conf:
*.* @@remote-host:514Set LogLevel VERBOSE dans votre configuration SSH afin que les journaux incluent les empreintes de clé pour chaque connexion réussie. Pour les environnements de production gérant plusieurs serveurs, des outils tels que Wazuh ou OSSEC offrent une détection d'intrusion basée sur l'hôte avec une analyse centralisée des journaux.
Maintenance continue
Le renforcement de la sécurité n'est pas une tâche ponctuelle. Les configurations évoluent, de nouvelles vulnérabilités apparaissent et les changements de personnel laissent derrière eux des comptes orphelins.
Chaque semaine : examinez les journaux Fail2Ban, vérifiez les mises à jour qui ont échoué, vérifiez les sauvegardes.
Tous les mois : auditez les comptes utilisateurs et les autorisations, passez en revue les services en cours d'exécution, effectuez une analyse complète avec Lynis ou OpenSCAP.
Tous les trimestres : renouveler les identifiants, mettre à jour les règles de pare-feu, tester la reprise après sinistre.
Utilisez des outils d'infrastructure en tant que code (IaaSC) tels qu'Ansible avec les rôles de renforcement de dev-sec.io pour appliquer des configurations cohérentes sur l'ensemble de votre parc et éviter toute dérive entre les audits.
Les serveurs dédiés de FDC vous offrent un accès root complet et un contrôle total sur votre pile de sécurité. Découvrez les options de serveurs dédiés pour construire sur une plateforme où vous contrôlez chaque couche.

Fatigué des déploiements lents ou des limites de bande passante ? FDC Servers offre une puissance dédiée instantanée, une portée mondiale et des plans flexibles conçus pour n'importe quelle échelle.
Mettre à jour maintenantPourquoi il est important d'avoir un VPS puissant et sans compteur
Un VPS sans compteur offre une bande passante forfaitaire à une vitesse de port fixe. En quoi il diffère des forfaits avec compteur, quand il est rentable et ce qu'il faut vérifier avant d'acheter.
7 min de lecture - 9 mai 2025
Gestion de la mémoire sous Linux : Swap, OOM Killer & Cgroups
12 min de lecture - 31 mai 2026