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.
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.
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