Instalar Fail2ban no Ubuntu 24.04 e bloquear bots SSH

O que o Fail2ban faz de facto

O Fail2ban é um daemon que lê logs. Monitoriza as mensagens de autenticação do SSH e, depois de várias falhas provenientes de um endereço no espaço de tempo definido, executa um comando da firewall que bloqueia esse endereço durante algum tempo. Essa é a ideia completa. A configuração ocupa cerca de 30 linhas num ficheiro, e no Ubuntu 24.04 a instalação é feita com um único comando apt, que deixa o sistema protegido antes de alterar qualquer configuração.

É importante compreender o que ele é e o que não é. O Fail2ban não autentica utilizadores, não cifra dados e não impede uma única tentativa de início de sessão determinada; apenas bloqueia tentativas repetidas provenientes da mesma origem. É um filtro de ruído e um limitador de taxa, não um bloqueio absoluto. A função é impedir que a análise contínua da porta 22 em segundo plano consuma CPU, largura de banda e espaço nos logs, além de atrasar qualquer atacante que tenha de utilizar um endereço de cada vez.

O que o Fail2ban não substitui

O Fail2ban é a terceira camada, não a primeira. Se o seu servidor ainda aceitar palavras-passe por SSH, uma botnet distribuída por milhares de endereços pode continuar a tentar autenticar-se, porque cada endereço permanece abaixo do limite de bloqueio e nunca o atinge. A defesa real contra isso é a autenticação apenas por chave, que torna impossível adivinhar palavras-passe, independentemente do número de tentativas. O Fail2ban, sobre a autenticação apenas por chave, cumpre duas funções úteis: reduz o ruído de brute force nos logs e expulsa os scanners logo no início, para que deixem de bombardear a porta. Considere-o uma medida de defesa em profundidade. Fica atrás da autenticação por chave e da firewall, nunca à frente delas.

Pré-requisitos e a realidade do Ubuntu 24.04

Precisa de um VPS com Ubuntu 24.04, acesso root ou sudo e SSH já funcional, idealmente com autenticação por chave. O Fail2ban consome poucos recursos: algumas dezenas de megabytes de RAM, sem necessidade de ajustar limites.

Agora vem a parte em que todos os guias antigos estão errados. Durante anos, a recomendação padrão foi "instale o Fail2ban e depois adicione backend = systemd, porque o Ubuntu deixou de escrever em /var/log/auth.log." Essa recomendação só se aplica a algumas imagens. Um servidor Ubuntu 24.04 padrão ou uma imagem cloud ainda instala rsyslog. As regras padrão desse serviço escrevem em auth,authpriv.* e /var/log/auth.log. Por isso, na maioria dos VPS, as falhas de SSH aparecem também nesse ficheiro e no journal do systemd. As imagens minimalistas (a imagem cloud minimal do Ubuntu 24.04 é fornecida sem rsyslog) e a maioria dos contentores registam o SSH apenas no journal. Nesses casos, o ficheiro de texto realmente não existe. De qualquer forma, no Ubuntu 24.04 o pacote do Fail2ban já trata este caso. O pacote instala /etc/fail2ban/jail.d/defaults-debian.conf. Esse ficheiro, e não as predefinições do projeto original, é o que o seu servidor executa:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Leia isto com atenção, porque esclarece duas questões antes de alterar qualquer configuração. backend = systemd significa que a jail de SSH lê o journal. Portanto, não importa se a sua imagem escreve ou não em auth.log. banaction = nftables significa que os bloqueios são aplicados através do nftables, que é a firewall usada pelo Ubuntu 24.04, e não através do iptables antigo. [sshd] enabled = true significa que a jail fica ativa desde o primeiro arranque. Em resumo: um apt install fail2ban padrão no Ubuntu 24.04 bloqueia ataques de força bruta contra SSH sem configuração adicional. A maior parte do trabalho consiste em confirmar isso, ajustar a política e garantir que não perde o acesso ao servidor.

A armadilha antiga de auth.log ainda causa problemas em três situações. É importante reconhecê-las: instalou o Fail2ban com pip em vez de apt e, por isso, não existe defaults-debian.conf; está dentro de um contentor sem privilégios e sem um journal do systemd para consultar; ou seguiu um tutorial antigo e copiou backend = auto para o seu próprio jail.local, substituindo a predefinição funcional. A primeira e a terceira situações só impedem o bloqueio de SSH numa imagem sem rsyslog, como uma imagem minimalista. Quando rsyslog está em execução, o backend de ficheiros encontra /var/log/auth.log e funciona. A secção sobre modos de falha mostra exatamente o resultado de cada situação.

Passo 1: Instale e confirme que o bloqueio já está ativo

sudo apt update
sudo apt install -y fail2ban

O Ubuntu 24.04 inclui o Fail2ban 1.0.2, e o pacote instala python3-systemd como dependência obrigatória. Por isso, o backend do journal já tem tudo de que precisa. O serviço é ativado e iniciado automaticamente:

sudo systemctl status fail2ban

O resultado esperado é active (running). Em seguida, consulte a jail que já está a funcionar:

sudo fail2ban-client status sshd

Num VPS público que esteja acessível há apenas alguns minutos, é comum já ver falhas contabilizadas e endereços bloqueados. A Internet verifica continuamente a porta 22. Isso prova que a configuração padrão funciona. A partir daqui, irá aperfeiçoá-la, não criá-la do zero.

Passo 2: Edite jail.local, nunca jail.conf

O Fail2ban mantém os valores predefinidos originais em /etc/fail2ban/jail.conf. Não edite esse ficheiro. Uma atualização do pacote pode substituí-lo, como avisa o cabeçalho do próprio ficheiro, e as suas alterações podem ser perdidas. O Fail2ban lê os ficheiros por uma ordem fixa: primeiro jail.conf, depois jail.d/*.conf por ordem alfabética, depois jail.local e, por fim, jail.d/*.local por ordem alfabética. O último valor lido prevalece. Assim, jail.local substitui defaults-debian.conf, mas qualquer ficheiro *.local que coloque em jail.d/ é lido depois e substitui esse valor; mantenha as suas substituições num único local para saber qual é o valor efetivo. O ficheiro .local é seu, e as atualizações do pacote nunca o alteram. A mesma regra aplica-se aos filtros: um ficheiro *.local substitui o filter.d/*.conf fornecido pelo pacote.

Por isso, crie um pequeno jail.local que substitua apenas as poucas definições relevantes e deixe jail.conf e o jail.d/defaults-debian.conf fornecido pelo pacote intactos, como referência.

Passo 3: Escreva /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Insira este conteúdo e altere o endereço na linha ignoreip para o seu próprio IP público:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Cada linha tem uma função:

• bantime, findtime e maxretry definem a política. O valor predefinido fornecido em bantime é de apenas dez minutos; uma hora é um limite mínimo mais adequado. Cinco falhas do mesmo endereço no período de dez minutos resultam num bloqueio. Pessoas reais introduzem uma palavra-passe incorreta uma ou duas vezes; cinco falhas em dez minutos indicam um script.
• ignoreip é a sua proteção contra bloqueios acidentais. Insira aqui o endereço público a partir do qual estabelece a ligação, para que o Fail2ban nunca possa bloquear o acesso ao seu próprio servidor. Uma ligação doméstica com IP variável é um motivo para preferir a abordagem com VPN apresentada no final, não para omitir esta linha.
• bantime.increment = true faz com que cada bloqueio repetido dure mais tempo do que o anterior: uma hora, depois duas, depois quatro, até bantime.maxtime. Os endereços que continuam a voltar ficam progressivamente bloqueados durante mais tempo.

Obtenha o endereço a colocar na lista de permissões a partir da máquina a partir da qual estabelece a ligação SSH, não a partir do servidor:

curl -s ifconfig.me

Pode gerar aqui um jail.local ajustado às suas portas e à política de bloqueio e, depois, inseri-lo no ficheiro:

Etapa 4: Reinicie e confirme que está a ler o journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

O -t executa primeiro um teste da configuração. Assim, um erro de escrita em jail.local falha claramente neste ponto, em vez de deixar o serviço parado. O estado de uma jail saudável é semelhante a este:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   203.0.113.66

O número que confirma que o Fail2ban está efetivamente a ler os seus logins é Total failed. Se for superior a zero ou aumentar quando provocar deliberadamente uma falha de login a partir de outra máquina, o journal está a ser lido e terminou. Se permanecer em 0, independentemente do número de falhas provocadas, e tiver a certeza de que não está a testar a partir do endereço em ignoreip, avance para os modos de falha abaixo.

Observe que a linha Journal matches ainda indica sshd.service. No Ubuntu, a unidade SSH é efetivamente ssh.service, mas o filtro fornecido também corresponde a _COMM=sshd. Além disso, o OpenSSH 24.04 regista as falhas a partir de um processo chamado sshd, pelo que a correspondência funciona. Este detalhe só é relevante se estiver a utilizar uma versão mais recente do OpenSSH (9.8 ou posterior, em que o worker por ligação é sshd-session); os modos de falha abrangem esse caso.

Etapa 5: Observe um bloqueio real ou force um para testar

Os bloqueios reais surgem sozinhos em poucos minutos em qualquer VPS público. Para observar um, acompanhe o log:

sudo tail -f /var/log/fail2ban.log

Um bloqueio tem este aspeto:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

Para testar todo o funcionamento sem esperar, bloqueie manualmente um endereço reservado para documentação. Nunca bloqueie o seu próprio endereço. 203.0.113.66 pertence a TEST-NET-3, um bloco reservado para documentação. Por isso, não pode ser um host real nem um endereço privado na rede do seu fornecedor:

sudo fail2ban-client set sshd banip 203.0.113.66

O comando apresenta 1, e o endereço aparece em Banned IP list dentro de fail2ban-client status sshd. Agora confirme que o bloqueio existe efetivamente na firewall. No Ubuntu 24.04, o sistema utilizado é nftables, não iptables:

sudo nft list table inet f2b-table

Verá um conjunto chamado addr-set-sshd que contém 203.0.113.66 e uma cadeia f2b-chain que rejeita qualquer origem presente nesse conjunto. Se fail2ban-client indicar que um endereço está bloqueado, mas nada aparecer em nft list, a ação de bloqueio não corresponde à firewall. Consulte a nota sobre nftables/iptables na secção de resolução de problemas.

Passo 6: Remova o seu próprio bloqueio e recupere o acesso se ficar bloqueado

Se bloqueou um endereço que não devia, incluindo o seu próprio, remova-o:

sudo fail2ban-client set sshd unbanip 203.0.113.66

Em caso de sucesso, o comando devolve 1. Para limpar todos os bloqueios em todas as jails:

sudo fail2ban-client unban --all

Não conte com uma sessão SSH já aberta para o salvar: o bloqueio do nftables rejeita todos os pacotes do endereço bloqueado para a porta 22, incluindo os de ligações estabelecidas. Por isso, uma sessão existente bloqueia assim que o bloqueio é aplicado. Se se bloquear e não tiver uma entrada ignoreip, ficará sem acesso até o bloqueio expirar. Recupere o acesso através da consola Web do seu fornecedor (VNC ou serial), que não passa pelo SSH, e aguarde bantime ou execute aí o comando para remover o bloqueio.

Passo 7: Faça as proibições persistirem e aumentarem

O Fail2ban mantém as proibições ativas numa pequena base de dados SQLite em /var/lib/fail2ban/fail2ban.sqlite3, para que sobrevivam ao reinício do serviço ou a um reboot; não as perde. As linhas bantime.increment que adicionou anteriormente transformam cada infrator reincidente num problema cada vez maior para si próprio, aumentando aproximadamente para o dobro, de uma hora até cerca de uma semana.

Para aplicar uma política global de "três infrações", o Fail2ban inclui uma jail recidive que monitoriza o seu próprio /var/log/fail2ban.log e aplica proibições longas a qualquer endereço que tenha sido proibido repetidamente em várias jails. Como o seu [DEFAULT] agora usa o backend systemd, fixe esta jail novamente no ficheiro de log que foi concebida para ler:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto com o logpath explícito mantém recidive a ler o fail2ban.log simples. É nesse ficheiro que aparecem efetivamente as linhas Ban contabilizadas. O valor predefinido do systemd que definiu globalmente apontaria para o journal, onde essas linhas não aparecem.

Passo 8: Combine com SSH baseado apenas em chaves e, melhor ainda, com uma VPN

O Fail2ban só é realmente eficaz quando usado com autenticação por chave. Num ficheiro de configuração complementar em /etc/ssh/sshd_config.d/, por exemplo /etc/ssh/sshd_config.d/00-hardening.conf, defina:

PasswordAuthentication no
KbdInteractiveAuthentication no

Depois, sudo systemctl restart ssh. Com as palavras-passe desativadas, a força bruta não pode ter sucesso; o Fail2ban serve então para reduzir o ruído nos logs e bloquear os scanners logo no início. Mais seguro ainda é manter o SSH completamente fora da Internet pública: coloque o SSH atrás de uma VPN WireGuard autoalojada e configure a firewall para que a porta 22 responda apenas através do túnel. Ninguém pode fazer força bruta contra uma porta à qual não consegue chegar, e o Fail2ban passa a ser uma proteção secundária, não a primeira linha de defesa.

O Fail2ban não serve apenas para SSH. Qualquer serviço que registe tentativas de início de sessão falhadas pode ter uma jail: um servidor de correio, um site nginx ou um gestor de palavras-passe Vaultwarden autoalojado, cujo início de sessão web talvez não queira deixar exposto a tentativas automatizadas de credenciais. Depois de uma aplicação web ficar atrás de um site nginx com um certificado Let's Encrypt, aponte um filtro do Fail2ban para o respetivo access log, tal como a jail do SSH aponta para o journal.

Modos de falha, com as strings exatas que verá

"Have not found any log file for sshd jail", e o Fail2ban não inicia. Este é o problema antigo de auth.log. No Ubuntu 24.04, só ocorre quando /var/log/auth.log não existe, por exemplo, numa imagem sem rsyslog, como uma imagem mínima ou um contentor, e o journal não está a ser lido: uma instalação pip sem defaults-debian.conf, um contentor sem journal ou um backend = auto isolado que colou em jail.local. Num backend de ficheiro sem /var/log/auth.log, a jail sshd não encontra o seu log e o daemon termina. fail2ban.log mostra:

ERROR   Failed during configuration: Have not found any log file for sshd jail

Como esse erro é fatal, o serviço não inicia e fail2ban-client status apresenta o sintoma seguinte:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

Essa linha sobre o "socket path" não significa que o Fail2ban esteja avariado. Significa que ele nunca iniciou porque uma jail não conseguiu encontrar o seu log. Definir backend = systemd em [DEFAULT], algo que o pacote do Ubuntu já faz por si, corrige ambas as mensagens.

A jail está ativa, mas Total failed nunca avança. O daemon está em execução e o journal está a ser lido, mas as falhas reais acumulam-se em journalctl -u ssh enquanto o contador permanece em 0. Primeiro, exclua a causa óbvia: está a testar a partir de um endereço listado em ignoreip, pelo que as suas próprias falhas são excluídas por definição. Se não for esse o caso, está a usar uma compilação do OpenSSH em que o worker por ligação é sshd-session (9.8 e posteriores). O _COMM correspondente no journal é sshd-session, não sshd, pelo que a correspondência fornecida não o deteta. Alargue a correspondência no bloco [sshd]:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Reinicie, provoque deliberadamente uma falha de início de sessão a partir de um endereço que não esteja em ignoreip e confirme se Total failed finalmente aumenta.

Baniu-se a si próprio: Connection refused. Não incluiu o seu próprio endereço em ignoreip, testou alguns inícios de sessão incorretos e agora:

ssh: connect to host 10.0.0.10 port 22: Connection refused

A recusa, em vez de um timeout silencioso, é o veredito reject predefinido da ação nftables a funcionar contra si. Corrija o problema conforme descrito no passo 6: remova o ban a partir de uma sessão num endereço diferente que não esteja banido ou a partir da consola do fornecedor. Uma sessão já aberta a partir do endereço banido também fica bloqueada. Depois, adicione o seu endereço a ignoreip para evitar que isto volte a acontecer.

O Fail2ban indica que um endereço está banido, mas ele continua a conseguir ligar-se. O contador em status sshd aumenta, mas o endereço continua a alcançar a porta 22. Isto indica uma incompatibilidade entre a ação de ban e a firewall. No Ubuntu 24.04, quase sempre significa que substituiu o banaction = nftables funcional por banaction = iptables-multiport, copiado de um guia antigo, num sistema sem a camada iptables. fail2ban.log mostra:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Elimine essa substituição e deixe ativa a ação nftables fornecida pelo pacote. Em alternativa, se gerir a firewall inteiramente através do ufw e quiser que os bans apareçam aí, defina banaction = ufw em [DEFAULT]. Reinicie e confirme que a regra aparece com sudo nft list ruleset | grep f2b.

O Fail2ban não inicia depois de editar jail.local. Um erro de escrita, um cabeçalho isolado ou um valor de tempo inválido faz com que o serviço recuse iniciar. Peça ao Fail2ban para validar a configuração antes de o executar:

sudo fail2ban-client -t

O comando identifica o ficheiro e a jail com o problema, por exemplo Errors in jail 'sshd'. Skipping.... Assim, corrige a origem em vez de tentar adivinhar.

FAQ

A instalação padrão do Fail2ban no Ubuntu 24.04 bloqueia mesmo ataques SSH?

Sim. O pacote inclui /etc/fail2ban/jail.d/defaults-debian.conf, que ativa a jail sshd, define backend = systemd para ler o journal do systemd, independentemente de a imagem escrever ou não /var/log/auth.log, e define banaction = nftables para que os bloqueios sejam aplicados através da firewall real do Ubuntu. Um apt install fail2ban simples protege o SSH desde o primeiro arranque. Confirme com sudo fail2ban-client status sshd e procure um valor diferente de zero em Total failed.

Por que motivo o Fail2ban não está a bloquear nada no meu servidor?

Exclua as três causas comuns pela ordem indicada. Pode estar a testar a partir de um endereço em ignoreip, que está isento por definição. Pode ter substituído a configuração padrão funcional ao colar backend = auto em jail.local com base num guia antigo. Isso interrompe o bloqueio de SSH numa imagem sem rsyslog e, portanto, sem auth.log. Ou pode estar dentro de um contentor sem qualquer journal do systemd disponível para leitura. Verifique Total failed em fail2ban-client status sshd: se nunca aumentar enquanto journalctl -u ssh mostra falhas reais, a jail está a ler o local errado.

Como removo o bloqueio do meu próprio endereço IP?

Execute sudo fail2ban-client set sshd unbanip YOUR.IP.HERE. Em caso de sucesso, o comando devolve 1. Também pode executar sudo fail2ban-client unban --all para remover todos os bloqueios. Se perdeu o acesso por SSH, use a consola web ou VNC do seu fornecedor para executar o mesmo comando. O bloqueio rejeita todos os pacotes do seu endereço para a porta 22. Por isso, até uma sessão já aberta deixa de funcionar. Depois, adicione o seu endereço a ignoreip para impedir que o problema se repita.

Qual é a diferença entre jail.conf e jail.local?

jail.conf contém os valores padrão do Fail2ban fornecidos pelo projeto e pode ser substituído durante uma atualização do pacote. Por isso, qualquer alteração nesse ficheiro fica em risco. O pacote Debian/Ubuntu aplica as suas próprias definições através de jail.d/defaults-debian.conf. As suas alterações devem ficar em jail.local. Esse ficheiro é lido depois dos dois anteriores e prevalece sobre eles. As atualizações nunca o alteram. Apenas um ficheiro *.local dentro de jail.d/ é lido posteriormente. Por isso, não deixe ficheiros adicionais nesse diretório. Mantenha jail.conf apenas como referência de leitura.

O Fail2ban substitui a autenticação SSH baseada em chaves?

Não. O Fail2ban limita a frequência de falhas repetidas provenientes de um endereço. Não impede uma tentativa lenta e distribuída em que cada endereço permanece abaixo do limite. A autenticação apenas com chaves (PasswordAuthentication no) torna impossível a tentativa de palavras-passe, e o Fail2ban reduz o ruído nos logs e remove os scanners mais cedo. Use ambos e, idealmente, mantenha o SSH totalmente fora da Internet pública.