Détecter une intrusion sur un serveur

Une compromission ne se voit pas toujours. Le site peut répondre normalement pendant qu'un processus lit vos fichiers ou envoie du spam depuis votre IPv6. L'objectif d'une détection n'est pas de tout comprendre immédiatement, mais de constater, de contenir et de préserver les preuves avant de décider.

Avant de toucher à la machine

Notez l'heure, les symptômes et les changements récents. Si la compromission est active, coupez l'exposition (pare-feu, arrêt du service web) plutôt que la machine : un redémarrage efface la mémoire et une réinstallation détruit les indices. Si le dashboard propose un snapshot, prenez-le avant toute modification.

Copiez les journaux ailleurs dès que possible. Un attaquant root peut les modifier sur place ; une copie exportée reste une preuve exploitable.

Comptes et accès

getent passwd | awk -F: '$3==0 {print $1}'
last -a | head -30
lastlog
sudo grep -r . /etc/sudoers /etc/sudoers.d
sudo find /root /home -name authorized_keys -exec ls -l {} \;

La première commande liste les comptes avec l'UID 0 : il ne devrait y avoir que root. last et lastlog montrent les connexions récentes, y compris celles qui ne correspondent pas à vos horaires. Vérifiez les clés autorisées, les comptes sudoers ajoutés et les shells modifiés.

Processus, réseau et persistance

ps auxf
sudo ss -tulpn
sudo ss -tnp state established

Cherchez un processus au nom plausible mais au chemin inhabituel, un binaire supprimé encore actif (ls -l /proc/PID/exe affiche (deleted)) ou une connexion sortante vers une adresse inconnue. Les attaquants persistants ajoutent souvent une tâche cron, un timer systemd ou un service :

crontab -l
sudo ls -l /etc/cron.*
systemctl list-timers --all
systemctl list-unit-files --state=enabled
cat /etc/ld.so.preload

Sur un serveur web, cherchez les fichiers récents dans les dossiers d'upload et les appels obfusqués : find /var/www -type f -mtime -7 -ls. Un fichier .php déposé dans un dossier d'images est un signal fort.

Journaux et outils de contrôle

journalctl --since "2026-11-01" -p warning
journalctl -u ssh --since today | grep -E "Accepted|Failed"

Les journaux Nginx et PHP révèlent les requêtes POST répétées vers un même script, les inclusions de fichiers distants et les chaînes encodées. Après installation, debsums -c et dpkg -V signalent des binaires système modifiés ; rkhunter --check et lynis audit system complètent l'inventaire, sans garantir la propreté d'une machine compromise : un rootkit peut fausser leurs résultats.

Décider et reconstruire

Si seul un site est touché et que le point d'entrée est identifié, nettoyez les fichiers, mettez à jour l'application et changez les secrets. Si l'attaquant a obtenu root, la seule réponse fiable est une réinstallation depuis le dashboard. Restaurez uniquement les données vérifiées, jamais les binaires ni les configurations, puis faites tourner tous les mots de passe, clés SSH et jetons.

Après reconstruction, contrôlez :

• les comptes UID 0 et les clés autorisées ;
• les ports en écoute avec ss -tulpn ;
• les tâches planifiées et les unités systemd ;
• les journaux des premiers jours.

Une réinfection rapide signale un point d'entrée oublié, souvent une sauvegarde restaurée trop vite.