Checklist sécurité : 10 points à vérifier sur tout serveur Linux

Pourquoi une checklist de sécurité systématique ?

La sécurité d'un serveur Linux ne se résume pas à l'installation d'un firewall. C'est un ensemble de couches complémentaires qui, prises individuellement, semblent anodines, mais dont l'absence d'une seule peut compromettre l'intégralité de votre infrastructure. Un serveur mal configuré est une porte ouverte pour les attaquants, qu'il s'agisse de bots automatisés ou d'intrusions ciblées.

Cette checklist regroupe 10 vérifications critiques à effectuer sur tout serveur Linux en production. Pour chaque point, vous trouverez la commande de vérification, le résultat attendu et la correction à appliquer si le contrôle échoue. L'objectif est d'avoir un processus reproductible que vous pouvez exécuter sur chaque nouveau serveur ou lors d'un audit périodique.

1. sécuriser SSH : clés uniquement, port modifié, root désactivé

Le service SSH est la première cible des attaquants. Un serveur exposé sur le port 22 avec l'authentification par mot de passe reçoit en moyenne des milliers de tentatives de brute force par jour. Trois mesures sont indispensables : désactiver l'authentification par mot de passe, modifier le port par défaut et interdire la connexion root directe.

# Verifier la configuration SSH
grep -E "^(PasswordAuthentication|PermitRootLogin|Port)" /etc/ssh/sshd_config

Attendu : PasswordAuthentication no, PermitRootLogin no, et un port différent de 22.

Correction : Modifiez /etc/ssh/sshd_config avec les valeurs ci-dessus, puis rechargez le service avec systemctl reload sshd. Assurez-vous d'avoir déposé votre clé publique dans ~/.ssh/authorized_keys avant de désactiver les mots de passe. Consultez le guide complet OpenSSH Server pour une configuration détaillée.

2. Firewall actif avec politique deny par défaut

Un firewall correctement configuré bloque tout le trafic non explicitement autorisé. Sans politique deny by default, chaque service que vous lancez est potentiellement accessible depuis l'extérieur.

# Verifier le statut UFW et la politique par defaut
sudo ufw status verbose

Attendu : Status active, politique par défaut deny (incoming), et uniquement les ports nécessaires ouverts (SSH, HTTP/HTTPS).

Correction : Activez UFW et configurez la politique par défaut :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp  # votre port SSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Pour une configuration complète, référez-vous au tutoriel UFW.

3. Mises à jour automatiques configurées

Les failles de sécurité connues sont exploitées dans les heures qui suivent leur publication. Les mises à jour automatiques de sécurité réduisent drastiquement cette fenêtre d'exposition.

# Verifier que unattended-upgrades est actif (Debian/Ubuntu)
systemctl is-enabled unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Attendu : Le service est enabled et le fichier contient APT::Periodic::Unattended-Upgrade "1";.

Correction : Installez et configurez les mises à jour automatiques :

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

Vérifiez dans /etc/apt/apt.conf.d/50unattended-upgrades que la ligne Unattended-Upgrade::Allowed-Origins inclut bien les mises à jour de sécurité de votre distribution.

4. Utilisateur non-root avec sudo

Travailler en root au quotidien multiplie les risques : une commande erronée, un script malveillant ou une compromission de session aura un impact maximal. Un utilisateur dédié avec des privilèges sudo limités est la norme.

# Verifier les utilisateurs du groupe sudo
getent group sudo
# Verifier que root n'a pas de mot de passe actif
sudo passwd -S root

Attendu : Au moins un utilisateur non-root dans le groupe sudo. Le statut du mot de passe root devrait être L (locked).

Correction : Créez un utilisateur dédié et verrouillez root :

sudo adduser deployer
sudo usermod -aG sudo deployer
sudo passwd -l root

5. Permissions des fichiers sensibles

Des permissions trop larges sur les fichiers système critiques permettent à n'importe quel utilisateur local de lire des informations sensibles, comme les hashs de mots de passe ou les clés privées SSH du serveur.

# Verifier les permissions des fichiers critiques
stat -c "%a %U %G %n" /etc/shadow /etc/gshadow /etc/ssh/sshd_config
ls -la /etc/ssh/ssh_host_*_key

Attendu : /etc/shadow en 640 (propriétaire root, groupe shadow). Les clés privées SSH en 600, propriété de root exclusivement.

Correction :

sudo chmod 640 /etc/shadow /etc/gshadow
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*_key.pub
sudo chmod 600 /etc/ssh/sshd_config

6. Services inutiles désactivés

Chaque service actif est une surface d'attaque supplémentaire. Un serveur de production ne devrait exécuter que les services strictement nécessaires à son rôle. Le gestionnaire systemd permet de lister et désactiver facilement les services superflus.

# Lister tous les services actifs
systemctl list-unit-files --type=service --state=enabled
# Lister les ports en ecoute
ss -tlnp

Attendu : Uniquement les services nécessaires sont enabled. Aucun port inattendu en écoute.

Correction : Désactivez les services inutiles :

# Exemple : desactiver un service non necessaire
sudo systemctl stop cups.service
sudo systemctl disable cups.service
sudo systemctl mask cups.service

Les services couramment inutiles sur un serveur : cups (impression), avahi-daemon (découverte réseau), bluetooth, ModemManager.

7. Fail2ban ou équivalent actif

Fail2ban surveille les logs d'authentification et bannit automatiquement les adresses IP qui échouent à se connecter de manière répétée. C'est une couche de défense indispensable contre le brute force, même si elle ne remplace pas les clés SSH.

# Verifier le statut de Fail2ban
sudo systemctl is-active fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Attendu : Le service est active, la jail sshd est activée avec un nombre de Currently banned supérieur ou égal à zéro.

Correction : Installez et configurez Fail2ban :

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo systemctl enable --now fail2ban

Consultez le guide Fail2ban pour configurer les jails, les durées de bannissement et les notifications par email.

8. Logs centralisés et surveillés

Des logs non surveillés ne servent à rien. Vous devez pouvoir détecter une intrusion ou un comportement anormal dans un délai raisonnable. La centralisation des logs et la mise en place d'alertes sont essentielles.

# Verifier que journald est fonctionnel et persiste les logs
journalctl --disk-usage
cat /etc/systemd/journald.conf | grep Storage
# Verifier la presence de logs recents
journalctl --since "1 hour ago" --no-pager | tail -20

Attendu : Storage=persistent dans la configuration journald. Les logs sont récents et le stockage n'est pas saturé.

Correction : Configurez la persistance des logs et une rotation adaptée :

# Activer la persistance
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
# Configurer la rotation
sudo journalctl --vacuum-size=500M

Pour un serveur de production, envisagez une solution de centralisation comme rsyslog vers un serveur distant, ou un stack ELK/Loki pour l'analyse.

9. Backups testés et fonctionnels

Avoir des backups ne suffit pas : il faut les tester régulièrement. Un backup qui n'a jamais été restauré n'est qu'une promesse, pas une garantie. Vérifiez l'existence, la fraîcheur et l'intégrité de vos sauvegardes.

# Verifier la date du dernier backup (adapter le chemin)
ls -lh /var/backups/ | head -10
# Verifier l'integrite d'une archive
tar -tzf /var/backups/latest-backup.tar.gz > /dev/null 2>&1 && echo "OK" || echo "CORRUPTED"
# Verifier l'espace disponible
df -h /var/backups/

Attendu : Le dernier backup date de moins de 24 heures (ou selon votre politique). L'archive est lisible sans erreur. L'espace disque est suffisant pour au moins deux cycles de sauvegarde.

Correction : Mettez en place un script de backup automatisé via cron et testez la restauration sur un environnement de staging au moins une fois par mois. Documentez la procédure de restauration et le temps nécessaire (RTO).

10. Audit régulier avec Lynis

Lynis est un outil d'audit de sécurité open source qui analyse votre système en profondeur et attribue un score de durcissement. Il couvre des centaines de vérifications que cette checklist ne peut pas toutes lister. C'est le complément idéal à vos vérifications manuelles.

# Installer Lynis
sudo apt install lynis
# Lancer un audit complet
sudo lynis audit system
# Consulter le score et les suggestions
grep "Hardening index" /var/log/lynis.log
grep "Suggestion" /var/log/lynis-report.dat | head -20

Attendu : Un score de durcissement (Hardening Index) supérieur à 70 pour un serveur correctement configuré. Aucune alerte critique (Warning) non traitée.

Correction : Parcourez les suggestions de Lynis et traitez-les par ordre de priorité. Planifiez un audit mensuel automatisé via cron et comparez les scores dans le temps pour détecter les régressions. Le tutoriel Lynis détaille l'interprétation des résultats et les corrections les plus courantes.

Automatiser avec un script d'audit

Exécuter cette checklist manuellement sur chaque serveur est fastidieux et source d'erreurs. La bonne pratique consiste à créer un script Bash qui automatise ces 10 vérifications et génère un rapport structuré.

#!/bin/bash
# audit-securite.sh - Checklist automatisee
echo "=== Audit de securite - $(hostname) - $(date) ==="

echo "[1] SSH Configuration"
grep -E "^(PasswordAuthentication|PermitRootLogin|Port)" /etc/ssh/sshd_config

echo "[2] Firewall"
sudo ufw status | head -5

echo "[3] Mises a jour automatiques"
systemctl is-enabled unattended-upgrades 2>/dev/null || echo "NON CONFIGURE"

echo "[4] Utilisateur sudo"
getent group sudo

echo "[5] Permissions fichiers sensibles"
stat -c "%a %n" /etc/shadow /etc/ssh/sshd_config

echo "[6] Services actifs"
systemctl list-unit-files --type=service --state=enabled --no-pager | wc -l

echo "[7] Fail2ban"
sudo systemctl is-active fail2ban 2>/dev/null || echo "INACTIF"

echo "[8] Logs"
journalctl --disk-usage 2>/dev/null

echo "[9] Backups"
ls -lh /var/backups/ 2>/dev/null | head -5

echo "[10] Lynis"
lynis --version 2>/dev/null || echo "NON INSTALLE"

echo "=== Fin de l'audit ==="

Rendez ce script exécutable avec chmod +x audit-securite.sh et planifiez-le en cron hebdomadaire. Redirigez la sortie vers un fichier ou envoyez-la par email pour garder un historique. Avec le temps, enrichissez ce script en ajoutant des vérifications spécifiques à votre infrastructure : certificats TLS, état des conteneurs Docker, versions des applications déployées.

La sécurité est un processus continu, pas un état final. En appliquant cette checklist de manière systématique et en l'automatisant, vous construisez une base solide qui réduit considérablement votre surface d'attaque et vous permet de détecter les régressions avant qu'elles ne soient exploitées.