Fail2Ban: déjà interdit?

J'ai Fail2Ban en cours d'exécution sur mon serveur Centos. (Config ci-dessous)

Dans mon var / log / messages, j'ai remarqué quelque chose de vraiment bizarre:

Jun 19 12:09:32 localhost fail2ban.actions: INFO   [postfix] 114.43.245.205 already banned

J'ai configuré Fail2Ban pour ajouter l'adresse IP interdite à iptables.

Mon jail.conf:

[postfix]

enabled  = true
filter   = postfix
action   = iptables
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/maillog
bantime  = 43200
maxretry = 2

Mon postfix.conf:

[INCLUDES]

before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 550 5.1.1
            reject: RCPT from (.*)\[<HOST>\]: 450 4.7.1
            reject: RCPT from (.*)\[<HOST>\]: 554 5.7.1
            reject: RCPT from (.*)\[<HOST>\]: (.*)@yahoo.com.tw
ignoreregex =

Ma question est de savoir comment quelqu'un qui a déjà été bloqué peut iptablestoujours se connecter au serveur?

La prison récidive recommandée dans l'autre réponse ici n'a pas résolu le problème pour moi. J'ai finalement corrigé cela, alors voici ma méthode au cas où cela aiderait les autres.

Fail2ban bloque uniquement TCP par défaut. Au moins avec ma configuration, j'ai remarqué que le message "déjà interdit" apparaissait lorsque les bots revenaient pour essayer le port bloqué sur UDP à la place.

Pour résoudre ce problème, indiquez à Fail2ban de bloquer le port sur tous les protocoles au lieu de simplement TCP. Vous devrez effectuer cette modification dans /etc/fail2ban/jail.conf et dans la section [Init] de chaque action que vous utilisez dans /etc/fail2ban/action.d/ .

Change ça:

# Default protocol
protocol = tcp

À:

# Default protocol
protocol = all

Ensuite, j'ai désactivé les demandes d'écho ICMP afin que les adresses IP bloquées n'aient aucun moyen de toucher le serveur:

1. nano /etc/sysctl.conf

2. Ajoutez ces deux lignes:

   net.ipv4.icmp_echo_ignore_all = 1  
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   

3. Quittez et enregistrez le fichier.
4. Exécutez sysctl -p pour que la modification prenne effet.

Après cela, exécutez le rechargement du client fail2ban et vous ne devriez plus voir ces messages "déjà interdits" à moins que vous ne soyez spammé par une IP qui obtient quelques tentatives d'accès avant que le blocage ne prenne effet.

En outre, il est important de bloquer tous les ports pour chaque délinquant plutôt que le port auquel ils tentaient d'accéder en utilisant l'action iptables-allports dans chacun des prisons. Sinon, ils peuvent déclencher une autre prison et finir comme "déjà interdits" dans les journaux.

Si vous regardez la sortie de iptables-save, vous verrez que les fail2banchaînes sont configurées pour évaluer les paquets selon les règles définies par les filtres, par exemple:

:fail2ban-ssh - [0:0]
-A INPUT -p tcp -A INPUT -p tcp -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A fail2ban-ssh -j RETURN

Le trafic parvient toujours au serveur avant l'application des autres règles de routage et le trafic est rejeté. fail2banvoit toujours ce trafic initial, et c'est pourquoi vous voyez les messages "déjà interdits". De plus, il existe un filtre spécial pour les récidivistes ( /etc/fail2ban/filter.d/recidive.conf):

# Fail2Ban filter for repeat bans
#
# This filter monitors the fail2ban log file, and enables you to add long
# time bans for ip addresses that get banned by fail2ban multiple times.
#
# Reasons to use this: block very persistent attackers for a longer time,
# stop receiving email notifications about the same attacker over and
# over again.
#
# This jail is only useful if you set the 'findtime' and 'bantime' parameters
# in jail.conf to a higher value than the other jails. Also, this jail has its
# drawbacks, namely in that it works only with iptables, or if you use a
# different blocking mechanism for this jail versus others (e.g. hostsdeny
# for most jails, and shorewall for this one).

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = fail2ban\.server\.actions

# The name of the jail that this filter is used for. In jail.conf, name the
# jail using this filter 'recidive', or change this line!
_jailname = recidive

failregex = ^(%(__prefix_line)s| %(_daemon)s%(__pid_re)s?:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

[Init]

journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=4

# Author: Tom Hendrikx, modifications by Amir Caspi

Cela se produira si l'adresse IP que vous interdisez n'est pas réellement l'adresse IP du client qui se connecte au serveur. Par exemple, si votre serveur se trouve derrière un équilibreur de charge ou un proxy.

Il m'a fallu un certain temps pour comprendre cela récemment. Le red herring était que les journaux étaient configurés pour capturer l' X-Forwarded-Foradresse IP, au lieu de la véritable adresse source, qui dans mon cas était l'équilibreur de charge.

Dans ce cas, fail2ban n'est pas d'une grande aide, car l'interdiction de l'adresse IP incriminée finirait par bloquer tout le trafic.

Je veux apporter mon propre problème et solution avec des messages "déjà interdits". Comme vous l'avez écrit, j'en avais des centaines en quelques minutes alors que l'attaquant aurait déjà dû être banni.

Avant de commencer, voici mon système:

• Plesk 12
• Centos 7
• Module Plesk installé, fonctionnant et configurant fail2ban pour moi

Lorsque j'ai installé OpenVPN sur mon serveur racine, j'avais changé firewalld en iptables. Cela pourrait avoir causé ce problème pour moi, mais à part cela, mon système était principalement intact et assez récemment installé (Strato rootserver a suggéré d'installer l'image).

Si vous avez ce problème, veuillez vérifier /etc/fail2ban/jail.d/00-firewalld.conf pour une ligne qui ressemble à ceci:

banaction = firewallcmd-ipset

À partir du moment où j'ai commenté cela, enregistré le fichier et redémarré fail2ban.service, tout allait bien avec fail2ban. Plus de messages

Je ne suis pas un expert mais j'espère vous fournir la bonne réponse. Si cela fonctionne pour vous, faites-le moi savoir!

Ma question est de savoir comment quelqu'un qui a déjà été bloqué dans iptables peut-il toujours se connecter au serveur?

Il s'est connecté au serveur une seule fois, mais dans cette connexion, il a essayé de transmettre plusieurs e-mails à des boîtes aux lettres inexistantes (comme info@domain.com, sales@domain.com, tech@domain.com etc.)

Vous avez configuré votre filtre postfix pour interdire ces tentatives afin que l'IP soit bannie après X tentatives. Le client peut déjà être déconnecté de postfix, mais comme postfix n'a peut-être pas fini de traiter tous ses e-mails, fail2ban peut détecter une autre tentative du même client lorsque postfix traite son courrier, et ainsi vous obtenez l'adresse de message déjà interdite. C'est à cause du fonctionnement de la file d'attente postfix.

Ma question est de savoir comment quelqu'un qui a déjà été bloqué dans iptables peut-il toujours se connecter au serveur?

Incroyable bonne question. Je cherchais si mes règles de pare-feu ne fonctionnaient pas, mais elles iptables --list-rulescorrespondaient exactement à un autre serveur de production avec fail2ban fonctionnel.

La solution époustouflante était d'ajouter le port 8080 aux ports bloqués, car j'accédais toujours à la page de connexion via les ports de développement.

Donc, la solution dans ma situation est que ce problème était une adaptation assez simple de mon jail.local:

[JIRA-LOGIN-tcp]
  enabled = true
  port = http,https,8080
  protocol = tcp
  filter = JIRA-LOGIN-ERROR
  logpath = /var/atlassian/application-data/jira/log/atlassian-jira-security.log
  bantime = 600
  maxretry = 1

voir /unix//a/525798/22315

il vous manque probablement le port 587 dans la ligne "port =", et vous pouvez vérifier le fichier de configuration de postfix ou faire "lsof -i: 587" pour savoir, directement, si postfix a été configuré pour ouvrir ce port.