Eu tentei isso e parece provável que suas suspeitas estejam corretas:
[root@risby home]# iptables -A FOO -m recent --update --seconds 300 --hitcount 200 -j DROP
iptables: Invalid argument. Run 'dmesg' for more information.
[root@risby home]# dmesg|tail -1
[1141835.281122] xt_recent: hitcount (200) is larger than packets to be remembered (20)
man iptables
revela o seguinte:
--hitcount hits This option must be used in conjunction with one of --rcheck or --update. When used, this will narrow the match to only happen when the address is in the list and packets had been received greater than or equal to the given value. This option may be used along with --seconds to create an even narrower match requiring a certain number of hits within a specific time frame. The maximum value for the hitcount parameter is given by the "ip_pkt_list_tot" parameter of the xt_recent kernel module. Exceeding this value on the command line will cause the rule to be rejected.
Então, se eu fosse você, tentaria eliminar esse 200
para 10
. Se isso faz com que o problema desapareça (ou, pelo menos, deixe essa linha), você identificou o problema. Eu executei um strings
no módulo do kernel e procurei por esse parâmetro e encontrei, entre outros, as duas entradas a seguir:
parm=ip_pkt_list_tot:number of packets per IP address to remember (max. 255)
parmtype=ip_pkt_list_tot:uint
que me dizem que este parâmetro pode ser definido como um argumento quando o módulo é carregado, mas não pode em caso algum exceder 255. Esse é o tipo de limite que me faz pensar que mesmo recompilar seu próprio kernel não ajuda, e você teria que reescrever o módulo para usar mais do que um contador de um byte ( uint
= inteiro sem sinal); Eu suspeito que isso não vai estar na agenda.
Espero que o texto acima mostre alguma luz sobre o problema e possíveis remediações.