Le blogouille de Caro et Nico

Entre famille, sport et aventures !

Lutte anti slowhack / botnet hack.

Bon alors… quand on gère des serveurs qui sont connectés sur internet, malgré le firewall, dès qu’on a une bonne série de services (SSH, FTPs, HTTPs, IMAPs, SMTPs, POP3s, etc…) on se retrouve avec un PAQUET de tentative d’intrusions, du genre plusieurs à la minute… à force cela devient fatiguant et fait tourner les machines pour rien.

En utilisant une bonne combinaison d’outils, on arrive à bien contenir les attaques basiques de type brute force venant de la même IP. En particulier avec les outils Fail2Ban et DenyHosts. Par contre depuis plusieurs mois je fait face à un nouveau type de problème, des milliers d’addresses IP différentes qui tentent toute une combinaison de login et mot de passe différents, genre « classique », mais à chaque fois, une seule unique IP tente une combinaison, puis quelques secondes après, c’est une autre IP qui tente une combinaison légèrement différente. Ca a l’air bien foutu, mais difficile à bloquer, en fait il y a quelques parades. 

Par exemple Dovecot logge se genre de choses

2017-11-12 14:44:08 auth-worker(7082): Info: sql(eleanor,101.187.110.152): unknown user (given password: password)

 

Et voilà l ‘adresse IP 101.187.110.152 qui tente la combinaison eleanor/password … je serais curieux de savoir ce qui se passe si ce script d’un botnet tombe sur un login valide, à priori je penche pour de l’envoi de spam.

En tout cas, voilà comment j’ai procédé pour limiter les ennuis :

Augmenté la fréquence de synchronisation de DenyHosts, à 5 minutes. Il y a une limite hardcodée de 50 hôtes à chaque sync, mais cela fait tout de même 15000 hôtes par jour à récupérer qui seront bloqués, en mettant un filet large de sélection, genre DOWNLOAD_THRESHOLD à 2 et SYNC_DOWNLOAD_RESILIENCY = 5h

Ensuite sur fail2ban, on peut mettre quelques filtres REGEX pour capturer ces tentatives de botnet sommes toutes basiques. Genre :

,<HOST>\): unknown user \(given password: 123456
,<HOST>\): unknown user \(given password: password
,<HOST>\): unknown user \(given password: web
,<HOST>\): unknown user \(given password: russ

Et en ajoutant quelques filtres sur les mots de passe basiques, on récupère un paquet d’adresse IP (j’en ai eu environ 70000 par jour !!) et avec un bon ban genre de plusieurs semaines, et ben voili voilou, bien tranquille, le nombre de de tentatives d’intrusions a complètement diminué, par un facteur 100.

Bon ban ! 

 

Comme quoi lire les logs ca fait du bien

Bon, suite à plantage de Apache2 et MySQL, un petit peu d’administration de serveur s’imposait. En lisant les logs systèmes on apprend plein de choses et on trouve plein de petits trucs qui déconnent….

En gros :

Des attaques brute force à répétition via WordPress sur les comptes users wordpress, qui surchargent le système et font sauter Apache2 et/ou MySQL. De plus le système semble configuré incorrectement sur la memory_limit entre php, Apache2, plugin suhosin et WordPress.

Solution : installation de fail2ban sous Debian.installation de plusieurs plugin WordPress de securité, comme WP fail2ban et WP Apocalypse Meow.
Correction de bug (timestamp error) dans DenyHosts pour le rendre fonctionnel à nouveau.
Modification de RoundCube pour logger dans syslog.
Augmentation de la mémoire max allouée à PHP dans Apache à 256M (au lieu de 128M).

Et voilà un serveur à nouveau sain et rapide, avec en prime une meilleure résistance aux attaques brute force.