Ingenieure DevSecOps
Comment durcir vos serveurs Linux en production en 8 etapes
TL;DR
- 8 etapes essentielles pour transformer un serveur Linux par defaut en bastion de production securise : surface d'attaque, pare-feu, SSH, mises a jour, journalisation, controle d'acces, chiffrement et audits.
- Commandes pretes a copier-coller pour Debian/Ubuntu et RHEL/Rocky Linux, testees en production.
- Objectif : score Lynis > 80/100 et conformite avec les benchmarks CIS Level 1.
- Temps estime : 2 a 4 heures pour le durcissement initial, automatisable ensuite avec Ansible.
Un serveur Linux fraichement installe est une porte ouverte. Les configurations par defaut de Debian, Ubuntu, RHEL ou Rocky Linux privilegient la compatibilite et la facilite d'utilisation, pas la securite. En production, cette approche est inacceptable : chaque service inutile, chaque port ouvert, chaque configuration laxiste est un vecteur d'attaque potentiel pour un adversaire.
Ce guide presente 8 etapes concretes et actionnables pour durcir vos serveurs Linux de production. Chaque etape inclut des commandes pretes a l'emploi, des explications sur le raisonnement securitaire, et des conseils pour eviter les pieges courants. L'objectif : atteindre un score Lynis superieur a 80/100 et une conformite avec les benchmarks CIS Level 1.
— Etape 1 : Reduire la surface d'attaque — desactiver les services inutiles
La premiere regle du hardening est simple : ce qui n'est pas installe ne peut pas etre exploite. Un serveur Linux par defaut embarque des dizaines de services et paquets dont vous n'avez probablement pas besoin en production. Chacun de ces composants represente du code supplementaire qui peut contenir des vulnerabilites.
Commencez par lister tous les services actifs et les ports ouverts :
# Lister les services actifs
systemctl list-units --type=service --state=running
# Lister les ports en ecoute
ss -tulnp
# Lister les paquets installes (Debian/Ubuntu)
dpkg --get-selections | grep -v deinstall | wc -l
# Lister les paquets (RHEL/Rocky)
rpm -qa | wc -lDesactivez systematiquement les services non necessaires. Sur un serveur web, par exemple, vous n'avez probablement pas besoin de cups (impression), avahi-daemon (decouverte reseau), bluetooth, ou rpcbind (NFS) :
# Desactiver et arreter les services inutiles
sudo systemctl disable --now cups avahi-daemon bluetooth rpcbind
# Supprimer les paquets non necessaires (Debian/Ubuntu)
sudo apt purge -y telnet rsh-client rsh-redone-client \
nis talk inetutils-talk xinetd tftp
# Desactiver les protocoles reseau inutiles
cat >> /etc/modprobe.d/hardening.conf << 'EOF'
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true
EOFVerifiez egalement les fichiers SUID/SGID, qui sont des vecteurs classiques d'escalade de privileges. Retirez le bit SUID de tout binaire qui n'en a pas strictement besoin :
# Trouver tous les fichiers SUID
find / -perm -4000 -type f 2>/dev/null
# Retirer SUID si non necessaire (exemple)
sudo chmod u-s /usr/bin/newgrp /usr/bin/chfn /usr/bin/chsh— Etape 2 : Configurer le pare-feu avec iptables/nftables
Le pare-feu est votre premiere ligne de defense. La politique par defaut doit etre deny all : tout ce qui n'est pas explicitement autorise est bloque. Depuis Debian 11 et RHEL 8, nftables remplace progressivement iptables. Voici une configuration de base avec nftables :
# /etc/nftables.conf - Configuration durcie
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Loopback
iif lo accept
# Connexions etablies
ct state established,related accept
# Drop invalid
ct state invalid drop
# ICMP (limiter le rate)
ip protocol icmp icmp type echo-request \
limit rate 5/second accept
# SSH (port custom 2222)
tcp dport 2222 ct state new limit rate 3/minute accept
# HTTP/HTTPS
tcp dport { 80, 443 } accept
# Log les paquets rejetes
log prefix "[nftables-drop] " flags all counter drop
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}# Activer nftables au demarrage
sudo systemctl enable nftables
# Appliquer la configuration
sudo nft -f /etc/nftables.conf
# Verifier les regles actives
sudo nft list rulesetCompletez le pare-feu reseau par des parametres kernel durcis dans sysctl. Ces parametres protegent contre les attaques de type IP spoofing, ICMP redirect et SYN flood :
# /etc/sysctl.d/99-hardening.conf
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
kernel.randomize_va_space = 2
# Appliquer
sudo sysctl --system— Etape 3 : Durcir SSH — cles uniquement, port custom, fail2ban
SSH est le point d'entree principal pour l'administration des serveurs Linux. C'est aussi la cible numero un des attaques par force brute. Un serveur SSH sur le port 22 avec l'authentification par mot de passe activee recoit en moyenne des milliers de tentatives de connexion par jour. Le durcissement SSH est non negociable.
# /etc/ssh/sshd_config.d/hardening.conf
# Port custom (reduire le bruit)
Port 2222
# Desactiver l'authentification par mot de passe
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
# Desactiver root login
PermitRootLogin no
# Limiter les utilisateurs autorises
AllowUsers deploy admin
# Timeouts et tentatives
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2
# Algorithmes cryptographiques forts uniquement
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
# Desactiver les fonctionnalites inutiles
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
# Banniere d'avertissement
Banner /etc/ssh/bannerInstallez et configurez fail2ban pour bloquer automatiquement les adresses IP qui echouent a s'authentifier :
# Installation
sudo apt install -y fail2ban # Debian/Ubuntu
sudo dnf install -y fail2ban # RHEL/Rocky
# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
banaction = nftables-multiport
[sshd]
enabled = true
port = 2222
logpath = /var/log/auth.log
maxretry = 3
bantime = 86400
# Demarrer
sudo systemctl enable --now fail2ban
# Verifier le statut
sudo fail2ban-client status sshd— Etape 4 : Mettre en place les mises a jour automatiques de securite
Les vulnerabilites non patchees sont la cause numero un des compromissions de serveurs. Les mises a jour de securite doivent etre appliquees automatiquement, sans intervention humaine. Le debat sur les mises a jour automatiques en production est tranche : le risque d'un service qui redemarre est infiniment inferieur au risque d'une exploitation de vulnerabilite connue.
# === Debian/Ubuntu ===
sudo apt install -y unattended-upgrades apt-listchanges
# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "admin@example.com";
# Activer
sudo dpkg-reconfigure -plow unattended-upgrades# === RHEL/Rocky Linux ===
sudo dnf install -y dnf-automatic
# /etc/dnf/automatic.conf
[commands]
upgrade_type = security
apply_updates = yes
random_sleep = 360
[emitters]
emit_via = email
email_from = root@server.example.com
email_to = admin@example.com
# Activer le timer
sudo systemctl enable --now dnf-automatic-install.timer— Etape 5 : Configurer auditd et la journalisation centralisee
Sans journalisation adequate, vous etes aveugle face aux intrusions. auditd est le framework d'audit du noyau Linux : il peut tracer les appels systeme, les acces fichiers, les changements de configuration et les connexions reseau. En complement, la centralisation des logs vers un SIEM garantit qu'un attaquant ne puisse pas effacer ses traces.
# Installation
sudo apt install -y auditd audispd-plugins # Debian
sudo dnf install -y audit # RHEL
# /etc/audit/rules.d/hardening.rules
# Surveiller les modifications de fichiers critiques
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudo_changes
-w /etc/sudoers.d/ -p wa -k sudo_changes
# Surveiller les fichiers de configuration reseau
-w /etc/hosts -p wa -k network_config
-w /etc/sysconfig/network -p wa -k network_config
-w /etc/ssh/sshd_config -p wa -k ssh_config
# Surveiller les montages de systemes de fichiers
-a always,exit -F arch=b64 -S mount -F auid>=1000 \
-F auid!=4294967295 -k mounts
# Surveiller les suppressions de fichiers
-a always,exit -F arch=b64 -S unlink -S unlinkat \
-S rename -S renameat -F auid>=1000 \
-F auid!=4294967295 -k delete
# Surveiller les changements de date/heure
-a always,exit -F arch=b64 -S adjtimex -S settimeofday \
-k time_change
-w /etc/localtime -p wa -k time_change
# Rendre les regles immuables (necessite reboot pour modifier)
-e 2# Charger les regles
sudo augenrules --load
# Verifier le statut
sudo auditctl -s
# Rechercher dans les logs
sudo ausearch -k identity -ts today
sudo aureport --auth --summaryPour la centralisation, configurez rsyslog ou journald pour envoyer les logs vers un serveur central (ELK, Graylog, Splunk ou un SIEM cloud). Cela garantit la preservation des preuves meme si le serveur est compromis.
— Etape 6 : Implementer le controle d'acces avec SELinux/AppArmor
Les permissions Unix classiques (rwx) sont insuffisantes pour proteger un serveur de production. Un processus compromis herite des permissions de l'utilisateur qui l'execute — si c'est root, c'est game over. Les mecanismes de controle d'acces obligatoire (MAC) comme SELinux et AppArmor ajoutent une couche de restriction qui limite ce qu'un processus peut faire, meme s'il tourne en tant que root.
# === SELinux (RHEL/Rocky/CentOS) ===
# Verifier le mode actuel
getenforce
# Passer en mode enforcing
sudo setenforce 1
# Rendre permanent
sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
# Verifier les violations
sudo ausearch -m AVC -ts today
# Generer un module pour autoriser un service bloque
sudo audit2allow -a -M mymodule
sudo semodule -i mymodule.pp
# Lister les booleens SELinux
getsebool -a | grep httpd# === AppArmor (Debian/Ubuntu) ===
# Verifier le statut
sudo apparmor_status
# Mettre un profil en mode enforce
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
# Creer un profil pour un nouveau service
sudo aa-genprof /usr/bin/myapp
# Recharger les profils
sudo apparmor_parser -r /etc/apparmor.d/*
# Voir les logs de violations
sudo dmesg | grep apparmorLe choix entre SELinux et AppArmor depend de votre distribution. Sur RHEL, Rocky Linux et CentOS, SELinux est natif et deja pre-configure — ne le desactivez jamais. Sur Debian et Ubuntu, AppArmor est le choix naturel. Dans les deux cas, le mode enforcing est obligatoire en production. Le mode permissive ne bloque rien, il ne fait que journaliser — c'est un mode de debug, pas de production.
— Etape 7 : Chiffrer les donnees au repos et en transit
Le chiffrement protege vos donnees dans deux scenarios : le vol physique d'un disque ou d'une VM (donnees au repos) et l'interception reseau (donnees en transit). Les deux sont obligatoires pour la conformite RGPD et NIS2.
Chiffrement au repos avec LUKS
# Chiffrer une partition de donnees avec LUKS
sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup luksOpen /dev/sdb1 data_encrypted
sudo mkfs.ext4 /dev/mapper/data_encrypted
sudo mount /dev/mapper/data_encrypted /mnt/data
# Ajouter au fstab pour montage automatique
# (necessite un keyfile ou deverrouillage au boot)
echo '/dev/mapper/data_encrypted /mnt/data ext4 defaults 0 2' \
| sudo tee -a /etc/fstab
# Creer un keyfile pour le deverrouillage automatique
sudo dd if=/dev/urandom of=/root/.luks-keyfile bs=4096 count=1
sudo chmod 400 /root/.luks-keyfile
sudo cryptsetup luksAddKey /dev/sdb1 /root/.luks-keyfileChiffrement en transit : TLS partout
# Generer un certificat avec Let's Encrypt (Certbot)
sudo apt install -y certbot
sudo certbot certonly --standalone -d server.example.com
# Configuration TLS durcie pour Nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
# Headers de securite supplementaires
add_header Strict-Transport-Security "max-age=63072000" always;
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;N'oubliez pas de chiffrer egalement les communications internes entre vos serveurs. Les connexions a la base de donnees, les appels API internes et la synchronisation de fichiers doivent utiliser TLS meme sur un reseau prive. Un attaquant qui a compromis un serveur du reseau interne peut sniffer le trafic non chiffre.
— Etape 8 : Automatiser les audits avec Lynis et les benchmarks CIS
Le durcissement n'est pas un evenement ponctuel, c'est un processus continu. Les configurations derivent, de nouveaux paquets sont installes, des exceptions temporaires deviennent permanentes. Les audits automatises avec Lynis et OpenSCAP permettent de detecter ces regressions avant qu'elles ne deviennent des vecteurs d'attaque.
# Installation de Lynis
sudo apt install -y lynis # Debian/Ubuntu
# OU depuis le depot officiel
cd /opt && sudo git clone https://github.com/CISOfy/lynis.git
# Lancer un audit complet
sudo lynis audit system
# Audit en mode automatise (pour cron)
sudo lynis audit system --cronjob --quiet \
--logfile /var/log/lynis-audit.log
# Verifier le score de durcissement
grep "Hardening index" /var/log/lynis.log# OpenSCAP pour les benchmarks CIS
sudo apt install -y libopenscap8 ssg-debderived # Debian
sudo dnf install -y openscap-scanner \
scap-security-guide # RHEL
# Scanner avec le profil CIS Level 1
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--results /tmp/cis-results.xml \
--report /tmp/cis-report.html \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
# Ouvrir le rapport HTML
# Le rapport detaille chaque controle CIS avec pass/failPlanifiez un audit Lynis hebdomadaire en crontab et envoyez les resultats par email ou vers votre systeme de monitoring. Un score inferieur a 70/100 doit declencher une alerte et une action corrective :
# Crontab : audit Lynis chaque dimanche a 2h du matin
0 2 * * 0 /usr/sbin/lynis audit system --cronjob --quiet \
2>&1 | mail -s "Lynis Audit $(hostname)" admin@example.com
# Script d'alerte si score < 70
#!/bin/bash
SCORE=$(grep "Hardening index" /var/log/lynis.log | \
awk '{print $NF}' | tr -d '[]')
if [ "$SCORE" -lt 70 ]; then
echo "ALERTE: Score Lynis $SCORE sur $(hostname)" | \
mail -s "SECURITE: Score hardening critique" admin@example.com
fiBesoin d'un audit de hardening professionnel ?
Nos ingenieurs DevSecOps auditent vos serveurs Linux, implementent le durcissement et automatisent les controles de conformite CIS. Rapport detaille et plan de remediation inclus.
Demander un audit de hardening →— Checklist finale de durcissement
Utilisez cette checklist pour valider que votre serveur est correctement durci avant la mise en production :
— Conclusion : le hardening comme culture, pas comme projet
Le durcissement d'un serveur Linux n'est pas une tache a cocher et oublier. C'est un processus continu qui doit etre integre dans votre pipeline CI/CD, vos runbooks d'infrastructure et vos processus de revue de securite. Chaque nouveau deploiement, chaque mise a jour majeure, chaque changement de configuration doit declencher une verification du niveau de durcissement.
L'automatisation est la cle. Utilisez des roles Ansible comme dev-sec.os-hardening et dev-sec.ssh-hardening pour appliquer ces 8 etapes de maniere coherente sur l'ensemble de votre parc. Integrez les scans Lynis et CIS dans votre pipeline de deployment : un serveur qui ne passe pas l'audit ne part pas en production.
Le hardening Linux est l'un des meilleurs retours sur investissement en cybersecurite. Avec 2 a 4 heures de travail initial et une automatisation intelligente, vous reduisez drastiquement la surface d'attaque de vos serveurs. Dans un contexte ou les ransomwares et les APT ciblent de plus en plus les infrastructures Linux (en hausse de 75% en 2025 selon les rapports de Mandiant), ce n'est plus une option — c'est une necessite.
Questions frequentes
Vous ne trouvez pas la reponse a votre question ?
Veille cybersecurite
Recevez chaque semaine les dernieres menaces, vulnerabilites et bonnes pratiques directement dans votre boite mail.
Pas de spam. Desinscription en un clic. Environ 1 email par semaine.
— Pret a renforcer votre cybersecurite ?
Rejoignez les entreprises qui font confiance a WebGuard Agency pour proteger leurs actifs numeriques. Premier audit offert.