première relecture

This commit is contained in:
Gregory Colpart 2017-05-20 18:24:23 +02:00
parent 3434e8dc50
commit a68c203b88

View file

@ -1,29 +1,68 @@
**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
---
categories: web security
title: Howto Fail2Ban
...
* Documentation : <https://www.fail2ban.org/wiki/index.php/MANUAL_0_8>
* Rôle Ansible : <https://forge.evolix.org/projects/ansible-roles/repository/show/fail2ban>
# Howto Fail2Ban
Fail2Ban est un service (en Python), qui scanne les logs applicatifs à la recherche d'échec de connexions pour bannir (via iptables) les adresses IP qui font trop de tentatives.
TODO : description à ré-écrire
[Fail2Ban](https://www.fail2ban.org) est un service (en Python), qui scanne les logs applicatifs à la recherche d'échec de connexions pour bannir (via iptables) les adresses IP qui font trop de tentatives.
Il est disponible en version 0.8.4-3 pour Squeeze et 0.8.6-3 pour Wheezy. Un backport pour Squeeze est [disponible](https://packages.debian.org/squeeze-backports/fail2ban)
Fail2Ban v0.8.13 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.
## Installation
~~~
# aptitude install fail2ban
# apt install fail2ban
# fail2ban-server -V
Fail2Ban v0.8.13
Copyright (c) 2004-2008 Cyril Jaquier, 2008- Fail2Ban Contributors
Copyright of modifications held by their respective authors.
Licensed under the GNU General Public License v2 (GPL).
Written by Cyril Jaquier <cyril.jaquier@fail2ban.org>.
Many contributions by Yaroslav O. Halchenko <debian@onerussian.com>.
~~~
## Configuration
Cela se passe dans le répertoire /etc/fail2ban
Le principe repose sur un système de règles basées sur des regex correspondant à applicatif.
Par défaut les règles pour SSH sont activées , voici comment ça se composer
*filter.d/sshd.conf* contient les regex correspondant à SSH
jail.conf est le fichier principal activant (ou pas) les règles avec différents paramètres
Fichiers de configuration :
~~~
/etc/fail2ban
├── fail2ban.conf
├── jail.conf
├── jail.local
├── action.d
│ ├── apf.conf
│ ├── badips.conf
│ ├── blocklist_de.conf
│ […]
├── fail2ban.d
├── filter.d
│ ├── 3proxy.conf
│ ├── apache-auth.conf
│ ├── apache-badbots.conf
│ […]
└── jail.d
~~~
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 _ssh_ (activée par défaut à l'installation) :
~~~{.ini}
[ssh]
enabled = true
@ -33,50 +72,148 @@ logpath = /var/log/auth.log
maxretry = 6
~~~
On peut régler plusieurs paramètres, comme le maxretry (nombres d'échecs) dans la section [DEFAULT] ou pour chaque applicatif.
Cette jail va surveiller le fichier `/var/log/auth.log` via la règle de filtrage `/etc/fail2ban/filter.d/sshd.conf` :
si il détecte la correspondance 6 fois en 10 minutes (temps par défaut), 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.
## Règles
Les paramètres par défaut sont :
On peut évidemment écrire ses propres règles. On pourra les tester ainsi :
~~~{.ini}
maxretry = 3
findtime = 600
banaction = iptables-multiport
bantime = 600
ignoreip = 127.0.0.1/8
~~~
Les paramètres par défaut et un certain nombre de jails (non activées à par _ssh_) 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`.
Pour dumper la configuration courante :
~~~
# fail2ban-regex /tmp/mail.log filter.d/sasl-test.conf
# fail2ban-client -d
['set', 'loglevel', 3]
['set', 'logtarget', '/var/log/fail2ban.log']
[...]
~~~
## Administration
On peut lister les "jails" :
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
|- Number of jail: NN
`- Jail list: ...
Status
|- Number of jail: 1
`- Jail list: ssh
~~~
On va les retrouver aussi avec `iptables -L -n`
Pour débannir une IP :
Et l'on doit les retrouver au niveau d'iptables :
~~~
# fail2ban-client set <JAIL> unbanip <IP>
# 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:
[...]
~~~
## Règles de filtrage
Un certain nombre de 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 en s'appuyant sur [les expressions régulières Python](https://docs.python.org/3/library/re.html) pour détecter la variable _<HOST>_.
Exemple d'une règle :
~~~
[Definition]
failregex = warning: \[<HOST>\]: authentication failed:
ignoreregex =
~~~
On peut tester sa règle avec la commande **fail2ban-regex** en précisant une date :
~~~
$ fail2ban-regex '2017-05-20 10:10:10 foo' 'warning: \[<HOST>\]: authentication failed:'
[...]
Failregex: 0 total
[...]
$ fail2ban-regex '2017-05-20 10:10:10 [192.0.2.42]: authentication failed:' '\[<HOST>\]: authentication failed:'
[...]
Failregex: 1 total
|- #) [# of hits] regular expression
| 1) [1] \[<HOST>\]: authentication failed:
[...]
$ fail2ban-regex auth.log /etc/fail2ban/filter.d/evolix-test.conf
[...]
~~~
## Exemples
### Dovecot
Il faut ajouter des règles personnalisées :
~~~
[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
port = pop3,pop3s,imap,imaps
logpath = /var/log/mail.log
~~~
Filtre dovecot, filter.d/dovecot-pop3imap.conf
On ajoute la règle `filter.d/evolix-dovecot.conf` :
~~~
[Definition]
@ -84,9 +221,21 @@ failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted logi
ignoreregex =
~~~
puis on définit une jail ainsi :
~~~{.ini}
[dovecot]
enabled = true
filter = evolix-dovecot
port = pop3,pop3s,imap,imaps
logpath = /var/log/mail.log
~~~
Filtre dovecot, filter.d/dovecot-pop3imap.conf
## Courier
Il suffit d'activer la règle courierlogin prédéfinie :
On utilise la règle _courierlogin_ prédéfinie pour la jail :
~~~{.ini}
[courierauth]
@ -99,18 +248,7 @@ logpath = /var/log/mail.log
## Postfix SASL
Il faut modifier la règle SASL prédéfinie :
~~~{.ini}
[sasl]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = sasl-evolix
logpath = /var/log/mail.log
~~~
avec filter.d/sasl-evolix.conf :
La règle SASL ne convient pas, il faut la modifier via une nouvelle règle `filter.d/evolix-sasl.conf` :
~~~
[Definition]
@ -118,20 +256,24 @@ failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGES
ignoreregex =
~~~
## Services HTTP
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
Il est possible d'utiliser `fail2ban` sur des sites web pour ajouter une couche de protection contre les attaques, ou alors pour répondre à une attaque en cours.
Les deux attaques les plus courantes sur les services HTTP sont les DDOS et les attaques en "brute force".
Pour les attaques de type DDOS, la chose la plus efficace à faire est d'écrire des règles pour le serveur web (Apache, Nginx, etc.)
Comme `fail2ban` a besoin d'être configuré au cas par cas, il faut utiliser des configurations différentes pour chaque plateforme web.
En général, on tente d'être le plus précis possible en configurant `fail2ban` pour regarder les logs d'authentification. Cela permet d'éviter les faux positifs et d'être efficace en cas d'attaque.
### Apache & Nginx DDOS
On peut protéger Apache des attaques DDOS simples avec les configurations suivantes. Il faut tout d'abord s'assurer qu'Apache enregistre des logs d'accès. On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/ddos-http.conf` :
~~~
@ -160,12 +302,12 @@ maxretry = 300
findtime = 300
~~~
### Wordpress
### webapps
#### Wordpress sans plugin
Il existe plusieurs options pour configurer `fail2ban` pour Wordpress. Cela découle du fait qu'il n'y a pas de moyen par défaut de logger les authentifications erronées sous Wordpress, et que la page d'authentification ne renvoie pas d'erreur HTTP particulière non plus. ["Une proposition à cet effet"](https://core.trac.wordpress.org/ticket/25446) a cependant été faite et risque éventuellement d'être implémentée.
#### Option 1: HTPP 200
Cette option est la plus simple des trois car elle ne nécessite pas de modifier l'installation Wordpress. Elle a cependant le désavantage d'être très générale et peu créer des faux positifs. C'est celle qui est actuellement utilisée par Évolix.
Il faut tout d'abord s'assurer que notre serveur web enregistre des logs d'accès. On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/apache-wp.conf`:
@ -188,7 +330,7 @@ maxretry = 5
findtime = 60
~~~
#### Option 2: Plugin simple & HTTP 401
#### Wordpress avec plugin simple
Une seconde option est d'utiliser un plugin Wordpress très simple pour envoyer une erreur HTTP 401 en cas d'erreur d'authentification. Cette méthode est plus fine et créé moins de faux positifs, mais nécessite de toucher à l'installation Wordpress.
@ -224,7 +366,7 @@ maxretry = 5
findtime = 60
~~~
#### Option 3: Plugin régulier & LOG_AUTH
#### Wordpress avec plugin Fail2Ban
La dernière solution utilise le [le plugin Wordpress fail2ban](https://wordpress.org/plugins/wp-fail2ban/) pour enregistrer les authentification dans un fichier de log. `fail2ban` vérifie par la suite ce fichier pour bannir les gens effectuant des attaques.
@ -320,7 +462,7 @@ Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter les règles suiva
port = http,https
~~~
### ownCloud
#### ownCloud
Pour faire fonctionne ownCloud avec fail2ban, il faut tout d'abord modifier le `config.php` pour enregistrer les informations d'authentification:
@ -349,7 +491,7 @@ Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec
findtime = 600
~~~
### Joomla
#### Joomla
Il faut tout d'abord s'assurer que notre serveur web enregistre des logs d'accès. On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/apache-joomla.conf`:
@ -370,7 +512,7 @@ Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec
findtime = 60
~~~
### Prestashop
#### Prestashop
Il faut tout d'abord s'assurer que notre serveur web enregistre des logs d'accès. On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/apache-prestashop.conf`:
@ -390,3 +532,15 @@ Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec
maxretry = 10
findtime = 60
~~~
## FAQ
### Fail2Ban supporte l'IPv6 ?
Non, Fail2Ban ne supporte pas encore l'IPv6, c'est prévu pour la version 0.10 (encore expérimentale).
### 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.