Audit de sécurité serveur Linux : checklist complète 2026

Commencer par Lynis ? l'audit automatisé

Avant de plonger dans les commandes manuelles, installez Lynis. C'est l'outil d'audit de sécurité Linux de référence : il analyse votre système, le compare aux benchmarks CIS et aux bonnes pratiques, et génère un rapport prioris? avec un score de durcissement.

# Installation
sudo apt install lynis          # Debian/Ubuntu
sudo dnf install lynis          # CentOS/RHEL/Fedora

# Lancer un audit complet
sudo lynis audit system

# Le rapport s'affiche en temps réel et est sauvegardé dans
cat /var/log/lynis.log          # log d?taill?
cat /var/log/lynis-report.dat   # rapport machine-readable

# Score typique : entre 50 et 80/100 sur un serveur non durci
# Objectif : >75 pour un serveur de production

1. Audit des utilisateurs et des droits

Les comptes utilisateurs inutiles ou mal configurés sont souvent le premier vecteur d'attaque. Un compte avec un shell actif mais un propri?taire qui a quitt? l'entreprise il y a 2 ans, c'est une porte ouverte.

# Lister tous les comptes avec un shell actif (hors système)
grep -v "nologin\|false\|sync" /etc/passwd | awk -F: '{print $1, $7}'

# Lister les comptes avec des droits sudo
getent group sudo wheel | tr ',' '\n' | grep -v "^sudo\|^wheel"
sudo -l -U nom_utilisateur      # vérifier les droits d'un utilisateur sp?cifique

# Comptes sans mot de passe (dangereux !)
sudo awk -F: '($2 == "" ) { print $1 }' /etc/shadow

# Comptes avec UID 0 autres que root (tr?s suspect)
awk -F: '($3 == 0) { print $1 }' /etc/passwd

# Vérifier les connexions récentes
last -n 20                      # 20 derni?res connexions
lastb -n 20                     # 20 derni?res tentatives échouées

Actions correctives

• Désactiver les comptes inutiles : sudo usermod -s /usr/sbin/nologin utilisateur
• Verrouiller un compte : sudo passwd -l utilisateur
• Supprimer un compte : sudo userdel -r utilisateur
• Restreindre sudo : ?diter /etc/sudoers avec visudo, éviter NOPASSWD

2. Services r?seau exposés

Chaque port ouvert sur Internet est une surface d'attaque potentielle. La r?gle d'or : un serveur ne devrait exposer que les ports strictement nécessaires ? sa fonction.

# Lister tous les ports en écoute avec le processus associ?
ss -tunlp
# ou
netstat -tunlp

# Ports exposés sur l'interface publique (0.0.0.0 = toutes les interfaces)
ss -tunlp | grep "0.0.0.0"

# Connexions sortantes actives (détecter du trafic suspect)
ss -tunp | grep ESTABLISHED

# Scanner votre propre serveur depuis l'extérieur (vision d'un attaquant)
nmap -sV -p- votre.ip.publique

# Désactiver et masquer un service inutile
sudo systemctl stop nom_service
sudo systemctl disable nom_service
sudo systemctl mask nom_service    # emp?che la rçactivation accidentelle

# Lister tous les services actifs
systemctl list-units --type=service --state=active

3. Permissions et fichiers SUID suspects

Les fichiers avec le bit SUID activ? s'ex?cutent avec les droits de leur propri?taire (souvent root), quel que soit l'utilisateur qui les lance. Les attaquants cherchent des binaires SUID vulnérables pour une ?l?vation de privil?ges.

# Lister tous les fichiers SUID ? comparez avec une baseline connue
find / -perm -4000 -type f 2>/dev/null | sort

# Fichiers world-writable (n'importe qui peut les modifier) ? suspect
find / -perm -0002 -type f 2>/dev/null | grep -v proc | grep -v sys

# Fichiers modifi?s dans les 24 derni?res heures (post-compromission)
find / -mtime -1 -type f 2>/dev/null | grep -v "/proc\|/sys\|/dev\|/run"

# Vérifier l'int?grit? des binaires système avec debsums (Debian/Ubuntu)
sudo apt install debsums
sudo debsums -s    # signale les fichiers modifi?s par rapport aux packages officiels

Permissions des fichiers critiques

# Ces permissions sont les valeurs correctes ? vérifiez les vêtres
stat /etc/passwd      # doit être 644 (rw-r--r--)
stat /etc/shadow      # doit être 640 ou 000 (root:shadow)
stat /etc/sudoers     # doit être 440
stat ~/.ssh           # doit être 700
stat ~/.ssh/authorized_keys  # doit être 600

# Corriger si nécessaire
chmod 644 /etc/passwd
chmod 640 /etc/shadow
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4. Audit de la configuration SSH

SSH est le vecteur d'attaque num?ro un sur les serveurs Linux. Vérifiez que votre configuration est durcie.

# Vérifier la configuration SSH actuelle
sshd -T | grep -E "permitrootlogin|passwordauth|x11forwarding|maxauthtries|port"

# Valeurs attendues pour un serveur durci :
# permitrootlogin no
# passwordauthentication no
# x11forwarding no
# maxauthtries 3
# port != 22 (recommandé)

# Vérifier les clés autorisées et leur format
cat ~/.ssh/authorized_keys   # chercher des clés inconnues !

5. Audit du pare-feu

# UFW (Ubuntu/Debian)
sudo ufw status verbose          # r?gles actives
sudo ufw status numbered         # r?gles num?rot?es pour modification facile

# iptables
sudo iptables -L -n -v           # toutes les r?gles
sudo iptables -L INPUT -n -v     # r?gles entrantes uniquement

# nftables (systèmes modernes)
sudo nft list ruleset

# Vérifier que le pare-feu est actif au d?marrage
sudo systemctl is-enabled ufw
sudo systemctl is-enabled iptables

R?gles minimales recommandées

# Politique par défaut : tout bloquer sauf l'autoris?
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser uniquement les ports nécessaires
sudo ufw allow 2222/tcp comment "SSH"
sudo ufw allow 443/tcp comment "HTTPS"
sudo ufw allow 80/tcp comment "HTTP"

# Activer
sudo ufw enable
sudo ufw status verbose

6. Gestion des mises ? jour et des CVE

# Vérifier les mises ? jour disponibles
sudo apt update && apt list --upgradable   # Debian/Ubuntu
sudo dnf check-update                      # CentOS/RHEL

# Mises ? jour de sécurité uniquement (sans les fonctionnalités)
sudo apt upgrade --with-new-pkgs           # Debian/Ubuntu
sudo dnf update --security                 # CentOS/RHEL

# Activer les mises ? jour automatiques de sécurité
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

# Vérifier les packages vulnérables avec debsecan (Debian)
sudo apt install debsecan
debsecan --suite $(lsb_release -cs) --format detail | head -40

7. Audit des logs et du monitoring

Sans logs, vous êtes aveugle. Sans alertes, vous rçagissez après le dèsastre. Un serveur de production doit avoir une stratégie de logging et d'alerte claire.

# Vérifier que rsyslog ou journald est actif
systemctl is-active rsyslog
systemctl is-active systemd-journald

# Analyser les logs d'authentification
sudo grep "Failed password" /var/log/auth.log | tail -20
sudo grep "Invalid user" /var/log/auth.log | tail -20
sudo grep "session opened" /var/log/auth.log | tail -20

# Chercher des connexions root réussies (devrait être vide si PermitRootLogin no)
sudo grep "Accepted.*root" /var/log/auth.log

# Analyser les logs système pour des erreurs critiques
sudo journalctl -p err -n 50   # 50 derni?res erreurs
sudo journalctl --since "1 hour ago" -p warning

Centraliser et alerter

• Envoyer les logs vers un serveur centralisé (ELK, Graylog, ou votre SIEM)
• Configurer des alertes sur les patterns critiques (connexion root, nouvelles clés SSH, changements sudoers)
• Conserver les logs au moins 90 jours (conformité RGPD et analyse forensique)

Checklist d'audit complète

Conclusion

Un audit de sécurité n'est pas un ?v?nement ponctuel mais un processus continu. Lancez Lynis r?guli?rement, automatisez la v?rification des mises ? jour, et mettez en place des alertes sur les événements critiques. Un serveur bien audit? n'est pas invulnérable, mais il est significativement plus difficile ? compromettre, et vous saurez quand quelqu'un essaie.