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.