--- categories: web security title: Howto Fail2Ban ... * Documentation : * Rôle Ansible : # Howto Fail2Ban [Fail2Ban](https://www.fail2ban.org) est un outil pour limiter les attaques par brute force : il scanne en permanence des journaux pour détecter des anomalies répétitives et bannir les adresses IP coupables via [IPTables](HowtoIPTables). Nous l'utilisons souvent pour les erreurs d'authentification répétées sur des services publics comme SMTP, POP, IMAP ou FTP. On peut également être amené à l'utiliser pour SSH mais c'est plus rare car il est évidemment préférable de limiter directement l'accès via [IPTables](HowtoIPTables). ## Installation ~~~ # apt install fail2ban # fail2ban-client -V 0.11.2 ~~~ ## Configuration Fichiers de configuration : ~~~ /etc/fail2ban ├── fail2ban.conf ├── jail.conf ├── jail.local ├── jail.d │ └── defaults-debian.conf ├── action.d │ ├── apf.conf │ ├── badips.conf │ ├── blocklist_de.conf │ […] ├── fail2ban.d ├── filter.d │ ├── 3proxy.conf │ ├── apache-auth.conf │ ├── apache-badbots.conf │ […] ├── paths-common.conf ├── paths-debian.conf └── paths-opensuse.conf ~~~ Fail2Ban repose sur des règles de filtrage définies dans `/etc/fail2ban/filter.d/` et des actions dans `/etc/fail2ban/action.d/`. On définit ensuite des **jails**, combinaisons d'une règle de filtrage et d'une ou plusieurs actions. Voici la jail nommée _sshd_ (attention, en Debian 8 elle se nommait _ssh_) : ~~~{.ini} [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 findtime = 600 bantime = 600 ~~~ Cette jail va surveiller le fichier `/var/log/auth.log` via la règle de filtrage `/etc/fail2ban/filter.d/sshd.conf` : s'il détecte la correspondance 5 fois en 10 minutes, il va utiliser l'action par défaut, à savoir l'action `/etc/fail2ban/action.d/iptables-multiport.conf` qui va ajouter une règle _iptables_ pour bannir le port concerné pendant 10 minutes. **Attention, cette jail _sshd_ est activée par défaut à l'installation via le fichier `jail.d/defaults-debian.conf`** Les paramètres par défaut sont : ~~~{.ini} maxretry = 5 findtime = 600 banaction = iptables-multiport bantime = 600 ignoreip = 127.0.0.1/8 ~~~ > *Note* : en Debian 8, le paramètre par défaut de *maxretry* est `maxretry = 3` Les paramètres par défaut et un certain nombre de jails (non activées à part _sshd_) sont définies dans `/etc/fail2ban/jail.conf`, si l'on veut ajouter ou modifier des paramètres ou des jails, il faut utiliser le fichier `/etc/fail2ban/jail.local` ou des fichiers `/etc/fail2ban/jail.d/*.conf` Pour dumper la configuration courante : ~~~ # fail2ban-client -d ['set', 'loglevel', 3] ['set', 'logtarget', '/var/log/fail2ban.log'] [...] ~~~ ## Administration Fail2Ban est un démon en Python, on peut s'assurer qu'il tourne bien sur un système : ~~~ $ ps auwx | grep fail2ban root 24173 0.00.2 185048 12176 ? Sl 16:16 0:03 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid ~~~ On peut lister les jails actives : ~~~ # fail2ban-client status Status |- Number of jail: 1 `- Jail list: ssh ~~~ Et l'on doit les retrouver au niveau d'iptables : ~~~ # iptables -L -n ~~~ ### fail2ban-client De nombreuses commandes sont possibles avec `fail2ban-client` pour lister des informations ou modifier des paramètres. Pour lister l'état de la jail _ssh_ : ~~~ # fail2ban-client status ssh Status for the jail: ssh |- filter | |- File list: /var/log/auth.log | |- Currently failed: 0 | `- Total failed: 6 `- action |- Currently banned: 1 | `- IP list: 192.0.2.42 `- Total banned: 1 ~~~ Pour dé-bannir l'adresse IP 192.0.2.42 de la jail _ssh_ : ~~~ # fail2ban-client set ssh unbanip 192.0.2.42 ~~~ Pour lister les informations de la jail _ssh_ : ~~~ # fail2ban-client get ssh maxretry 6 # fail2ban-client get ssh findtime 600 # fail2ban-client get ssh bantime 600 # fail2ban-client get ssh ignoreip These IP addresses/networks are ignored: `- 127.0.0.1/8 # fail2ban-client get ssh addaction iptables-multiport # fail2ban-client get ssh failregex The following regular expression are defined: [...] ~~~ On pourra mettre à jour les paramètres d'une jail à chaud avec `set`. Ça évite un couteux redémarrage de Fail2ban. ~~~ # fail2ban-client set ssh bantime 300 ~~~ ## Ajouter ses propres jails On peut bien sûr ajouter ses propres _jails_ en ajoutant dans le fichier `jail.local`, un exemple : ~~~{.ini} [custom-1234] enabled = true port = http,https filter = accesslog-custom-1234 logpath = /var/log/access.log maxretry = 5 findtime = 180 bantime = 86400 ignoreip = 127.0.0.1/8 192.0.2.42 action = iptables-multiport sendmail[dest=jdoe@example.com] ~~~~ > *Attention* : en cas d'action liée à iptables (ce qui est le défaut), le nom de la jail ne doit pas excéder 20 caractères ! ### Règles de filtrage Les règles de filtrage sont définies dans `/etc/fail2ban/filter.d/` : ~~~ 3proxy.conf apache-noscript.conf couriersmtp.conf exim.conf lighttpd-auth.conf openwebmail.conf proftpd.conf selinux-ssh.conf squid.conf webmin-auth.conf apache-auth.conf apache-overflows.conf cyrus-imap.conf exim-spam.conf mysqld-auth.conf pam-generic.conf pure-ftpd.conf sendmail-auth.conf sshd.conf wuftpd.conf apache-badbots.conf assp.conf dovecot.conf freeswitch.conf nagios.conf perdition.conf qmail.conf sendmail-reject.conf sshd-ddos.conf xinetd-fail.conf apache-common.conf asterisk.conf dropbear.conf groupoffice.conf named-refused.conf php-url-fopen.conf recidive.conf sieve.conf suhosin.conf apache-modsecurity.conf common.conf ejabberd-auth.conf gssftpd.conf nginx-http-auth.conf postfix.conf roundcube-auth.conf sogo-auth.conf uwimap-auth.conf apache-nohome.conf courierlogin.conf exim-common.conf horde.conf nsd.conf postfix-sasl.conf selinux-common.conf solid-pop3d.conf vsftpd.conf ~~~ On peut écrire ses propres règles de filtrage en s'appuyant sur [les expressions régulières Python](https://docs.python.org/3/library/re.html) pour détecter la variable __. Exemple d'une règle : ~~~{.ini} [Definition] failregex = warning: \[\]: authentication failed: ignoreregex = ~~~ Pour tester une règle : ~~~ $ fail2ban-regex auth.log /etc/fail2ban/filter.d/evolix-test.conf ~~~ Afin d'obtenir des informations supplémentaires - dans le cas où on cherche les heures de connexion d'une adresse IP particulière - on peut utiliser les options `-v` et/ou `--print-all-matched`. On peut aussi tester avec une date : ~~~ $ fail2ban-regex '2017-05-20 10:10:10 foo' 'warning: \[\]: authentication failed:' [...] Failregex: 0 total [...] $ fail2ban-regex '2017-05-20 10:10:10 [192.0.2.42]: authentication failed:' '\[\]: authentication failed:' [...] Failregex: 1 total |- #) [# of hits] regular expression | 1) [1] \[\]: authentication failed: [...] ~~~ ### Actions Les actions sont définies dans `/etc/fail2ban/action.d/` : ~~~ apf.conf firewallcmd-ipset.conf iptables.conf iptables-xt_recent-echo.conf osx-ipfw.conf sendmail-whois-lines.conf badips.conf firewallcmd-new.conf iptables-ipset-proto4.conf mail-buffered.conf pf.conf shorewall.conf blocklist_de.conf hostsdeny.conf iptables-ipset-proto6-allports.conf mail.conf route.conf ufw.conf bsd-ipfw.conf ipfilter.conf iptables-ipset-proto6.conf mail-whois.conf sendmail-buffered.conf complain.conf ipfw.conf iptables-multiport.conf mail-whois-lines.conf sendmail-common.conf dshield.conf iptables-allports.conf iptables-multiport-log.conf mynetwatchman.conf sendmail.conf dummy.conf iptables-blocktype.conf iptables-new.conf osx-afctl.conf sendmail-whois.conf ~~~ Si l'on ne précise pas d'action, l'action sera par défaut _iptables-multiport_ (définie dans `jail.conf`) : ~~~{.ini} banaction = iptables-multiport ~~~ Exemple pour bannir et déclencher l'envoi d'un email : ~~~{.ini} action = iptables-multiport sendmail[dest=jdoe@example.com] ~~~ ## Exemples ### SSH invalid user Le but de cette règle est de bannir immédiatement si une connexion SSH a lieu sur un utilisateur invalide. Très efficace contre les robots qui font des bruteforce massivement distribués. On ajoute la règle `filter.d/sshd-invaliduser.conf` : ~~~{.ini} [INCLUDES] before = common.conf [Definition] _daemon = sshd failregex = ^%(__prefix_line)s[iI](?:llegal|nvalid) user .*? from (?: port \d+)?\s*$ ignoreregex = [Init] journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd ~~~ > **Note** : Par fois la regex ne matche pas, on pourra mettre une regex moins rigide : ~~~{.ini} failregex = (I|i)nvalid user \S+ from .*$ ~~~ puis on définit une jail ainsi : ~~~{.ini} [sshd-invaliduser] enabled = true maxretry = 1 port = ssh,2222 logpath = %(sshd_log)s backend = %(sshd_backend)s ~~~ > **Note** : Il est conseillé de mettre dans la configuration SSH `UseDNS no`. ### Dovecot On ajoute la règle `filter.d/dovecot-evolix.conf` : ~~~{.ini} [Definition] failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted login \(auth failed|Aborted login \(tried to use disabled|Disconnected \(auth failed|Aborted login \(\d+ authentication attempts).*rip=,.* ignoreregex = ~~~ puis on définit une jail ainsi : ~~~{.ini} [dovecot-evolix] enabled = true filter = dovecot-evolix port = pop3,pop3s,imap,imaps,imap2,imap3,smtp,ssmtp logpath = /var/log/mail.log ~~~ ### Courier On utilise la règle _courierlogin_ prédéfinie pour la jail : ~~~{.ini} [courierauth] enabled = true port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s filter = courierlogin logpath = /var/log/mail.log ~~~ ### Postfix SASL La règle SASL ne convient pas, il faut la modifier via une nouvelle règle `filter.d/evolix-sasl.conf` : ~~~ [Definition] failregex = (?i): warning: [-._\w]+\[\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: ignoreregex = ~~~ puis l'on définit une jail ainsi : ~~~{.ini} [sasl] enabled = true port = smtp,ssmtp,submissions,imap2,imap3,imaps,pop3,pop3s filter = evolix-sasl logpath = /var/log/mail.log ~~~ ### Apache / Nginx Grâce aux journaux *access_log* générés par Apache / Nginx, on peut utiliser Fail2Ban comme protection sur certaines URLs ou l'ensemble des requêtes. Cela peut être des règles activées en permanence ou des règles spécifiques pour répondre à une attaque DOS ou « brute force » en cours. Voici un exemple avec un filtre `/etc/fail2ban/filter.d/dos-http.conf` qui va contrôler l'ensemble des requêtes avec la méthode HTTP GET : ~~~{.ini} [Definition] failregex = -.*"GET.*HTTP.* ~~~ puis on définit une jail du type `/etc/fail2ban/jail.d/dos-http.conf` : ~~~{.ini} [dos-http] enabled = true port = http,https filter = dos-http logpath = access.log maxretry = 300 findtime = 300 ~~~ ATTENTION, cet exemple ne doit absolument pas être mis en place pour un cas général, cela va faire dysfonctionner la plupart des sites qui ont souvent plein d'éléments statiques (CSS, JS, images, etc.). ### 401 /etc/fail2ban/filter.d/nginx-401.conf : ~~~{.ini} [Definition] failregex = -.*"GET.*HTTP.* 401 .* ~~~ Jail : ~~~{.ini} [nginx-401-allvhosts] enabled = true port = http,https filter = nginx-401 logpath = /home/*/log/access.log tail maxretry = 30 findtime = 3600 ~~~ ### 403 /etc/fail2ban/filter.d/nginx-403.conf : ~~~{.ini} [Definition] failregex = -.*"GET.*HTTP.* 403 .* ~~~ Jail : ~~~{.ini} [nginx-403-allvhosts] enabled = true port = http,https filter = nginx-403 logpath = /home/*/log/access.log tail maxretry = 30 findtime = 3600 ~~~ ## webapps ### Wordpress sans plugin L'option la plus simple pour utiliser Fail2Ban avec Wordpress consiste à détecter un trop grand nombre de tentatives de login dans les journaux *access_log*. On ajoute un filtre dans `/etc/fail2ban/filter.d/apache-wp.conf` : ~~~{.ini} [Definition] failregex = -.*"POST.*/wp-login.php HTTP.* 200 -.*"POST.*/xmlrpc.php.* ~~~ puis on définit une jail du type `/etc/fail2ban/jail.d/apache-wp.conf` : ~~~{.ini} [apache-wp] enabled = true port = http,https filter = apache-wp logpath = /var/log/apache2/access.log maxretry = 10 findtime = 300 ~~~ Cette méthode a le défaut de ne pas distinguer les tentatives réussies et échouées, car la page d'authentification ne renvoie pas d'erreur HTTP particulière ([Une proposition à cet effet a été faite, à suivre](https://core.trac.wordpress.org/ticket/25446)). Pour utiliser une méthode plus avancée (permettant notamment d'avoir un _maxretry_ plus strict) voir ci-dessous. ### Wordpress avec plugin simple Une deuxième option est d'utiliser un plugin Wordpress pour envoyer une erreur HTTP 401 en cas d'erreur d'authentification. Cette méthode est plus fine mais nécessite de toucher à l'installation Wordpress : il faut installer le plugin dans [wp-content/mu-plugins](https://codex.wordpress.org/Must_Use_Plugins), un dossier spécial qui ne sera pas vu à travers l'interface d'administration web. Il suffit de créer `wp-content/mu-plugins/401-on-login-fail.php` : ~~~{.php} .*POST.*(wp-login\.php|xmlrpc\.php).* 401 ~~~ puis on définit une jail du type `/etc/fail2ban/jail.d/apache-wp.conf` : ~~~{.ini} [apache-wp] enabled = true port = http,https filter = apache-wp logpath = /var/log/apache2/access.log /home/user/log/access.log maxretry = 5 findtime = 300 ~~~ ### Wordpress avec plugin Fail2Ban La dernière solution utilise le [plugin Wordpress fail2ban](https://wordpress.org/plugins/wp-fail2ban/) pour enregistrer les authentifications dans un fichier de log. Elle nécessite l'installation et la mise à jour régulière du plugin. Le plugin est disponible sur . On ajoute ensuite deux filtres dans `/etc/fail2ban/filter.d/wordpress-hard.conf` et `/etc/fail2ban/filter.d/wordpress-soft.conf` : ~~~ # Fail2Ban configuration file hard # # Author: Charles Lecklider # [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = (?:wordpress|wp) # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P[\w\-.^_]+) # Values: TEXT # failregex = ^%(__prefix_line)sAuthentication attempt for unknown user .* from ( via XML-RPC)?$ ^%(__prefix_line)sBlocked authentication attempt for .* from ( via XML-RPC)?$ ^%(__prefix_line)sBlocked user enumeration attempt from $ ^%(__prefix_line)sPingback error .* generated from $ # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex = ~~~ ~~~ # Fail2Ban configuration file soft # # Author: Charles Lecklider # [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = (?:wordpress|wp) # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P[\w\-.^_]+) # Values: TEXT # failregex = ^%(__prefix_line)sAuthentication failure for .* from $ ^%(__prefix_line)sXML-RPC authentication failure from $ # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex = ~~~ puis on définit deux jails du type : ~~~{.ini} [wordpress-hard] enabled = true port = http,https filter = wordpress-hard logpath = /var/log/auth.log maxretry = 1 findtime = 300 [wordpress-soft] enabled = true port = http,https filter = wordpress-soft logpath = /var/log/auth.log maxretry = 5 findtime = 300 ~~~ ### ownCloud Pour faire fonctionner ownCloud avec Fail2Ban, il faut tout d'abord modifier le fichier `config.php` pour enregistrer les informations d'authentification : ~~~ 'loglevel' => '2', 'log_authfailip' => true, 'logfile' => 'owncloud.log', ~~~ On ajoute un filtre dans `/etc/fail2ban/filter.d/owncloud.conf` : ~~~ [Definition] failregex={"app":"core","message":"Login failed: user '.*' , wrong password, IP:","level":2,"time":".*"} ~~~ puis on définit une jail du type `/etc/fail2ban/jail.d/owncloud.conf`: ~~~{.ini} [owncloud] enabled = true port = http,https filter = owncloud logpath = owncloud.log maxrety = 5 findtime = 300 ~~~ ### Joomla via les logs apache On va simplement détecter un trop grand nombre de tentatives de login dans les journaux *access_log*. On ajoute un filtre dans `/etc/fail2ban/filter.d/apache-joomla.conf` : ~~~ [Definition] failregex = -.*"POST.*/administrator/index.php HTTP ~~~ puis on définit une jail du type `/etc/fail2ban/jail.d/apache-joomla.conf`: ~~~{.ini} [apache-joomla] enabled = true port = http,https filter = apache-joomla logpath = /var/log/apache2/access.log maxretry = 10 findtime = 300 ~~~ ### Joomla via le log applicatif On peut aussi utiliser les logs applicatifs de joomla et notamment, son log/error.php qui contient les erreurs de connexions. Note: Ce log semble suivre la langue par défaut de l'installation. Il faut donc adapter ces regex ~~~ # Fail2Ban configuration file for joomla [INCLUDES] before = common.conf [Definition] failregex = ^.*INFO\s\sjoomlafailure\sLe nom d\'utilisateur ne correspond pas au mot de passe, ou vous n\'avez pas encore de compte.$ ignoreregex = ~~~ puis, pour l'activer : ~~~ [joomla-monsite] enabled = true port = http,https filter = joomla logpath = /home/monsite/www/log/error.php maxretry = 10 ~~~ ### Prestashop On va simplement détecter un trop grand nombre de tentatives de login dans les journaux *access_log*. On ajoute un filtre dans `/etc/fail2ban/filter.d/apache-prestashop.conf` : ~~~ [Definition] failregex = -.*"POST.*/login.* ~~~ puis on définit une jail du type `/etc/fail2ban/jail.d/apache-prestashop.conf`: ~~~{.ini} [apache-prestashop] enabled = true port = http,https filter = apache-prestashop logpath = /var/log/apache2/access.log maxretry = 10 findtime = 300 ~~~ ### pm2 / nodejs /etc/fail2ban/filter.d/pm2-auth-failure.conf : ~~~{.ini} [Definition] failregex = .*Auth failure, WRONG_HASH for IP .* [Init] datepattern = ^%%Y-%%m-%%d %%H:%%M ~~~ Définition de la jail : ~~~{.ini} [pm2-auth-failure] enabled = true port = http,https filter = pm2-auth-failure logpath = /home/APPPATH/.pm2/logs/api-error.log tail maxretry = 30 findtime = 3600 ~~~ ### haproxy-badbots Inspiré du filtre de Debian apache-badbots. /etc/fail2ban/filter.d/haproxy-badbots.conf : ~~~{.ini} [Definition] badbotscustom = EmailCollector|WebEMailExtrac|TrackBack/1\.02|sogou music spider|ezooms.bot|BLEXBot|MJ12bot|AhrefsBot|Yandex|EvilRobot|360Spider|Yeti|Baiduspider badbots = Atomic_Email_Hunter/4\.0|atSpider/1\.0|autoemailspider|bwh3_user_agent|China Local Browse 2\.6|ContactBot/0\.2|ContentSmartz|DataCha0s/2\.0|DBrowse 1\.4b|DBrowse 1\.4d|Demo Bot DOT 16b|Demo Bot Z 16b|DSurf15a 01|DSurf15a 71|DSurf15a 81|DSurf15a VA|EBrowse 1\.4b|Educate Search VxB|EmailSiphon|EmailSpider|EmailWolf 1\.00|ESurf15a 15|ExtractorPro|Franklin Locator 1\.8|FSurf15a 01|Full Web Bot 0416B|Full Web Bot 0516B|Full Web Bot 2816B|Guestbook Auto Submitter|Industry Program 1\.0\.x|ISC Systems iRc Search 2\.1|IUPUI Research Bot v 1\.9a|LARBIN-EXPERIMENTAL \(efp@gmx\.net\)|LetsCrawl\.com/1\.0 \+http\://letscrawl\.com/|Lincoln State Web Browser|LMQueueBot/0\.2|LWP\:\:Simple/5\.803|Mac Finder 1\.0\.xx|MFC Foundation Class Library 4\.0|Microsoft URL Control - 6\.00\.8xxx|Missauga Locate 1\.0\.0|Missigua Locator 1\.9|Missouri College Browse|Mizzu Labs 2\.2|Mo College 1\.9|MVAClient|Mozilla/2\.0 \(compatible; NEWT ActiveX; Win32\)|Mozilla/3\.0 \(compatible; Indy Library\)|Mozilla/3\.0 \(compatible; scan4mail \(advanced version\) http\://www\.peterspages\.net/?scan4mail\)|Mozilla/4\.0 \(compatible; Advanced Email Extractor v2\.xx\)|Mozilla/4\.0 \(compatible; Iplexx Spider/1\.0 http\://www\.iplexx\.at\)|Mozilla/4\.0 \(compatible; MSIE 5\.0; Windows NT; DigExt; DTS Agent|Mozilla/4\.0 efp@gmx\.net|Mozilla/5\.0 \(Version\: xxxx Type\:xx\)|NameOfAgent \(CMS Spider\)|NASA Search 1\.0|Nsauditor/1\.x|PBrowse 1\.4b|PEval 1\.4b|Poirot|Port Huron Labs|Production Bot 0116B|Production Bot 2016B|Production Bot DOT 3016B|Program Shareware 1\.0\.2|PSurf15a 11|PSurf15a 51|PSurf15a VA|psycheclone|RSurf15a 41|RSurf15a 51|RSurf15a 81|searchbot admin@google\.com|ShablastBot 1\.0|snap\.com beta crawler v0|Snapbot/1\.0|Snapbot/1\.0 \(Snap Shots, \+http\://www\.snap\.com\)|sogou develop spider|Sogou Orion spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sogou spider|Sogou web spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sohu agent|SSurf15a 11 |TSurf15a 11|Under the Rainbow 2\.2|User-Agent\: Mozilla/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1\)|VadixBot|WebVulnCrawl\.unknown/1\.0 libwww-perl/5\.803|Wells Search II|WEP Search 00 failregex = ^.* :\d{1,5} .*\{.*\|.*(?:%(badbots)s|%(badbotscustom)s).*\}.*$ ignoreregex = ~~~ Définition de la jail : ~~~{.ini} [haproxy-badbots] enabled = true port = http,https filter = haproxy-badbots logpath = /var/log/haproxy.log maxretry = 10 bantime = 300 ~~~ ## Munin Pour activer les plugins Munin pour Fail2Ban : ~~~ # cd /etc/munin/plugins # ln -s /usr/share/munin/plugins/fail2ban ~~~ ## FAQ ### Fail2Ban supporte l'IPv6 ? Le support de l'IPv6 est arrivé dans la version 0.10. Dans Debian, cette version est disponible qu'à partir de la version 10 (Buster) (et aussi dans les backports pour la version 9 (Stretch) ### Attaque via un utilisateur Un utilisateur local peut générer des logs vers _syslog_ (par exemple avec la commande **logger**), il faut donc bien avoir en tête que toute jail s'appuyant sur des logs _syslog_ (comme `/var/log/auth.log`) pourra être activée par un utilisateur logué en SSH ou via PHP, CGI, etc. ### Comment mettre en liste blanche certaines adresses IP ? Pour mettre en whitelist certaines adresses IP, il faut utiliser le paramètre _ignoreip_ qui peut s'utiliser globalement (section [DEFAULT]) ou au sein de chaque jail : ~~~ ignoreip = 127.0.0.1/8 192.0.2.42 ~~~ Ou à chaud : ~~~ # fail2ban-client set sshd addignoreip 31.170.8.69 ~~~ ### Comment bannir une ip manuellement ? ~~~ fail2ban-client set JAIL banip IP ~~~ ### Erreur "fail2ban.actions.action: ERROR" avec jail au nom trop long Si le nom de votre jail dépasse 20 caractères, vous obtiendrez des erreurs du type : ~~~ fail2ban.actions.action: ERROR iptables -N fail2ban-accesslog-custom-12345 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q fail2ban-accesslog-custom-12345 returned 100 ~~~ la raison est que Fail2Ban utilise le nom de la jail pour ajouter une chaîne IPTables et elle ne doit pas dépasser une certaine longueur : ~~~ 22:52 < reg> iptables v1.4.14: chain name `fail2ban-accesslog-custom-12345' too long (must be under 29 chars) ~~~ ### Taille de la base de données SQLite et durée de conservation des bans [Un bug](https://github.com/fail2ban/fail2ban/issues/1267#issuecomment-323336619) affecte les versions antérieures à 0.11 (Debian Bullseye) dont la base `/var/lib/fail2ban/fail2ban.sqlite3` n'est pas purgée. Le contournement est de mettre en place un cron `/etc/cron.daily/fail2ban_dbpurge` : ~~~ #!/bin/sh sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 ".timeout 5000; DELETE FROM bans WHERE datetime('now', '-86400 second') > datetime(timeofban, 'unixepoch'); VACUUM;" ~~~ Notons que la commande `VACUUM` va copier la base en supprimant les espaces inutilisés dans la nouvelle base. Par défaut, la durée maximale est définie par l'option `bantime` dont l'unité est à la seconde : ~~~ grep -R -E "bantime[[:blank:]]*=[[:blank:]]*[0-9]+" /etc/fail2ban/ ~~~ Le défaut de cette solution est qu'il ne permet plus les bans illimités (`bantime = -1`), car ceux-ci seront supprimés par le cron. Si la base de données est volumineuse parce qu'elle n'a jamais été purgée, la requête `DELETE` échouera. Pour libérer de l'espace, il faut faire des `DELETE` successifs à la main (qui peuvent prendre un certain temps) : ~~~ # sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 sqlite > .timeout 5000; sqlite > DELETE FROM bans WHERE date('now', '-1000 day') > datetime(timeofban, 'unixepoch'); sqlite > DELETE FROM bans WHERE date('now', '-500 day') > datetime(timeofban, 'unixepoch'); (...) sqlite > DELETE FROM bans WHERE date('now', '-14 day') > datetime(timeofban, 'unixepoch'); sqlite > DELETE FROM bans WHERE date('now', '-$days day') > datetime(timeofban, 'unixepoch'); sqlite > VACUUM; ~~~