Fail2Ban: ya prohibido?

Tengo Fail2Ban ejecutándose en mi servidor Centos. (Configuración a continuación)

En mis var / log / messages noté algo realmente extraño:

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

Configuré Fail2Ban para agregar la IP prohibida a iptables.

Mi cárcel.conf:

[postfix]

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

Mi 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 =

Mi pregunta es ¿cómo puede alguien que ya ha sido bloqueado iptablesconectarse al servidor?

La cárcel recidivante recomendada en la otra respuesta aquí no me solucionó el problema. Sin embargo, eventualmente solucioné esto, así que aquí está mi método en caso de que ayude a otros.

Fail2ban solo bloquea a través de TCP de forma predeterminada. Al menos con mi configuración, noté que aparecía el mensaje "ya prohibido" cuando los bots volvieron a intentar el puerto bloqueado a través de UDP.

Para solucionar este problema, dígale a Fail2ban que bloquee el puerto en todos los protocolos en lugar de solo TCP. Deberá realizar este cambio en /etc/fail2ban/jail.conf y en la sección [Init] de cada acción que esté utilizando en /etc/fail2ban/action.d/ .

Cambia esto:

# Default protocol
protocol = tcp

A:

# Default protocol
protocol = all

A continuación, deshabilité las solicitudes de eco ICMP para que las IP bloqueadas no tuvieran forma de llegar al servidor:

1. nano /etc/sysctl.conf

2. Agregue estas dos líneas:

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

3. Salga y guarde el archivo.
4. Ejecute sysctl -p para que el cambio surta efecto.

Después de eso, ejecute recargar fail2ban-client y ya no debería ver estos mensajes "ya prohibidos" a menos que una dirección IP le envíe correo no deseado y reciba un par de intentos de acceso antes de que el bloqueo entre en vigencia.

Además, es importante bloquear todos los puertos para cada infractor en lugar del puerto al que intentaban acceder utilizando la acción iptables-allports en cada una de las cárceles. De lo contrario, pueden desencadenar otra cárcel y terminar como "ya prohibido" en los registros.

Si observa la salida de iptables-save, verá que las fail2bancadenas están configuradas para que evalúen los paquetes de acuerdo con las reglas definidas por los filtros, por ejemplo:

: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

El tráfico aún llega al servidor antes de que se apliquen las otras reglas de enrutamiento y se rechaza el tráfico. fail2bantodavía ve este tráfico inicial, y es por eso que ve los mensajes "ya prohibidos". Además, hay un filtro especial para reincidentes ( /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

Esto sucederá si la dirección IP que está prohibiendo no es en realidad la dirección IP del cliente que se conecta al servidor. Por ejemplo, si su servidor está detrás de un equilibrador de carga o proxy.

Me llevó bastante tiempo resolver esto recientemente. El arenque rojo fue que los registros se configuraron para capturar la X-Forwarded-Fordirección IP, en lugar de la dirección de origen real, que en mi caso era el equilibrador de carga.

En este caso, fail2ban no es de mucha ayuda, ya que prohibir la IP infractora terminaría bloqueando todo el tráfico.

Quiero contribuir con mi propio problema y solución con mensajes "ya prohibidos". Como escribiste, tuve cientos de ellos en minutos, mientras que el atacante ya debería haber sido prohibido.

Antes de comenzar, aquí está mi sistema:

• Plesk 12
• Centos 7
• Plesk-Module instalado, operando y configurando fail2ban para mí

Cuando instalé OpenVPN en mi servidor raíz, cambié firewalld a iptables. Eso podría haberme causado este problema, pero aparte de eso, mi sistema estaba prácticamente intacto y recién instalado (Strato rootserver sugirió una imagen de instalación).

Si tiene este problema, consulte /etc/fail2ban/jail.d/00-firewalld.conf para obtener una línea similar a esta:

banaction = firewallcmd-ipset

Desde el momento en que comenté eso, guardé el archivo y lo reinicié fail2ban.service, todo estuvo bien con fail2ban. No mas mensajes

No soy un experto, pero espero darte la respuesta correcta. Si eso funciona para usted, ¡hágamelo saber!

Mi pregunta es ¿cómo puede alguien que ya ha sido bloqueado en iptables todavía conectarse al servidor?

Se conectó al servidor solo una vez, pero en esa conexión intentó enviar múltiples correos electrónicos a buzones probablemente inexistentes (como [email protected], [email protected], tecnologí[email protected], etc.)

Ha configurado su filtro de postfix para prohibir esos intentos, por lo que la IP se bloqueará después de X intentos. Es posible que el cliente ya esté desconectado de Postfix, pero dado que Postfix puede no haber terminado de procesar todo su correo electrónico, fail2ban puede detectar otro intento del mismo cliente cuando Postfix procesa su correo y, por lo tanto, obtiene la dirección del mensaje ya prohibida. Es por cómo funciona la cola de postfix.

Mi pregunta es ¿cómo puede alguien que ya ha sido bloqueado en iptables todavía conectarse al servidor?

Increíble buena pregunta. Estaba buscando si las reglas de mi firewall no funcionaban, pero iptables --list-rulescoincidían exactamente con otro servidor de producción con fail2ban en funcionamiento.

La solución alucinante fue agregar el puerto 8080 a los puertos bloqueados, ya que todavía estaba accediendo a la página de inicio de sesión a través de los puertos de desarrollo.

Entonces, la solución en mi situación es que este problema fue una adaptación bastante simple de mi 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

ver /unix//a/525798/22315

probablemente le falte el puerto 587 de la línea "port =", y puede verificar el archivo de configuración de postfix o hacer "lsof -i: 587" para averiguar, directamente, si postfix ha sido configurado para abrir ese puerto.