Comment j’ai déjoué une attaque sur mon site WordPress

par

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 :

uptime

L’obtiens le retour suivant :

06:41:47 up 64 days, 13:00,  1 user,  load average: 2.84, 2.76, 2.18

Aucun 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 :

top

Je 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.log

Et 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.169 envoie 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 DROP

Mais surprise mon VPS n’a pas iptables installé par défaut … oui je sais ce n’est pas bien 😁

sudo: iptables: command not found

5. 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 drop

Je vérifie que la règle est bien enregistrée :

sudo nft list ruleset

Et je rends le tout persistant au redémarrage :

sudo sh -c 'nft list ruleset > /etc/nftables.conf'
sudo systemctl enable nftables
sudo systemctl start nftables

6. 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 :

top

Et 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. 😉

Laisser un commentaire