wikinotes

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>netadmin sysadmin securite brut-force ban ip}}

:TODO_DOCUPDATE:

====== Fail2ban ======

Analyse les journaux des différents services en se basant sur des expression rationnelles (regex) et isole automatiquement les IP générant un nombre trop élevé d'erreurs permettant de stopper les attaques en force brute.


Installation via le gestionnaire de paquets:

<code bash>
$ sudo apt-get install fail2ban
</code>

  * Les règles sont placées dans le dossier **/etc/fail2ban/filter.d/**.
  * Le fichier de conf s'obtient par copie et modification du fichier par défaut /etc/fail2ban/jail.conf

<code bash>
$ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
</code>

===== Exceptions =====

Dans la section globale, on peut spécifier des IPs à ignorer (à ne jamais bannir).

<file>
[DEFAULT]

ignorself = true
ignoreip = 127.0.0.1/8 ::1
</file>

===== Notifications email =====

Définir les variables suivantes dans le fichier /etc/fail2ban/jail.local
<file>
destemail = user@domain
sendername = Fail2ban
sender = sender@domain
mta = mail
action = %(action_mwl)s
</file>

===== Protection du service ssh =====

Pour activer la surveillance du service ssh, vérifier la valeur de la directive **enable** dans la section [sshd]

<note>
Si le service SSH n'écoute pas sur le port par défaut, veiller à bien redéfinir la valeur de la directive **port** afin que la règle de filtrage netfilter générée par fail2ban soit correcte. 
</note>

<file>
[sshd]

enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6
</file>

Recharger le fichier de configuration
<code bash>
$ sudo fail2ban-client reload
</code>

===== Test =====

Pour afficher l'état de l'ensemble des cellules (prisons ou jails):

<code bash>
$ sudo fail2ban-client status
</code>

Pour le détail de la cellule sshd:

<code bash>
$ sudo fail2ban-client status sshd
</code>

Si des hôtes sont bannis, on peut vérifier les règles créées par fail2ban:
<code bash>
iptables -L -n
</code>

<file>
Chain INPUT (policy DROP)
target     prot opt source               destination         
f2b-sshd   tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22

. . .

Chain f2b-sshd (1 references)
target     prot opt source               destination         
REJECT     all  --  79.137.37.26         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  103.150.125.189      0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  120.88.46.226        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  14.49.204.81         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  24.2.154.81          0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  193.106.191.50       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  179.60.147.99        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  165.22.216.121       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  152.89.196.123       0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
</file>

On peut être surpris de constater que les règles générées par fail2ban utilisent la cible REJECT plutôt que DROP. Ce choix a été justifié par les développeurs dans la conversation https://github.com/fail2ban/fail2ban/issues/507 essentiellement parce que l'usage de DROP peut impacter fortement la réactivité des applications exécutées par les utilisateurs légitimes. A contrario l'usage de DROP n'a pas vraiment d'impact sur les attaquants/scripts/bots qui connaissent déjà l’existence du service (qu'il tentent d'attaquer en force brute). A ce sujet voir également http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

On peut toutefois changer se comportement par défaut si on le souhaite en éditant le fichier /etc/fail2ban/action.d/iptables-common.conf et en modifiant la valeur de la variable **blocktype**:

<file>
# Option:  blocktype (ipv6)
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp6-port-unreachable
# Values:  STRING
#blocktype = REJECT --reject-with icmp6-port-unreachable

blocktype = DROP
</file>

===== Usage =====

Une fois la configuration chargée, on peut accéder/modifier certaines valeurs à l'aide du client fail2ban:

<code bash>
# Déterminer combien de temps est bannie une ip pour ssh
$ fail2ban-client get sshd bantime

# Déterminer le nombre d'essais autorisé pour ssh
$ fail2ban-client get sshd maxretry
</code>

Pou modifier la configuration utiliser l'argument **set**

<code bash>
$ fail2ban-client set sshd maxretry 3
</code>


Pour bannir/autoriser manuellement les IPs:
<code bash>
# Interdire l'acces au service ssh a une IP
$ fail2ban-client set sshd banip 192.168.0.34

# Autoriser à nouveau une IP
$ fail2ban-client set sshd unbanip 192.168.0.34
</code>

<note>
Les valeurs spécifiées via la ligne de commande sont effectives immédiatement mais seront remplacées par celles définies dans les fichiers de configuration lorsque la configuration sera rechargée ou le service redémarré.
</note>

===== Déploiement =====

Sur serveurs en DMZ.


===== Alternatives =====

  * Tallow : plus léger, exploite les journaux systemd;
  * SSHGuard.


===== Références =====

  * https://www.grafikart.fr/formations/serveur-linux/fail2ban
  * https://www.kali-linux.fr/configuration/proteger-ssh-avec-fail2ban
  * https://doc.ubuntu-fr.org/fail2ban
  * https://wiki.chotaire.net/linux-fail2ban
wikinotes

Outils pour utilisateurs

Outils du site

Outils de la page
