Un serveur compromis ne tombe presque jamais en panne
C’est l’erreur classique.
On imagine qu’un serveur piraté va ralentir brutalement, crasher ou afficher des erreurs évidentes.
En réalité, les compromissions modernes sont silencieuses.
Un attaquant cherche rarement à casser votre serveur.
Il veut :
- un accès persistant,
- des ressources (CPU, réseau),
- ou un point de rebond vers d’autres machines.
Résultat : le serveur continue de fonctionner normalement, parfois pendant des semaines ou des mois.
La vraie question n’est donc pas “mon serveur est-il lent ?”
Mais plutôt :
“Y a-t-il quelque chose qui ne devrait pas être là ?”
Les premiers signes faibles (ceux que tout le monde ignore)
Avant de parler d’outils complexes, commençons par l’observation.
Charge système inhabituelle
Un CPU légèrement occupé en permanence, sans pic clair :
top
htopUn processus inconnu qui consomme 5–15 % en continu mérite toujours un coup d’œil.
Activité réseau étrange
Connexions sortantes régulières vers des IP inconnues :
ss -tunapUn serveur web qui communique vers l’extérieur sans raison précise est suspect par défaut.
Connexions SSH alors que personne ne se connecte
Même chose ici :
lastDes connexions à 3h du matin, depuis des pays inhabituels, doivent immédiatement alerter.
Vérifier les utilisateurs et accès SSH
Comptes utilisateurs ajoutés discrètement
Un attaquant crée souvent un compte “normal”, discret, sans droits évidents.
cat /etc/passwdCherchez :
- des utilisateurs récents,
- des shells
/bin/bashou/bin/shinattendus, - des UID inhabituels.
Clés SSH injectées
Classique et très efficace :
ls -la /root/.ssh/
ls -la /home/*/.ssh/Toute clé que vous ne reconnaissez pas est un signal rouge immédiat.
Historique des connexions SSH
Les logs ne mentent jamais (quand ils existent encore) :
grep "Accepted" /var/log/auth.logNotez les IP, les horaires, les utilisateurs.
Processus malveillants courants sur Linux
Les processus malveillants essaient de se fondre dans la masse.
Affichage de l’arborescence des processus
ps auxfIndices suspects :
- processus lancés depuis
/tmp,/dev/shm,/var/tmp - noms très génériques (
cron,kworker,systemd-helper) - processus sans binaire clair
Qui parle sur le réseau ?
lsof -iUn binaire inconnu qui ouvre des connexions TCP sortantes est rarement légitime.
Ports ouverts sans raison
Un serveur compromis écoute souvent… mais discrètement.
ss -lntupPuis, pour vérifier localement :
nmap localhostPosez-vous une question simple pour chaque port :
“Ai-je volontairement ouvert ce service ?”
Si la réponse est non → investigation immédiate.
Vérifier les tâches planifiées (persistance)
La persistance est la priorité d’un attaquant.
Crontab utilisateur et système
crontab -l
ls /etc/cron.*Cherchez :
- scripts inconnus,
- commandes curl / wget,
- exécutions fréquentes (toutes les minutes).
Timers systemd
Beaucoup plus discrets que cron :
systemctl list-timersFichiers et emplacements à surveiller en priorité
Certains dossiers sont des nids à malwares :
/tmp/var/tmp/dev/shm/run
Commande simple :
find /tmp /var/tmp /dev/shm -type f -lsUn binaire exécutable dans ces dossiers est hautement suspect.
Les logs : souvent négligés, toujours utiles
Même partiels, les logs donnent des indices :
- authentification
- redémarrages de services
- erreurs silencieuses
journalctl -p err
journalctl --since "2 days ago"Que faire si un doute sérieux existe ?
C’est le point le plus important.
❌ Ne pas tenter de “nettoyer” à chaud
❌ Ne pas redémarrer immédiatement
❌ Ne pas supprimer les fichiers suspects sans comprendre
✔️ Isoler le serveur (firewall, réseau)
✔️ Sauvegarder les données importantes
✔️ Sauvegarder les journaux
✔️ Prévoir une réinstallation propre
Un serveur compromis ne redevient jamais fiable à 100 % sans réinstallation.
Comment éviter que cela se reproduise
La prévention reste plus simple que la détection :
- Accès SSH strict (clés uniquement)
- Utilisateurs limités
- Services minimaux
- Surveillance basique mais continue
- Journaux centralisés
- Mises à jour régulières
Un serveur bien durci réduit drastiquement la surface d’attaque.
