Forum Linux.debian/ubuntu fail2ban n'invoque pas iptables

Posté par  .
Étiquettes :
0
12
avr.
2010
Bonjour à tous !

Afin de renforcer la sécurité d'un serveur, je cherche mettre en place fail2ban.
Notre but est de bloquer une IP pendant 4 heures si on a 6 échecs de connexion sur cinq minutes.

Le serveur dont il est question ici est une Debian Lenny.
La version du package utilisé est bien la dernière pour Lenny : 0.8.3-2sid1


Hélas, lors des tests, fail2ban n'a banni aucune IP.

Extrait de /var/log/auth.log :

(...)

Apr 11 22:45:18 xxx sshd[28514]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh (...)

Apr 11 22:45:21 xxx sshd[28514]: Failed password for invalid user elis from xxx.xxx.xxx.xxx port 36988 ssh2

Apr 11 22:45:22 xxx sshd[28517]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh (...)

Apr 11 22:45:23 xxx sshd[28517]: Failed password for invalid user elis from xxx.xxx.xxx.xxx port 37418 ssh2

(...)


Extrait de /var/log/fail2ban.log :

(...)

2010-04-11 22:45:22,596 fail2ban.filter : DEBUG  /var/log/auth.log has been modified

2010-04-11 22:45:22,597 fail2ban.filter.datedetector: DEBUG  Sorting the template list

2010-04-11 22:45:27,597 fail2ban.filter : DEBUG  /var/log/auth.log has been modified

2010-04-11 22:45:27,597 fail2ban.filter.datedetector: DEBUG  Sorting the template list

(...)



Or, fail2ban me semble configuré correctement.


Extrait de /etc/fail2ban/jail.conf :

[DEFAULT]

ignoreip = 127.0.0.1

findtime = 300

bantime  = 14400

maxretry = 6

backend = polling



[ssh]

enabled = true

port    = ssh

filter  = sshd

logpath  = /var/log/auth.log

maxretry = 6


Extrait de /etc/fail2ban/filter.d/ :

[INCLUDES]

before = common.conf



[Definition]

_daemon = sshd

failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from \s*$

            ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from \s*$

            ^%(__prefix_line)sFailed (?:password|publickey) for .* from (?: port \d*)?(?: ssh\d*)?$

            ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM \s*$

            ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from \s*$

            ^%(__prefix_line)sUser .+ from  not allowed because not listed in AllowUsers$

            ^%(__prefix_line)sUser .+ from  not allowed because none of user's groups are listed in AllowGroups\s*$

            ^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=(?:\s+user=.*)?\s*$

            ^%(__prefix_line)srefused connect from \S+ \(\)\s*$

            ^%(__prefix_line)sAddress  .* POSSIBLE BREAK-IN ATTEMPT\s*$



J'ai testé avec "fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf"
fail2ban a détecté correctement les différentes erreurs.
Une dizaine d'IPs remplissaient les conditions pour un ban.

Running tests

=============



Use regex file : /etc/fail2ban/filter.d/sshd.conf

Use log file   : /var/log/auth.log



Results

=======



Failregex

| (...)

|

`- Number of matches:

   [1] 0 match(es)

   [2] 0 match(es)

   [3] 1713 match(es)

   [4] 0 match(es)

   [5] 1079 match(es)

   [6] 0 match(es)

   [7] 0 match(es)

   [8] 0 match(es)

   [9] 0 match(es)

   [10] 0 match(es)


Quelqu'un aurait-il une piste ?

Merci d'avance,

  • # un hack ignoble

    Posté par  . Évalué à -1.

    Je ne me suis jamais penché sur fail2ban, mais d'après ce que je comprends c'est un hack ignoble qui parse les logs pour bannir des IP, alors qu'iptables est fait pour ça:
    iptables -I INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT

    Maintenant je peux me tromper...

    • [^] # Re: un hack ignoble

      Posté par  . Évalué à 5.

      L'idée c'est qu'il ne ban que ceux qui ont fourni un mauvais mdp / une mauvaise clé. Parce qu'un utilisateur légitime peut avoir besoin de faire plein de connexion dans un temps limité, ce qu'empêche ta solution.

      • [^] # Re: un hack ignoble

        Posté par  . Évalué à 3.

        Je suis curieux de voir un exemple d'utilisation légitime de ce que tu décris ("plein de connexions..."). Même s'il en existe, 99% des gens qui utilisent fail2ban ne sont pas concernés, ils veulent juste se protéger contre une attaque brute force. Enfin, les avantages d'iptables:
        - ça marche
        - cela permet de réduire la charge réseau/CPU (les connexions ne sont pas établies, contrairement à fail2ban)
        - cela protège contre les attaques très courtes (je suppose que fail2ban est lancé périodiquement, et de toute façon les tentatives de connexion ne sont pas écrites immédiatement dans les logs, sinon bonjour le remplissage et l'activité disque)

        Donc je maintiens que dans 99% des cas, iptables doit être préféré à fail2ban...

        • [^] # Re: un hack ignoble

          Posté par  . Évalué à 2.

          Oui, j'ai dit "peut" avoir besoin. Effectivement, je ne vois pas énormément d'utilisation légitime avec plein de connexions par seconde. Si les attaques sont vraiment nombreuses, la technique iptables est peut-être meilleure. Mais ce cas de très grandes attaques me paraît aussi assez rare.

  • # Ma config (qui fonctionne bien)

    Posté par  . Évalué à 1.

    Salut, je viens de comparer ta config avec la mienne. Or dans ton fichier jail.conf, il te manque qqc:


    [ssh-iptables]

    enabled = true
    filter = sshd
    action = iptables[name=SSH, port=ssh, protocol=tcp]
    mail-whois[name=SSH, dest=moi@mon_adresse.tld]
    logpath = /var/log/messages
    maxretry = 5


    Il te manque donc 'action' qui défini justement l'action à faire si une IP est repérée.

    Action qui doit correspondre à un fichier .conf dans /etc/fail2ban/action.d/
    Dans mon cas iptables.conf (pour bloquer l'IP en question) et mail-whois.conf pour me prévenir par email du blocage.

    • [^] # Re: Ma config (qui fonctionne bien)

      Posté par  . Évalué à 1.

      J'ai rajouté le 'action', comme suggéré par François. Malheureusement, cela ne fonctionne pas mieux. Et pour cause. En retirant les commentaires, j'ai églaement retiré par erreur ces lignes de mon post, que Debian génère par défaut : 
      banaction = iptables
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
action = %(action_)s

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.