Unha banaction, dous transportes: arranxar unha jail de fail2ban para VPN

Nada en fail2ban descarta un paquete por si só: invoca unha acción, e esa acción é a que nomea un protocolo e un porto. Cando a jail informa dun ban mentres o daemon segue aceptando inicios de sesión, o ban adoita ser real e máis estreito do que implica o rexistro. Un cliente que se reconecta polo outro transporte nunca atopa a regra que se instalou. Compare o que instalou a acción co que escoita o daemon antes de cambiar nada, porque a proba está na cadea de devasas que escribiu a acción, non na lista da jail.

Lea a cadea, non o resumo da jail

fail2ban insire a súa propia cadea diante da cadea do servizo, así que unha listaxe de contadores mostra exactamente o que existe. Unha cadea co nome da jail, que contén unha soa regra cuxa columna de protocolo di udp, é unha explicación completa dos inicios de sesión TCP que seguen chegando. Só se rexeitan os paquetes UDP da orixe bloqueada. O servizo ten un escoitador TCP, e nada nesa cadea o toca.

Ollo tamén co efecto da jail veciña. Un host pode parecer perfectamente configurado só porque outra jail achega a metade que falta, e a mesma compilación non fai nada onde esa jail non está instalada.

A acción nomea un só protocolo, e aí é onde se rompe

Cada banaction é un modelo de orde de devasas, e o protocolo está nun dos seus marcadores. A estreiteza é intencionada, xa que unha jail web e unha jail DNS non teñen nada que ver con bloquear portos idénticos. Convértese nunha trampa cando o servizo escoita en máis dun transporte, algo que os daemons VPN fan habitualmente. O filtro pode vixiar os inicios de sesión fallidos dos dous transportes mentres a acción cobre un.

Os despregamentos de SoftEther e OpenVPN adoitan escoitar en UDP e TCP á vez, e como a liña do rexistro se ve igual nos dous casos, o filtro vixía os dous. A asimetría nunca aparece no informe da propia jail. fail2ban contou correctamente os fallos e despois instalou unha regra que se aplica á metade do tráfico polo que chegaron eses fallos.

Faga que o ban cubra os dous transportes

Arranxe isto na definición da jail; as regras escritas á man mesturaranse na próxima recarga. Especifique dúas accións, unha 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"]

Non intente acurtalo con protocol = all. A banaction predeterminada é unha acción multiport, e expándese a -p <protocol> -m multiport --dports <port>; sen protocolo L4 non hai nada que a coincidencia de porto poida comprobar, así que iptables rexeita a regra mentres a jail segue informando dun ban correcto. Unha acción de todos os portos como iptables-allports ou nftables-allports acepta unha soa entrada, pero bloquea todos os portos desa orixe, o que é unha decisión distinta e necesita a súa propia xustificación. Deixe protocol en tcp ou udp e acepte as dúas entradas.

Demostre que a regra existe en lugar de confiar no axuste, porque un axuste describe unha intención ata que unha cadea o sostén:

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

Cada cadea debería listar unha regra, con -p tcp na primeira e -p udp na segunda, ambas nomeando o enderezo bloqueado. Logo confirme que o mesmo enderezo se rexeita nos dous transportes. Un ban que non viu na cadea é unha esperanza, e o próximo informe do mesmo síntoma volverá custar a mesma hora.

O que un ban aínda deixa escapar, e o próximo caso

O que fai a acción é rexeitar unha única orixe, e só nos portos indicados nela. Non fai nada contra un atacante que rota enderezos, e non pode separar unha máquina hostil dunha saída NAT de nivel de operador compartida por centos de usuarios, onde un só ban deixa fóra persoas que non fixeron nada. Asegúrese de que o filtro le o enderezo que o cliente ten de verdade, non unha cabeceira reenviada nin un enderezo de proxy. Manteña a xanela o bastante curta para que un erro caduque só.

Nada diso defende saltar o arranxo do protocolo; defende soster dúas ideas á vez. O ban é máis estreito do que suxire o resumo da jail, e mesmo un ban completo é máis estreito que a ameaza. Poña a cadea de devasas xunto á lista de escoitas do daemon e compare protocolo por protocolo, porque esas dúas listas deciden se un ban pode chegar ao servizo.

Garde a orde de recarga e a listaxe de cadeas no runbook xunto á jail. A seguinte persoa necesitará ambas, e o resumo da jail non lle dirá ningunha das dúas.