Zimbra – Fail2ban – Sécuriser l'attaque « brute force » | Babash

Malgré une sécurisation de nos MTA, du proxy et l’utilisation de fail2ban avec une configuration de base, nous sommes attaqués par brute force de temps à autre. En soi, rien de méchant puisque les serveurs ne tombent pas, ils essayent juste de trouver les bons mots de passe pour utiliser le mail. Nous allons donc bloquer les IP en question

Tout d’abord, sachez que nous utilisons l’identification CAS, de ce fait, nos logs ne correspondent pas à une installation classique que vous avez peut être.

Si vous avez une installation classique, je vous invite à consulter les articles suivants :

Sinon, voilà ce que j’ai mis en place :

Installation de fail2ban

apt-get install fail2ban

Dur non ? 🙂

Création d’un fichier jail.local

Pour éviter de perdre la configuration suites aux MAJ de fail2ban, création du fichier local.

Dans « /etc/fail2ban/jail.local » :

# Fail2Ban configuration file.
#
# This file was composed for Debian systems from the original one
# provided now under /usr/share/doc/fail2ban/examples/jail.conf
# for additional examples.
# Comments: use '#' for comment lines and ';' for inline comments
# To avoid merges during upgrades DO NOT MODIFY THIS FILE
# and rather provide your changes in /etc/fail2ban/jail.local
# The DEFAULT allows a global definition of the options. They can be overridden
# in each jail afterwards.

[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1/8

# "bantime" is the number of seconds that a host is banned.
bantime  = 86400

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 3600
maxretry = 3

# "backend" specifies the backend used to get files modification.
# Available options are "pyinotify", "gamin", "polling" and "auto".
# This option can be overridden in each jail as well.
#
# pyinotify: requires pyinotify (a file alteration monitor) to be installed.
#            If pyinotify is not installed, Fail2ban will use auto.
# gamin:     requires Gamin (a file alteration monitor) to be installed.
#            If Gamin is not installed, Fail2ban will use auto.
# polling:   uses a polling algorithm which does not require external libraries.
# auto:      will try to use the following backends, in order:
#            pyinotify, gamin, polling.
backend = auto

# "usedns" specifies if jails should trust hostnames in logs,#   warn when reverse DNS lookups are performed, or ignore all hostnames in logs
#
# yes:   if a hostname is encountered, a reverse DNS lookup will be performed.
# warn:  if a hostname is encountered, a reverse DNS lookup will be performed,
#        but it will be logged as a warning.
# no:    if a hostname is encountered, will not be used for banning,
#        but it will be logged as info.
usedns = warn

# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = votre email
#
# Name of the sender for mta actions
sendername = Fail2Ban

#
# ACTIONS
#
# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define
# action_* variables. Can be overridden globally or per
# section within jail.local file
banaction = iptables-multiport

# email action. Since 0.8.1 upstream fail2ban uses sendmail
# MTA for the mailing. Change mta configuration parameter to mail
# if you want to revert to conventional 'mail'.
mta = sendmail

# Default protocol
protocol = tcp

# Specify chain where jumps would need to be added in iptables-* actions
chain = INPUT

#
# Action shortcuts. To be used to define action parameter
# The simplest action to take: ban only
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

# ban & send an e-mail with whois report to the destemail.
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
             %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s", sendername="%(sendername)s"]

# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
              %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]

# Choose default action.  To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_)s

#
# JAILS
#

# Next jails corresponds to the standard configuration in Fail2ban 0.6 which
# was shipped in Debian. Enable any defined here jail by including
#
# [SECTION_NAME]
# enabled = true
#

# in /etc/fail2ban/jail.local.
#
# Optionally you may override any other parameter (e.g. banaction,
# action, port, logpath, etc) in that section within jail.local

Configuration de base

Dans le fichier « jail.local » fraichement créé, ajoutons à la fin :

[ssh]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

Nous avons donc activé le contrôle sur SSH.

Lire plus :   VmWare ESXi et le port trunking - Babash

Configuration pour le Webmail (proxy)

Pour ma part, j’ai trouvé les infos ici : « /opt/zimbra/log/nginx.log »

J’ai trouvé que les tentatives se présentaient sous cette forme : « -ERR authentication failed: LOGIN failed » while reading response from upstream, client: »

Création du filtre

Pour notre cas de brute force, on va donc ajouter un nouveau filtre.

Créer un fichier dans « /etc/fail2ban/filter.d/zimbra-auth-webmail.conf » :

# fail2ban filter configuration for zimbra AUTH webmail

[Definition]
failregex = -ERR authentication failed: LOGIN failed\" while reading response from upstream\, client\: \:
ignoreregex =

Tester le filtre

Une fois créé, on contrôle notre filtre :

fail2ban-regex /opt/zimbra/log/nginx.log /etc/fail2ban/filter.d/zimbra-auth-webmail.conf
Running tests ============= Use   failregex file : /etc/fail2ban/filter.d/zimbra-auth-webmail.conf Use         log file : /opt/zimbra/log/nginx.log Results ======= Failregex: 4 total |-  #) [# of hits] regular expression |   1) [4] -ERR authentication failed: LOGIN failed\" while reading response from upstream\, client\: \: `- Ignoreregex: 0 total Date template hits: |- [# of hits] date format |  [23905] Year/Month/Day Hour:Minute:Second
`-

Lines: 23905 lines, 0 ignored, 4 matched, 23901 missed
Missed line(s):: too many to print.  Use --print-all-missed to print all 23901 lines

On trouve bien ici :

  • 4 IP qui correspondent
  • et une date template trouvée tout seul par fail2ban.

Conclusion : Ca marche !

Activer le contrôle

On peut donc activer la règle en ajoutant le bloc suivant dans « jail.local ».

Actuellement, zimbra est configuré pour bloquer les comptes 30 minutes si 10 tentatives sur 1h. Cela est pour une utilisation “normale” ( l’utilisateur qui a oublié son mot de passe ). On ne doit donc pas mettre moins sinon cet utilisateur sera bloqué 1 journée !

A voir dans le temps pour ajuster les paramètres, notamment le bannissement à 1 mois par exemple.

[zimbra-webmail]
enabled         = true
port            = http,https
filter          = zimbra-auth-webmail
logpath         = /opt/zimbra/log/nginx.log
# banni 1 jour
bantime  = 86400
# si  20 tentatives
maxretry = 20
# sur 1 heure
findtime = 3600

Configuration pour les SMTP (mta)

De plus, dans les logs, je me suis rendu compte qu’il y avait des tentatives, plus discrètes : 2 tentatives par jour pour une même IP à 2/3 secondes max d’intervalle. Une fois en s’identifiant en clair et juste après en chiffrée. C’est donc très bien fait, car cela passe inaperçu et demande un filtre bien pensé dans fail2ban.

Lire plus :   Renault PRE-CODE CALCULATOR | Babash

Configuration du filtre

Créer un fichier « /etc/fail2ban/filter.d/zimbra-authfailed.conf » :

# fail2ban filter configuration for zimbra AUTH Failed

[Definition]
failregex = (?i): warning: [-._\w]+\[\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: \w

ignoreregex =

Activation de la jail

Dans « jail.local », ajouter :

[zimbra-smtp]
enabled         = true
port            = smtp,smtps
filter          = zimbra-authfailed
logpath         = /var/log/zimbra.log
# banni 1 mois
bantime  = 2592000
# si  5 tentatives
maxretry = 2
# sur 10 secondes
findtime = 3

Redémarrage de fail2ban

/etc/init.d/fail2ban restart

Contrôler :

iptables -L
Chain INPUT (policy ACCEPT) target     prot opt source               destination fail2ban-zimbra-webmail  tcp  --  anywhere             anywhere             multiport dports http,https fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh

Vérifier les IP bloquées par fail2ban

iptables -L -n

Ou via fail2ban :

fail2ban-client status 

A lire également