Un site pris n'est généralement pas défiguré. La défiguration est rare parce qu'elle met fin à l'accès ; ce qui est courant, ce sont des pages de spam, des redirections qui ne se déclenchent que pour les visiteurs venus d'un moteur de recherche, et du courrier envoyé depuis votre serveur. Pour vous, connecté et tapant l'adresse directement, tout semble en ordre.
Les signaux
- Des résultats de recherche sur votre domaine que vous n'avez pas écrits.
- Du courrier parti de votre serveur qui rebondit en quantités inexplicables.
- Un bond du processeur ou du trafic sortant sans bond des visiteurs.
- Un visiteur qui signale une redirection que vous n'arrivez pas à reproduire.
- Votre hébergeur ou un navigateur qui met en garde contre le site.
Quatre commandes
# 1. files changed in the last week, ignoring the ones that should change
find /var/www/site -type f -mtime -7 -not -path '*/storage/*' -not -path '*/cache/*' | head -50
# 2. PHP where PHP has no business being
find /var/www/site/uploads /var/www/site/public/img -name '*.php*' 2>/dev/null
# 3. the shapes an injected shell takes
grep -rEl 'eval\(|base64_decode\(|gzinflate\(|assert\(\$' /var/www/site --include='*.php' | head
# 4. logins that succeeded
sudo grep "Accepted" /var/log/auth.log | tail -20Comparez à quelque chose de fiable
Si le code est dans git, la réponse la plus rapide du monde est git status sur le serveur : tout ce qui est modifié ou non suivi et que vous n'avez pas mis là est votre réponse en une ligne. Pour un CMS, retéléchargez la même version et comparez-lui les fichiers du cœur.
La base compte aussi
Le contenu injecté vit souvent dans la base plutôt que dans les fichiers, et c'est pourquoi un scan de fichiers propre prouve moins qu'on ne le croit — voir Un maliciel dans la base, pas dans les fichiers.
