Fail2Ban – Un point de sécurité à mettre en place

Bonjour à tous

Dans tous ce que je dois faire, et que je ne fais jamais le temps de faire, j’ai priorisé certains points comme les aspects sécurités dans un premier temps.

Fail2ban lit les logs de divers serveurs (SSH, Apache, FTP…) à la recherche d’erreurs d’authentification répétées et ajoute une règle iptables pour bannir l’adresse IP de la source.

Niveau installation rien de plus simple :

aptitude install fail2ban

Puis tout ce passe dans le dossier /etc/fail2ban, voyons maintenant la configuration :

Un fichier /etc/fail2ban/fail2ban.conf incluant les paramètres de log et de socket entre autre de fail2ban en lui même.
Un dossier /etc/fail2ban/action.d contenant les fichiers des actions en cas de bannissement.
Un dossier /etc/fail2ban/filter.d contenant les différents filtres pour les règles de filtrages.
Un fichier /etc/fail2ban/jail.conf contenant les paramètre principaux.

Ces deux derniers qui vont devoir être modifiés pour être adapté aux besoins de chacun.

Nous allons dans un premier temps rajouter de nouveaux filtres dans le dossier /etc/fail2ban/filter.d pour pouvoir gérer différents bannissements non connu par défaut par fail2ban.

Pour la protection des attaques contre la plus connue des interfaces de management de MySQL : apache-phpmyadmin

vi /etc/fail2ban/filter.d/apache-phpmyadmin.conf

# Fail2Ban configuration file
# Bans bots scanning for non-existing phpMyAdmin installations on your webhost.
[Definition]
failregex = [[]client []] File does not exist: .*(PMA|phpmyadmin|myadmin|mysql|mysqladmin|sqladmin|
                                                  mypma|admin|xampp|mysqldb|mydb|db|pmadb|phpmyadmin1|myadmin2)
ignoreregex =

Pour la protection des attaques d’un scanner de failles qui s’appelle Dfind. : apache-w00tw00t

vi /etc/fail2ban/filter.d/apache-w00tw00t.conf

[Definition]
failregex = ^ -.*"GET \\/w00tw00t\\.at\\.ISC\\.SANS\\.DFind\\:\\).*".*

Dans un second temps nous allons configurer le fichier principal de fail2ban : /etc/fail2ban/jail.conf

# The DEFAULT allows a global definition of the options. They can be override in each jail afterwards.

[DEFAULT]

ignoreip = 127.0.0.1 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
bantime  = 86400
maxretry = 3
backend = polling
destemail = log@domaine.com

# ACTIONS

banaction = iptables-multiport
mta = sendmail
protocol = tcp

action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
              %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
               %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]
action = %(action_mwl)s

# JAILS

[ssh]

enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 2

[pam-generic]

enabled = false filter = pam-generic port = all banaction = iptables-allports port = anyport logpath = /var/log/auth.log maxretry = 3

[xinetd-fail]

enabled = false filter = xinetd-fail port = all banaction = iptables-multiport-log logpath = /var/log/daemon.log maxretry = 2

[ssh-ddos]

enabled = true port = ssh filter = sshd-ddos logpath = /var/log/auth.log maxretry = 3 # HTTP servers

[apache]

enabled = true port = http,https filter = apache-auth logpath = /var/log/apache*/*error.log maxretry = 3

[apache-multiport]

enabled = true port = http,https filter = apache-auth logpath = /var/log/apache*/*error.log maxretry = 3

[apache-noscript]

enabled = true port = http,https filter = apache-noscript logpath = /var/log/apache*/*error.log maxretry = 3

[apache-overflows]

enabled = true port = http,https filter = apache-overflows logpath = /var/log/apache*/*error.log maxretry = 2

[apache-phpmyadmin]

enabled = true port = http,https filter = apache-phpmyadmin logpath = /var/log/apache*/*error.log maxretry = 2

[apache-w00tw00t]

enabled = true filter = apache-w00tw00t action = iptables[name=Apache-w00tw00t,port=80,protocol=tcp] logpath = /var/log/apache2/users/*access*.log maxretry = 1 # FTP servers

[vsftpd]

enabled = false port = ftp,ftp-data,ftps,ftps-data filter = vsftpd logpath = /var/log/vsftpd.log maxretry = 6

[proftpd]

enabled = true port = ftp,ftp-data,ftps,ftps-data filter = proftpd logpath = /var/log/auth.log maxretry = 6

[wuftpd]

enabled = false port = ftp,ftp-data,ftps,ftps-data filter = wuftpd logpath = /var/log/auth.log maxretry = 6 # Mail servers

[postfix]

enabled = true port = smtp,ssmtp filter = postfix logpath = /var/log/mail.log

[couriersmtp]

enabled = true port = smtp,ssmtp filter = couriersmtp logpath = /var/log/mail.log

[courierauth]

enabled = true port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s filter = courierlogin logpath = /var/log/mail.log

[sasl]

enabled = true port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s filter = sasl logpath = /var/log/mail.log # DNS Servers

[named-refused-udp]

enabled = false port = domain,953 protocol = udp filter = named-refused logpath = /var/log/named/security.log

[named-refused-tcp]

enabled = false port = domain,953 protocol = tcp filter = named-refused logpath = /var/log/named/security.log

Utilisant un panel ISPCP sur un de mes serveurs j’ai du adapter les fichiers de logs et remplacer

/var/log/apache*/*error.log par /var/log/apache2/users/*error.log

/var/log/proftpd/proftpd.log par /var/log/auth.log

Sur un autre frontal, j’utilise NGINX et j’ai aussi adapter le filtrage avec les règles suivantes :

[nginx]
enabled = true
port    = http,https
filter  = apache-auth
logpath = /var/log/nginx*/*error.log
maxretry = 3

[nginx-noscript]

enabled = true port = http,https filter = apache-noscript logpath = /var/log/nginx*/*error.log maxretry = 3

[nginx-overflows]

enabled = true port = http,https filter = apache-overflows logpath = /var/log/nginx*/*error.log maxretry = 2

Ne pas oublier de relancer le tout

/etc/init.d/fail2ban restart

Pour vérifier que tout fonctionne bien et que le serveur est bien lancé, on peut effectuer la commande :

fail2ban-server status
2011-11-18 19:39:24,736 fail2ban.server : INFO   Starting Fail2ban v0.8.4
2011-11-18 19:39:24,737 fail2ban.server : INFO   Starting in daemon mode

Pour voir les jails actifs on utilise la commande :

fail2ban-client status
Status
|- Number of jail:    13
`- Jail list:        apache-w00tw00t, apache-noscript, postfix, ssh-ddos, apache-multiport, apache-overflows,
            couriersmtp, ssh, sasl, apache, courierauth, proftpd, apache-phpmyadmin

Pour voir les ip qui sont bannies via un jail par exemple le ssh dans notre cas, on exécute la commande :

fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list:    /var/log/auth.log
|  |- Currently failed:    0
|  `- Total failed:    28
`- action
   |- Currently banned:    4
   |  `- IP list:    1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4
   `- Total banned:    11

Tout les autres options disponibles sont visibles via la commande :

fail2ban-client

A l’utilisation on se rends compte qu’il y a énormément de tentative de connexion non désirées sur les frontaux.

Pour information, j’utilise Munin pour mal de graph de mes systèmes, un plugin pour fail2ban est intégré à la dernière version.

Pour sa mise en place rien de plus simple, je vous donne les trois modifications à apporter à votre serveur :

ln -s /usr/share/munin/plugins/fail2ban /etc/munin/plugins/

Ajouter les deux lignes dans le fichier /etc/munin/plugin-conf.d/munin-node

[fail2ban]
user root

Et enfin relancer le node sur le serveur en question :

/etc/init.d/munin-node restart

Ci dessous un exemple de graph généré par Munin pour le service fail2ban.

Merci de votre lecture et à bientôt pour un nouvel article.

6 commentaires

Letoine20 janvier 2012 21 h 41 min

Bonjour,
Je débute avec tout cela et il y a un truc que je ne comprend pas :'(
Lorsque je rentre dans mon jail.conf les trois jails de Nginx, mon fail2ban refuse de redémarrer.
Auriez-vous quelques minutes pour m’aider un brin s’il vous plait?

Je suis sur archlinux, ai un nginx avec php-fpm et je reçois pas mal de requêtes illégitimes du genre :
"169.139.19.203 - - [20/Jan/2012:18:21:31 +0100] "\x07qq\xE0\xFF\x8A\xC3\x82`\x7F\xF9iC\x04@X\xA4n" 400 173 "-" "-""
(pas de pitié pour l’ip comme il n’y a pas de pitié pour mon pauvre petit serveur perso)

Letoine

Répondre

cschwartz21 janvier 2012 9 h 42 min

Bonjour

Dans un premier temps êtes vous certain de la configuration dans le fichier jail.conf.
Avez vous bien les fichiers dans les répertoires annoncés par la configuration et formater comme ci dessous au niveau du nommage :

[nginx] enabled = true port = http,https filter = apache-auth logpath = /var/log/nginx*/*error.log maxretry = 3 [nginx-noscript] enabled = true port = http,https filter = apache-noscript logpath = /var/log/nginx*/*error.log maxretry = 3 [nginx-overflows] enabled = true port = http,https filter = apache-overflows logpath = /var/log/nginx*/*error.log maxretry = 2

Bonne journée et merci de l’intérêt que vous porter à mon blog

Je reste à votre disposition pour d’autres questions.

Thor

Répondre

Letoine21 janvier 2012 21 h 11 min

Bonsoir,

Merci de votre réponse :-). J’ai bien ces lignes exactes que j’ai ajouté en fin de fichier dans jail.conf.
Le reste de la configuration (le filtrage de ssh) fonctionne tant que je garde ces paramètres à enabled = false. Dès lors que je tente de lui faire filtrer nginx, rc.d start fail2ban me renvoi un joli FAIL (sans autre explication, à moins qu’il y ait un log ailleurs mais je ne sais pas où).

Concernant mes fichiers de log de nginx, ils sont bien dans /var/log/nginx/ et avec ou sans les * cela ne passe pas. J’ai bien essayé de même de passer par le lien symbolique /etc/nginx/logs/ mais ça ne passe pas plus :'(.

Si vous avez une idée, ou autre chose à vérifier ce serai génial 🙂

Bonne soirée et bon week end à vous !

Letoine

Répondre

cschwartz22 janvier 2012 0 h 29 min

Re bonsoir

Il y a des logs de fail2ban dans le fichier
/var/log/fail2ban.log
A voir s’il contient une indication quand à l’erreur rencontrée…

Bon week end et tenez moi au courant des investigations…

Répondre

Letoine23 janvier 2012 14 h 04 min

Bonjour Thor,

Merci de votre investissement dans la résolution de mon problème ;-).
J’ai bien regardé au fail2ban.log et je n’y ai rien trouvé… Je me suis alors dit que j’étais peut-être le pire débutant que j’ai vu de ma vie (oui je suis un peu schizophrène); je m’explique :
J’ai l’habitude que si un deamon est en fonction, il me le rappelle lorsque je tente de le lancer…
En clair, j’ai fais un « rc.d stop fail2ban » et ce petit mignon c’est arrêté. En gros, il était déjà lancé !
Fouettez-moi, c’est le moment !

En tout état de cause, j’ai récupéré votre fichier de conf avec lequel j’ai remplacé le mien (après sauvegarde) et j’ai ajouté vos deux services supplémentaires car je reçois également pas mal de tests phpmyadmin et w00tw00t.

En outre, j’espère que ces sécurités vont m’aider aussi contre les tentatives d’injections de shellcode – voir premier commentaire – (qui est l’enregistrement dans mes logs qui me fait le plus peur – ce qui me rassure est de voir qu’ils sont bien rejetés par nginx par une erreur 400).

Merci beaucoup à vous, je suis débutant j’assume et même si je ne suis pas masochiste j’accepte tous les coups de fouet !

Letoine

Répondre

cschwartz24 janvier 2012 18 h 12 min

Bonsoir Letoine

Ben les erreurs ça arrive à tous le monde.

L’essentiel c’est que cela fonctionne et qu’il fail2ban jail bien les attaques.

Bonne continuation

Répondre

ThorAndCo

Fail2Ban – Un point de sécurité à mettre en place