ITSkillsCenter
Cybersécurité

Linux sécurité et hardening en production : guide pratique

11 min de lecture

Lecture : 11 minutes · Niveau : intermédiaire-avancé · Mise à jour : avril 2026

Un serveur Linux fraîchement installé n’est pas sécurisé. Il est acceptable par défaut pour démarrer, mais loin de l’état « production sécurisée ». Ce guide pose une checklist appliquée par les équipes sérieuses, en partant des gains les plus rapides.

Voir aussi → Linux administration avancée pour PME : guide pratique.

Sommaire

  1. Modèle de menace : à quoi se préparer
  2. Durcir SSH
  3. Pare-feu : UFW ou nftables
  4. fail2ban contre le brute-force
  5. Mises à jour automatiques de sécurité
  6. Utilisateurs et permissions
  7. AppArmor / SELinux
  8. Audit avec Lynis
  9. Surveillance et journalisation
  10. FAQ

1. Modèle de menace : à quoi se préparer

Pour un serveur Linux exposé à Internet (web, API, VPN, mail), les menaces typiques sont :

  • Brute-force SSH automatisé (bots scannant les ports 22 ouverts)
  • Exploitation de vulnérabilités logicielles non patchées (CVE publiques)
  • Compromission de comptes via mots de passe faibles ou réutilisés
  • Mauvaises configurations (permissions trop ouvertes, services inutiles exposés)
  • Élévation de privilèges une fois un accès initial obtenu
  • Persistance (rootkits, scheduled tasks injectées)

Le hardening adresse ces vecteurs en couches : moins de surface d’attaque, durcissement des accès, détection rapide.

2. Durcir SSH

Étapes essentielles

sudo nano /etc/ssh/sshd_config

Modifier ou ajouter :

# Pas de connexion root directement
PermitRootLogin no

# Authentification par clé seulement (pas de mot de passe)
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Limiter les utilisateurs autorisés
AllowUsers admin deploy

# Pas de connexion sans mot de passe ni clé
PermitEmptyPasswords no

# X11 et tunnels désactivés si pas utilisés
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

# Limites de connexion
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Algorithmes modernes seulement
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Tester et appliquer

# Vérifier la config avant de redémarrer
sudo sshd -t

# Recharger
sudo systemctl restart ssh

# IMPORTANT : ouvrir une SECONDE session SSH dans un autre terminal
# avant de fermer celle en cours, pour valider que la config marche.

Générer une clé SSH moderne

Côté poste client :

# Ed25519 : moderne, court, performant (recommandé)
ssh-keygen -t ed25519 -C "ton-email@exemple.com"

# Copier sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@serveur

Port custom : utile ?

Changer le port SSH (par exemple 2222) ne bloque pas un attaquant déterminé mais réduit massivement le bruit des bots automatiques. À combiner avec les autres mesures, pas en remplacement. C’est de la « security through obscurity » — utile en réduction de bruit, jamais comme défense principale.

3. Pare-feu : UFW ou nftables

UFW (Uncomplicated Firewall) est suffisant et simple pour la majorité des PME.

sudo apt install ufw

# Règles par défaut : tout bloquer en entrée, tout autoriser en sortie
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Ouvrir les services nécessaires
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 'Nginx Full'  # 80 + 443

# Limiter SSH (anti-brute-force basique)
sudo ufw limit 22/tcp

# Activer
sudo ufw enable

# Voir l'état
sudo ufw status verbose

ufw limit bloque automatiquement une IP qui essaie plus de 6 connexions en 30 secondes. Bonus simple contre les bots.

Pour des règles plus complexes, nftables natif Linux est plus puissant mais demande plus de connaissances.

4. fail2ban contre le brute-force

fail2ban scrute les logs et bannit automatiquement les IP suspectes.

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Configuration personnalisée

/etc/fail2ban/jail.local (à créer, ne pas modifier jail.conf) :

[DEFAULT]
# Durée du ban
bantime = 1h

# Fenêtre d'observation
findtime = 10m

# Nombre d'échecs avant ban
maxretry = 5

# IPs jamais bannies (whitelist : ton IP fixe par exemple)
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 24h

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

sudo systemctl restart fail2ban

# Voir les bans en cours
sudo fail2ban-client status sshd

# Débannir une IP
sudo fail2ban-client unban 1.2.3.4

5. Mises à jour automatiques de sécurité

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Configurer dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "admin@exemple.com";
Unattended-Upgrade::MailReport "on-change";

Pour des serveurs critiques : Automatic-Reboot "false" et redémarrer manuellement après vérification. Pour des serveurs non-critiques : true avec une heure choisie.

# Activer
sudo systemctl enable --now unattended-upgrades

# Vérifier que ça tourne
sudo unattended-upgrade --dry-run --debug

Voir aussi → systemd services en production : tutoriel pratique pour des timers personnalisés de maintenance.

6. Utilisateurs et permissions

Audit des comptes

# Comptes humains (UID >= 1000) avec shell connectable
awk -F: '($3 >= 1000) && ($7 !~ /(nologin|false)/) {print}' /etc/passwd

# Comptes avec mot de passe défini
sudo awk -F: '$2 !~ /^[!*]/ {print $1}' /etc/shadow

# Sudoers
sudo grep -E "^(ALL|%|[a-z])" /etc/sudoers /etc/sudoers.d/*

Bonnes pratiques

  • Pas de partage de comptes : chaque admin a le sien
  • Sudo ciblé : préférer %admins ALL=(ALL) /usr/bin/systemctl restart nginx à ALL complet
  • Désactiver les comptes inutilisés : sudo usermod -L user (lock) ou sudo usermod -e 1 user (expire)
  • Logs sudo : /var/log/auth.log doit être surveillé

Permissions critiques

# Fichiers sensibles
sudo chmod 600 /etc/shadow /etc/gshadow /etc/sudoers
sudo chmod 644 /etc/passwd /etc/group

# /tmp avec sticky bit (déjà par défaut sur la plupart)
sudo chmod 1777 /tmp

# Trouver les fichiers SUID/SGID (potentiellement risqués)
sudo find / -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null

Examiner manuellement la liste SUID : si un binaire inutile pour la PME est listé, retirer le bit (sudo chmod -s /path/to/binary).

7. AppArmor / SELinux

Les MAC (Mandatory Access Control) limitent ce qu’un service peut faire même si compromis.

AppArmor (Ubuntu/Debian par défaut)

# Statut
sudo aa-status

# Voir les profils chargés
sudo aa-status | head -30

# Profils en mode complain (logge sans bloquer) :
sudo aa-complain /etc/apparmor.d/*

# Profils en mode enforce (bloque vraiment) :
sudo aa-enforce /etc/apparmor.d/*

Sur Ubuntu, AppArmor est actif par défaut avec des profils pour Nginx, MySQL, etc. Vérifier qu’ils sont en enforce plutôt que complain.

SELinux (RHEL/Rocky/Fedora)

# Statut
sestatus

# Mode permissif (logue mais ne bloque pas)
sudo setenforce 0

# Mode enforce
sudo setenforce 1

Sur RHEL/Rocky, SELinux est en enforcing par défaut. Ne pas le désactiver « pour faire marcher l’app », au contraire : créer un profil correct.

8. Audit avec Lynis

Lynis est un auditeur de sécurité Linux mature (cisofy.com/lynis). Il scanne le système et propose des recommandations classées par priorité.

sudo apt install lynis
sudo lynis audit system

# Rapport détaillé
sudo cat /var/log/lynis-report.dat
sudo cat /var/log/lynis.log

Le score Lynis (« Hardening index ») donne une métrique de progression :

  • < 50 : système faible, beaucoup à faire
  • 50-75 : moyen, des améliorations rapides possibles
  • 75-90 : bon, axé sur le fine-tuning
  • 90+ : excellent, niveau hardening sérieux

À refaire après chaque changement majeur.

Audit des paquets vulnérables

# Vérifier les CVE des paquets installés
sudo apt install debsecan
sudo debsecan --suite $(lsb_release -cs)

# Alternative : vuls (plus complet)
# https://github.com/future-architect/vuls

9. Surveillance et journalisation

Surveiller les connexions

# Connexions actuelles
who
w

# Historique des connexions
last -n 50

# Tentatives échouées
sudo grep "Failed password" /var/log/auth.log | tail -50

# Connexions par IP
sudo grep "Accepted publickey" /var/log/auth.log | awk '{print $11}' | sort | uniq -c

auditd pour traçabilité fine

sudo apt install auditd
sudo systemctl enable --now auditd

# Surveiller les modifications de /etc/passwd
sudo auditctl -w /etc/passwd -p wa -k passwd_changes

# Voir les événements
sudo ausearch -k passwd_changes

Centralisation

Pour plus de 5 serveurs, centraliser les logs (journald-remote, Loki + Grafana, ou ELK) facilite énormément la détection d’incidents corrélés.

Voir aussi → Performance Linux : troubleshooting méthodique pour le côté observabilité performance.

10. FAQ

Désactiver le mot de passe SSH coupe l’accès si je perds ma clé. Comment me protéger ?

Avoir toujours plusieurs clés SSH (poste principal + secours sur clé USB chiffrée + console fournisseur). Garder un accès console hors-bande (KVM IPMI, console fournisseur cloud) qui permet une réinitialisation. Documenter le processus de récupération.

Mises à jour automatiques avec redémarrage : risque pour la production ?

C’est un compromis. Approche pragmatique : Automatic-Reboot "true" à 03h pour les serveurs non-critiques (sites vitrine, environnements internes). Pour les serveurs critiques (production e-commerce, base de données), redémarrage manuel programmé après vérification, avec maintenance window communiquée.

Faut-il chiffrer les disques d’un serveur dédié ?

Pour un serveur en datacenter : oui pour les données sensibles (LUKS sur volume de données). Limite : si la machine reboote, il faut déverrouiller manuellement ou avoir une solution de déverrouillage automatique (clevis + Tang). Pour un VPS chez un cloud public : moins critique car le provider gère les disques, mais reste utile pour les volumes de données sensibles.

AppArmor en mode complain partout, est-ce suffisant ?

Non. complain log les violations sans les bloquer. C’est utile pour développer un profil ou debugger, mais en production le but est enforce. Une violation enregistrée mais non bloquée laisse passer l’attaque.

Mon serveur est-il déjà compromis ? Comment vérifier ?

Indices : nouveaux processus inconnus (ps aux), connexions sortantes suspectes (ss -tunap), fichiers récents dans /tmp ou /var/tmp, scheduled tasks non-déclarées (crontab -l pour tous les users), modifications non-tracées dans /etc. Outils dédiés : chkrootkit, rkhunter, lynis. En cas de doute fort : isoler le serveur du réseau et investiguer depuis un environnement propre.

Faut-il bannir tous les pays sauf le sien ?

Pour des services internes uniquement consommés localement, le geo-fencing par pays via le pare-feu réduit la surface. Pour un site web public, c’est contre-productif. À adapter au cas d’usage. Listes IP par pays disponibles via ipdeny.com et autres sources.

Articles liés (cluster Linux administration)

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.

#audited #Hardening #linux #sécurité #SSH #Sysadmin
Besoin d'un site web ?

Confiez-nous la Création de Votre Site Web

Site vitrine, e-commerce ou application web — nous transformons votre vision en réalité digitale. Accompagnement personnalisé de A à Z.

À partir de 250.000 FCFA
Parlons de Votre Projet
Publicité

Articles Similaires