Cet article m’a donné l’opportunité de me remémorer mon usage plus ou moins ésotérique de fail2ban :
- Les attaques dictionnaires sur Sendmail ne sont que trop courantes
failregex = sm-mta\[[0-9]+\]: [^:]+: \[<HOST>\]: possible SMTP attack: command=AUTH - Si les spammeurs insistent, Sendmail commence par les ralentir. S’ils insistent trop,
failregex = sm-mta\[[0-9]+\]: ruleset=check_relay, arg1=[^,]+, arg2=[^,]+, relay=[^ ]+ \[<host>\], reject=421 4\.3\.2 Connection rate limit exceeded\. - Avec la configuration par défaut de Debian, Suhosin n’a pas (encore ?) produit de faux positif. Armé de cette confiance :
failregex = suhosin\[[. 0-9]+\]: ALERT - .* \(attacker '<HOST>', - iptables peut être configuré pour calmer les ardeurs des outils qui ouvrent une pléthore de connexions HTTP. Étape suivante pour les plus pénibles d’entre eux :
failregex = kernel: \[[. 0-9]+\] HTTP_DoS IN=eth0 OUT= MAC=[^ ]+ SRC=<host> DST=[^ ]+ LEN=[^ ]+ TOS=[^ ]+ PREC=[^ ]+ TTL=[^ ]+ ID=[^ ]+ (DF )?PROTO=TCP SPT=[^ ]+ DPT=80 WINDOW=[^ ]+ RES=[^ ]+ SYN
Autres leçons apprises avec plus ou moins de douleur :
- Il y a un problème de concurrence au démarrage de fail2ban (au moins dans son incarnation 0.8.3), qui peut être évité en plaçant des délais aléatoires comme indiqué dans le bug Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554162.
- Les scripts qui définissent les règles de Firewall sont bien avisés de d’abord arrêter fail2ban, appliquer les règles, puis démarrer fail2ban.