Comment auditer un serveur Linux en production

Un serveur en production n’est pas une machine à optimiser : c’est un système dont l’indisponibilité a un coût. L’audit doit donc commencer par la question « que se passe-t-il si ce serveur tombe ? », et non par la liste des paquets à mettre à jour.

Axe 1 : sécurité et exposition

L’objectif est de savoir précisément ce qui est accessible depuis Internet, et de vérifier que les règles censées protéger le serveur sont réellement actives.

1. Recenser les ports réellement à l’écoute et vérifier que les services exposés sont intentionnels.
2. Contrôler que l’accès SSH est restreint, de préférence par clé, et que l’authentification par mot de passe est désactivée.
3. Vérifier que le pare-feu ne dépend pas d’une règle activée en mémoire, mais d’une configuration persistée.
4. S’assurer que les mises à jour de sécurité sont appliquées et qu’un redémarrage peut être planifié sans urgence.
5. Examiner les comptes et les clés SSH existants : un compte oublié est une porte d’entrée.

# Services réellement à l'écoute
ss -tulpn

# Règles de pare-feu persistantes (nftables ou ufw)
ufw status verbose 2>/dev/null || nft list ruleset 2>/dev/null

# Comptes et clés SSH présents
awk -F: '$3 >= 1000 {print $1}' /etc/passwd
ls -la ~/.ssh/authorized_keys 2>/dev/null

# Mises à jour de sécurité disponibles
apt list --upgradable 2>/dev/null | head -20

Axe 2 : capacité de restauration

C’est l’axe le plus important et le plus souvent traité en dernier. Une sauvegarde non testée n’est pas une stratégie de reprise : c’est un fichier dont on découvre l’inutilité au moment précis d’en avoir besoin.

• La base de données est-elle sauvegardée ? Et la méthode est-elle cohérente avec le moteur utilisé ? Une copie à chaud d’une base transactionnelle peut produire un fichier inutilisable.
• Le code et la configuration sont-ils sauvegardés ? Dépôt, variables d’environnement, configuration Nginx, secrets applicatifs.
• La restauration a-t-elle déjà été testée ? Sur une machine, et pas seulement en théorie.
• Les sauvegardes sont-elles hors du serveur ? Une sauvegarde conservée sur le même serveur ne survit pas à la perte de celui-ci.
• Quels sont les délais réalistes ? Une reprise qui prend deux heures et une reprise qui en prennent vingt-quatre ne sont pas la même stratégie.

# Age et volume des sauvegardes
ls -lh /var/backups/ 2>/dev/null
df -h /var/backups 2>/dev/null

# Dernière sauvegarde de base réussie (exemple)
ls -lt /var/backups/mysql/ 2>/dev/null | head

# La commande qui compte vraiment : restaurer
mysql -u user -p nom_base < /var/backups/mysql/derniere-sauvegarde.sql

Axe 3 : ressources et services

On mesure l’état du serveur avant de décider s’il faut ajouter de la puissance. Un serveur saturé et un serveur sous-dimensionné ne produisent pas les mêmes symptômes, et les mêmes corrections ne conviennent pas.

# Vue d'ensemble immédiate
uptime
free -m
df -h

# Processus les plus gourmands
ps aux --sort=-%mem | head -15

# Activité disque
iostat -x 1 3 2>/dev/null || vmstat 1 3

# Occupation des inodes : une cause fréquente de « disque plein »
df -i | head -10

Axe 4 : supervision et journaux

Un serveur non supervisé ne tombe pas d’un coup : il devient inutilisable petit à petit, jusqu’au moment où quelqu’un s’en aperçoit. La supervision n’a pas besoin d’être complexe pour être utile ; quelques métriques et une alerte pertinente valent mieux qu’un tableau de bord complet jamais consulté.

# Occupation du volume système
df -h /
df -i /

# Journaux qui grossissent sans rotation
du -sh /var/log/* 2>/dev/null | sort -h | tail -10
journalctl --disk-usage 2>/dev/null

# Workers PHP : nombre et consommation
ps -o pid,ppid,pcpu,pmem,rss,etime -C php-fpm 2>/dev/null | head -20

La supervision minimale utile pour un site d’entreprise tient en quelques points : espace disque, mémoire disponible, activité CPU, expiration du certificat TLS et résultat de la dernière sauvegarde. Si l’un de ces cinq éléments n’est pas surveillé, c’est là que se situe le prochain incident non anticipé.

Ce que doit produire un audit

• Un état des risques : ce qui expose la production, classé par impact réel et par probabilité.
• Une liste de corrections bornées : chaque action avec son effet attendu, son risque et son temps de mise en œuvre.
• Un ordre d’exécution : ce qui peut être fait immédiatement, ce qui demande une fenêtre de maintenance, ce qui nécessite une décision d’investissement.
• Un état des restaurations : ce qui a été vérifié, et ce qui reste à vérifier.

Quand faire appel à un spécialiste

Un audit externe devient pertinent quand la production porte une activité réelle et qu’aucune personne n’a la responsabilité complète du serveur, quand les sauvegardes n’ont jamais été testées, ou quand plusieurs incidents ont déjà eu lieu sans que leur cause commune ait été identifiée. Si l’application elle-même est lente, le diagnostic d’une application Laravel lente permet de vérifier d’abord que le problème ne vient pas du code.

• Linux
• Nginx
• Sécurité
• Sauvegardes
• Monitoring