De acordo com a documentação, definir o banimento da prisão para um valor negativo deve resultar em um banimento permanente. No entanto, uma vez feito isso, o seguinte comportamento muda, em comparação com a definição de bantime como um número inteiro positivo:
1) ipset listnão mostra tabela hash fail2ban-sshd
2) firewall-cmd --direct --get-all-rulesestá vazio
3) /var/log/fail2ban.logtorna-se uma única linha. entrada interessante
sshd[25772]: Usuário ubuntu inválido de 93.174.89.88 porta 37477', 'ip': '93.174.89.88', 'ipmatches': em 0x7f4588f9dc08>, 'ipfailures': em 0x7f4588f9daa0>, 'time' 15363018 42.088076, 'falhas ': 1443, 'ipjailfailures': at 0x7f4588f9dd70>})': Erro ao banir 93.174.89.88
4) /var/log/messagestem o seguinte
firewalld[916]: AVISO: '/usr/sbin/iptables-restore --wait=2 -n' falhou: iptables-restore v1.4.21: O conjunto fail2ban-sshd não existe.#012#012Ocorreu um erro na linha: 2#012Tente 'iptables-restore -h' ou 'iptables-restore --help' para obter mais informações. firewalld[916]: ERRO: COMMAND_FAILED
O único comando funcionando conforme o esperado é fail2ban-client status sshd, porém os IPs que aparecem banidos ainda tentam se conectar. Acho que a raiz de todos os problemas é que o ipset não é criado por qualquer motivo, uma vez que o número inteiro é negativo.
Alguma ideia? Além disso, o comando fail2ban-client reloadtem o mesmo efeito que systemctl restart fail2ban.serviceao aplicar uma nova configuração?
No meu caso, /etc/fail2ban/jail.d/local.conf
[sshd]
enabled = true
bantime = -1
findtime = 3600
maxretry = 5
action = %(action_)s
Responder1
Este era um bug nas versões mais antigas do fail2ban. Desde então, isso foi corrigido, mas se a sua distribuição Linux ainda enviar essa versão mais antiga, você também pode precisar de uma solução alternativa.
OProblema no GitHubque explica o problema e a correção também inclui uma solução alternativa:
Isso foi corrigido nas versões mais recentes. Para 0.9 você pode simplesmente sobrescrever o parâmetro bantime (timeout) em ação dentro da prisão (o tempo limite do parâmetro para a regra persistente do ipset é 0).
[sshd] bantime = -1 action = %(banaction)s[name=%(__name__)s, bantime=0, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
Responder2
ipset só pode ter um tempo limite mínimo de 0 ou um tempo limite máximo de 2147483, consultehttp://ipset.netfilter.org/ipset.man.html
timeout Todos os tipos de conjunto suportam o parâmetro opcional timeout ao criar um conjunto e adicionar entradas. O valor do parâmetro timeout para o comando create significa o valor de tempo limite padrão (em segundos) para novas entradas. Se um conjunto for criado com suporte de tempo limite, a mesma opção de tempo limite poderá ser usada para especificar valores de tempo limite não padrão ao adicionar entradas. O valor de tempo limite zero significa que a entrada é adicionada permanentemente ao conjunto. O valor de tempo limite de elementos já adicionados pode ser alterado adicionando novamente o elemento usando a opção -exist. O maior valor de tempo limite possível é 2147483 (em segundos).
o valor que é utilizado para a criação do timeout do ipset é o valor conf bantime. como você tem um -1 no valor conf do bantime, seu sistema está tendo um erro ao criar o ipset para as jails do fail2ban, já que não há nenhum ipset criado porque você está basicamente fazendo o sistema executar algo assim:
ipset create fail2ban-sshd hash:ip timeout -1
O intervalo de valores de tempo limite aceitável é de 0 a 2147483 segundos. depois, sem um ipset chamado fail2ban-sshd executando algo como:
firewall-cmd --direct --add-rule ipv4 filter INPUT_direct 0 -p tcp -m multiport --dports http,https -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable
ou:
iptables -t filter -I INPUT_direct 1 -p tcp -m multiport --dports http,https -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable
certamente falharia, pois não há nenhum ipset chamado fail2ban-sshd que foi criado. você deve alterar seu -1 bantime para 0.