Retour sur sécurisation serveur suite attaque

Des timeouts sur le serveur depuis quelques temps…
Je m’aperçois qu’un script que j’avais écrit l’été dernier, censé filtrer les IP étrangères, sort en erreur.
La charge du serveur était assez forte, du coup l’ensemble des service souffrait, des timeouts dans la tronche sans arret…

Ces requetes infernales viennent des 4 coins du monde, tapent sur WIMS (pour se servir de la puissance de calcul du serveur en s’appuyant sur des modules de calcul de wims), les logs de haproxy en témoignent:

La charge du serveur était assez élevée, > 5. J’ai effectué les réglages suivants:

• changement du sous-domaine de wims pour que les requetes soient redirigées dans le vide (dans la zone dns)
• compilation d’une version plus récente de haproxy:

• ajout d’un regex fail2ban afin d’ajouter les IP qui font chier dans iptables, dans le fichier /etc/fail2ban/filter.d/wims.conf

[Definition]

failregex = ^.*haproxy\[[0-9]+\]: <HOST>:.* "(GET |POST )\/wims.*(lang=de|lang=cn|lang=es).* HTTP\/1.1"$
ignoreregex =

• un petit tail sur /var/log/fail2ban.log pour vérifier que cela fonctionne

• suppression des 45K sessions sur wims qui devaient pas aider dans wims/sessions
• suppression du sous-domaine wims.divingeek.com dans la zone dns en esperant ne plus recevoir les requetes dans les 24h le temps de la propagation
• la commande top qui aide énormément pour surveiller la charge serveur et qui inquiète dès que cela remonte un peu trop vite

• les requetes étaient redirigées vers le backend par défaut de haproxy, serveur web, qui répondait, donc augmentait le load à son tour…
  • donc mise à jour du wordpress,
  • redirection des requetes entrantes avec le sous-domaine wims vers un backend qui n’aboutit pas dans haproxy, le temps que fail2ban et la propagation fassent le job…

ça devrait tenir, il va falloir que je fournisse aux élèves le nouveau nom de domaine de WIMS, qui est bien utile en salle informatique!