Maximum bantime with fail2ban

Question

Estou usando fail2ban/firewalld para restringir o acesso semelhante a bot a um servidor Nginx . Normalmente, a configuração da cadeia correspondente é semelhante a:

[nginx-botsearch]
#banaction = iptables-multiport
enabled = true
filter = nginx-botsearch
logpath = /var/log/nginx*/*access*.log
maxretry = 3
bantime = 3600

Isso funciona como esperado (o padrão de banimento é firewallcmd-ipset ), ou seja, o comando iptables -L mostra uma entrada na cadeia INPUT_direct :

REJECT     tcp  --  anywhere             anywhere             multiport dports http,https match-set fail2ban-nginx-botsearch src reject-with icmp-port-unreachable

com o correspondente ipset de fail2ban-nginx-botsearch .

No entanto, notei um comportamento estranho quando o bantime é aumentado. Tudo funciona como esperado para bantime <= 4294967 . Quando eu defino bantime = 4294968 e recarrego fail2ban service, a entrada na saída iptables está ausente (o ipset não é criado) e, de fato, testar com, por exemplo, o utilitário ab mostra que a proibição não é aplicada . Curiosamente, usar banaction = iptables-multiport funciona mesmo para bantimes "grandes". Qual pode ser a razão para esse comportamento? Estou usando o fail2ban v 0.9.7 no CentOS 7.

    

Answer 1

Este não é um problema estritamente relacionado a fail2ban , mas sim um erro no código netfilter em seu kernel. Em resumo, sua versão de ipset tem um estouro de inteiro para o parâmetro timeout , então você vê um comportamento imprevisível quando excede o inteiro de 32 bits.

Você não vê isso com multiportas, pois não usa esse código e, em vez disso, confia em seus próprios dispositivos para rastrear os tempos limite.

Aqui está um link para o patch para este problema no código do netfilter.