Connexion
Comment j’ai déjoué une attaque sur mon site WordPress
Jetpack m’a alerté ce matin que mon site syskb.com a été temporairement inaccessible cette nuit.
Jetpack Monitor a détecté une interruption de service. Votre site s’est déconnecté ou a cessé de répondre pendant environ 18 minutes…
J’ai tellement rarement de problème que par acquis de conscience je me suis connecté sur mon VPS hébergé chez IONOS avec PuTTy et j’ai fait quelques vérifications d’usage …
1. Je vérifie si le serveur a redémarré
Première piste : peut-être que le serveur plante et redémarre tout seul ? Je lance :
uptimeL’obtiens le retour suivant :
06:41:47 up 64 days, 13:00, 1 user, load average: 2.84, 2.76, 2.18Aucun redémarrage depuis 64 jours : le problème vient d’ailleurs. Mais la charge moyenne du système est élevée, je n’ai que 2 coeurs sur mon VPS est il consomme plus de 2 coeurs, ce qui peut ralentir voire bloquer le site. C’ets une bonne piste à étudier !
2. Diagnostic des processus gourmands
J’utilise top pour voir en direct ce qui consomme des ressources :
topJe constate que mariadbd (la base de données MariaDB) consomme énormément de CPU, avec parfois plus de 70%. Apache est aussi sollicité. Mon intuition : une attaque ou un robot malveillant.
3. Analyse des logs Apache
Je fouille les logs pour comprendre d’où viennent les requêtes grâce à la commande :
sudo tail -n 50 /var/log/apache2/access.logEt là surprise, je suis victime d’une attaque automatisée, très probablement un bot qui tente des injections SQL ou des spams sur les commentaires WordPress.
- L’IP
192.145.28.169envoie des dizaines de requêtes par seconde - Requêtes comme :
select sleep(15)OR 5*5=25 --wp-comments-post.php→ spam de commentaires
- Tentatives d’exploitation ciblant des plugins WordPress (
wp-table-builder,Jetpack) - Attaques de type SQL Injection retardée (ex.
sleep(15)) → surcharge intentionnelle du serveur
Ces requêtes malveillantes saturent Apache, MariaDB, et donc mon VPS → Jetpack pense parfois que mon site est hors ligne alors qu’il est saturé.
4. Première tentative de blocage avec iptables
Je tente de bloquer l’adresse IP avec iptables :
sudo iptables -A INPUT -s 192.145.28.169 -j DROPMais surprise mon VPS n’a pas iptables installé par défaut … oui je sais ce n’est pas bien 
sudo: iptables: command not found5. Je bascule vers nftables
Debian utilise maintenant nftables comme système de pare-feu par défaut. Je décide de l’utiliser pour bloquer l’IP en question.
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0\; }
sudo nft add rule inet filter input ip saddr 192.145.28.169 dropJe vérifie que la règle est bien enregistrée :
sudo nft list rulesetEt je rends le tout persistant au redémarrage :
sudo sh -c 'nft list ruleset > /etc/nftables.conf'
sudo systemctl enable nftables
sudo systemctl start nftables6. Vérification et soulagement
Je surveille les logs d’Apache à nouveau, et je remarque qu’aucune nouvelle requête de cette IP ne passe. Le trafic est beaucoup plus léger, le CPU redescend, et mon site redevient stable.
J’utilise de nouveau top pour voir si la consommation à baissée :
topEt bonne nouvelle la consommation de CPU est redescendue sous les 10%.
Mon intuition était bonne, une attaque ou un robot malveillant saturait mon serveur.
Conclusion
Ce retour d’expérience m’a appris deux choses :
- Jetpack Monitor est précieux pour détecter des interruptions
- nftables est puissant et flexible, même s’il est un peu plus verbeux qu’iptables
Et surtout : il ne faut pas toujours accuser son hébergeur ou WordPress quand un site ralentit ou tombe. Un bon diagnostic permet souvent de trouver la vraie cause.
Cet article original intitulé Comment j’ai déjoué une attaque sur mon site WordPress a été publié la première sur SysKB.
