Una banaction, dos transportes: arreglar una jail de fail2ban para VPN

Nada en fail2ban descarta un paquete por sí solo: invoca una acción, y esa acción es la que nombra un protocolo y un puerto. Cuando la jail informa de un ban mientras el demonio sigue aceptando inicios de sesión, el ban suele ser real y más estrecho de lo que implica el registro. Un cliente que se reconecta por el otro transporte nunca encuentra la regla que se instaló. Compare lo que instaló la acción con lo que escucha el demonio antes de cambiar nada, porque la prueba está en la cadena de cortafuegos que escribió la acción, no en la lista de la jail.

Lea la cadena, no el resumen de la jail

fail2ban inserta su propia cadena delante de la cadena del servicio, así que un listado de contadores muestra exactamente lo que existe. Una cadena con el nombre de la jail, que contiene una sola regla cuya columna de protocolo dice udp, es una explicación completa de los inicios de sesión TCP que siguen llegando. Solo se rechazan los paquetes UDP del origen bloqueado. El servicio tiene un escucha TCP, y nada en esa cadena lo toca.

Ojo también con el efecto de la jail vecina. Un host puede parecer perfectamente configurado solo porque otra jail aporta la mitad que falta, y la misma compilación no hace nada donde esa jail no está instalada.

La acción nombra un solo protocolo, y ahí es donde se rompe

Cada banaction es una plantilla de comando de cortafuegos, y el protocolo está en uno de sus marcadores. La estrechez es intencionada, ya que una jail web y una jail DNS no tienen nada que ver con bloquear puertos idénticos. Se convierte en trampa cuando el servicio escucha en más de un transporte, algo que los demonios VPN hacen de forma habitual. El filtro puede vigilar los inicios de sesión fallidos de ambos transportes mientras la acción cubre uno.

Los despliegues de SoftEther y OpenVPN suelen escuchar en UDP y TCP a la vez, y como la línea del registro se ve igual en ambos casos, el filtro vigila los dos. La asimetría nunca aparece en el informe de la propia jail. fail2ban contó correctamente los fallos y luego instaló una regla que se aplica a la mitad del tráfico por el que llegaron esos fallos.

Haga que el ban cubra los dos transportes

Arregle esto en la definición de la jail; las reglas escritas a mano se mezclarán en la próxima recarga. Especifique dos acciones, una por protocolo:

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

No intente acortarlo con protocol = all. La banaction predeterminada es una acción multiport, y se expande a -p <protocol> -m multiport --dports <port>; sin protocolo L4 no hay nada que la coincidencia de puerto pueda comprobar, así que iptables rechaza la regla mientras la jail sigue informando de un ban correcto. Una acción de todos los puertos como iptables-allports o nftables-allports acepta una sola entrada, pero bloquea todos los puertos de ese origen, lo que es una decisión distinta y necesita su propia justificación. Deje protocol en tcp o udp y acepte las dos entradas.

Demuestre que la regla existe en lugar de confiar en el ajuste, porque un ajuste describe una intención hasta que una cadena lo sostiene:

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

Cada cadena debería listar una regla, con -p tcp en la primera y -p udp en la segunda, ambas nombrando la dirección bloqueada. Luego confirme que la misma dirección se rechaza en ambos transportes. Un ban que no ha visto en la cadena es una esperanza, y el próximo informe del mismo síntoma volverá a costar la misma hora.

Lo que un ban sigue sin cubrir, y el próximo caso

Lo que hace la acción es rechazar un único origen, y solo en los puertos indicados en ella. No hace nada contra un atacante que rota direcciones, y no puede separar una máquina hostil de una salida NAT de nivel de operador compartida por cientos de usuarios, donde un solo ban deja fuera a personas que no hicieron nada. Asegúrese de que el filtro lee la dirección que el cliente tiene de verdad, no una cabecera reenviada ni una dirección de proxy. Mantenga la ventana lo bastante corta para que un error caduque solo.

Nada de eso aboga por saltarse el arreglo del protocolo; aboga por sostener dos ideas a la vez. El ban es más estrecho de lo que sugiere el resumen de la jail, e incluso un ban completo es más estrecho que la amenaza. Ponga la cadena de cortafuegos junto a la lista de escuchas del demonio y compare protocolo por protocolo, porque esas dos listas deciden si un ban puede llegar al servicio.

Guarde el comando de recarga y el listado de cadenas en el runbook junto a la jail. La siguiente persona necesitará ambos, y el resumen de la jail no le dirá ninguno de los dos.