Como instalar Fail2ban no Ubuntu 24.04

O que o Fail2ban realmente faz

O Fail2ban é um daemon de leitura de logs. Ele monitora mensagens de autenticação SSH e, após algumas falhas de um mesmo endereço em um curto intervalo, executa um comando de firewall que bloqueia esse endereço temporariamente. Essa é a ideia central. São cerca de trinta linhas de configuração em um único arquivo, e no Ubuntu 24.04 a instalação é um único comando apt que garante proteção antes mesmo de você editar qualquer coisa.

Saiba exatamente o que ele é e o que não é. O Fail2ban não autentica usuários, não criptografa dados e não impede uma única tentativa de login determinada — apenas tentativas repetidas vindas da mesma origem. Ele é um filtro de ruído e um limitador de taxa, não uma fechadura. O objetivo é impedir que o escaneamento constante de background na porta 22 desperdice CPU, largura de banda e espaço de log, além de atrasar qualquer atacante que precise usar um endereço por vez.

O que o Fail2ban não substitui

O Fail2ban é a terceira camada, não a primeira. Se o seu servidor ainda aceita senhas via SSH, uma botnet distribuída por milhares de endereços pode continuar tentando adivinhações, pois cada endereço permanece abaixo do seu limite de banimento e nunca o aciona. A defesa real contra isso é a autenticação apenas por chave, que torna a adivinhação de senhas impossível, independentemente do número de tentativas. O Fail2ban operando junto com a autenticação por chave possui duas funções úteis: ele remove o ruído de brute-force dos seus logs e expulsa scanners precocemente para que parem de sobrecarregar a porta. Considere-o como defesa em profundidade. Ele atua após a autenticação por chave e após o firewall, nunca antes deles.

Pré-requisitos e a realidade do Ubuntu 24.04

Você precisa de um VPS rodando Ubuntu 24.04 com acesso root ou sudo, e SSH funcional — preferencialmente com autenticação por chave. O Fail2ban é leve: consome apenas alguns megabytes de RAM e não exige ajuste de limites.

Agora, a parte que todos os guias antigos erram. Por anos, o conselho padrão era "instale o Fail2ban e depois adicione backend = systemd, porque o Ubuntu parou de gerar /var/log/auth.log". Esse conselho descreve uma mudança real — imagens modernas de servidores e nuvem são enviadas sem rsyslog, então o SSH loga apenas no systemd journal e o arquivo de texto não existe mais — mas no Ubuntu 24.04 o pacote Fail2ban já prevê isso. O pacote instala o /etc/fail2ban/jail.d/defaults-debian.conf, e é esse arquivo, e não os padrões originais, que o seu servidor realmente utiliza:

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

[sshd]
enabled = true

Leia com atenção, pois isso resolve duas questões antes de você configurar qualquer coisa. backend = systemd significa que o jail de SSH lê o journal, então a ausência do auth.log não importa. banaction = nftables significa que os banimentos são aplicados via nftables, que é o firewall que o Ubuntu 24.04 realmente utiliza, em vez do legado iptables. E [sshd] enabled = true significa que o jail está ativo desde o primeiro boot. O resultado: um apt install fail2ban padrão no Ubuntu 24.04 bloqueia brute-force de SSH nativamente. A maior parte do seu trabalho será confirmar isso, ajustar a política e garantir que você não perca o acesso ao servidor.

A antiga armadilha do auth.log ainda ocorre em três situações, e vale a pena identificá-las: você instalou o Fail2ban com pip em vez de apt, portanto não há defaults-debian.conf; você está dentro de um container sem privilégios sem systemd journal para leitura; ou você seguiu um tutorial antigo e colou backend = auto no seu próprio jail.local, sobrescrevendo o padrão funcional. A seção de modos de falha mostra exatamente como cada um se apresenta.

Passo 1: Instalar e confirmar que o banimento já está ativo

sudo apt update
sudo apt install -y fail2ban

O Ubuntu 24.04 vem com o Fail2ban 1.0.2, e o pacote instala o python3-systemd como dependência obrigatória, portanto o backend do journal possui tudo o que é necessário. O serviço é habilitado e iniciado automaticamente:

sudo systemctl status fail2ban

Você deve verificar o status do active (running). Em seguida, verifique o jail que já está em execução:

sudo fail2ban-client status sshd

Em um VPS público que esteja acessível há apenas alguns minutos, é comum já ver falhas contabilizadas e endereços banidos — a internet realiza varreduras contínuas na porta 22. Isso prova que a configuração padrão funciona. A partir daqui, você irá refiná-la, não construí-la do zero.

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

O Fail2ban mantém os padrões originais em /etc/fail2ban/jail.conf. Não edite esse arquivo. Qualquer apt upgrade do pacote pode substituí-lo, e suas alterações serão perdidas sem aviso. O Fail2ban lê os arquivos em uma ordem fixa — jail.conf primeiro, depois tudo em jail.d/, depois jail.local — e o último valor definido prevalece. O arquivo .local é seu, e atualizações do pacote nunca o alteram. A mesma regra se aplica aos filters, onde um arquivo *.local sobrescreve o filter.d/*.conf padrão.

Portanto, escreva um pequeno jail.local que sobrescreva apenas as configurações necessárias, e deixe tanto o jail.conf quanto o jail.d/defaults-debian.conf do pacote intactos para referência.

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

sudo nano /etc/fail2ban/jail.local

Insira o conteúdo abaixo, alterando 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 específica:

• bantime, findtime, maxretry definem a política. O padrão bantime é de apenas dez minutos; uma hora é um limite mais seguro. Cinco falhas de um mesmo endereço em dez minutos resultam no banimento. Usuários reais erram a senha uma ou duas vezes; cinco falhas em dez minutos indicam um script.
• ignoreip é a sua segurança. Insira aqui o endereço público de onde você se conecta para evitar que o Fail2ban bloqueie seu próprio acesso ao servidor. Se você usa uma conexão doméstica com IP dinâmico, prefira a abordagem de VPN mencionada ao final, mas não ignore esta linha.
• bantime.increment = true faz com que cada banimento sucessivo seja mais longo que o anterior — uma hora, depois duas, depois quatro — até bantime.maxtime. Endereços recorrentes recebem bloqueios progressivamente maiores.

Para encontrar o endereço que deve ser colocado na whitelist, execute o comando na máquina de origem do SSH, não no servidor:

curl -s ifconfig.me

Você pode gerar um jail.local configurado para suas portas e política de banimento aqui, e depois colá-lo no arquivo:

Passo 4: Reinicie e verifique se o journal está sendo lido

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

O -t executa um teste de configuração primeiro. Assim, um erro de digitação em jail.local causará uma falha imediata em vez de deixar o serviço parado. O status de uma jail saudável é 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:   10.0.0.66

O número que prova que o Fail2ban está lendo seus logins é Total failed. Se estiver acima de zero, ou aumentar quando você falhar propositalmente um login de outra máquina, o journal está sendo lido e o processo terminou. Se permanecer em 0 independentemente de quantas vezes você falhar — e você tiver certeza de que não está testando a partir do endereço em ignoreip — vá para os modos de falha abaixo.

Observe que a linha Journal matches ainda cita sshd.service. No Ubuntu, a unidade SSH é na verdade ssh.service, mas o filtro incluso também faz match com _COMM=sshd, e o OpenSSH no 24.04 registra falhas de um processo chamado sshd, portanto o match funciona. Esse detalhe só importa se você estiver em um OpenSSH mais recente (9.8 ou superior, onde o worker por conexão é sshd-session); os modos de falha cobrem esse caso.

Passo 5: Monitore um banimento real ou force um para testar

Banimentos reais ocorrem automaticamente em poucos minutos em qualquer VPS pública. Para monitorar, use o tail no log:

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

Um banimento tem este formato:

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

Para testar o fluxo completo sem esperar, bana um endereço de documentação manualmente — nunca o seu próprio:

sudo fail2ban-client set sshd banip 10.0.0.66

O comando imprimirá 1, e o endereço aparecerá em Banned IP list dentro de fail2ban-client status sshd. Agora confirme se o bloqueio realmente existe no firewall. No Ubuntu 24.04, utiliza-se o nftables, não o iptables:

sudo nft list table inet f2b-table

Você verá um set chamado addr-set-sshd contendo 10.0.0.66, e uma chain f2b-chain que rejeita qualquer origem contida nesse set. Se o fail2ban-client indicar que um endereço está banido, mas nada aparecer em nft list, a ação de banimento não coincide com o seu firewall — veja a nota sobre nftables/iptables em failure modes.

Passo 6: Desbanir a si mesmo e recuperar o acesso se estiver bloqueado

Se você baniu um endereço indevidamente — como o seu próprio — remova-o:

sudo fail2ban-client set sshd unbanip 10.0.0.66

O comando retorna 1 em caso de sucesso. Para limpar todos os banimentos de todos os jails:

sudo fail2ban-client unban --all

Não dependa de uma sessão SSH já aberta para evitar o bloqueio: o banimento no nftables rejeita todos os pacotes do endereço banido para a porta 22 — incluindo conexões estabelecidas — portanto, uma sessão existente trava no momento em que o banimento é aplicado. Se você se banir e não houver uma entrada ignoreip, você ficará bloqueado até que o banimento expire — recupere o acesso através do console web do seu provedor (VNC ou serial), que não utiliza SSH, e aguarde o tempo de bantime ou execute o comando de unban por lá.

Passo 7: Tornar os bans persistentes e escalonáveis

O Fail2ban armazena bans ativos em um banco de dados SQLite em /var/lib/fail2ban/fail2ban.sqlite3, garantindo que eles sobrevivam a reinicializações do serviço ou do sistema; você não os perde. As linhas bantime.increment que você adicionou transformam cada infrator recorrente em um problema crescente para ele mesmo — aumentando aproximadamente o dobro de uma hora para uma semana.

Para uma política de "três erros" em todo o sistema, o Fail2ban inclui uma jail recidive que monitora sua própria /var/log/fail2ban.log e aplica bans longos para qualquer endereço banido repetidamente em todas as jails. Como seu [DEFAULT] agora usa o backend systemd, vincule esta jail de volta ao arquivo de log para o qual ela foi projetada:

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

O backend = auto com o logpath explícito mantém o recidive lendo o fail2ban.log puro, que é onde as linhas Ban que ele conta realmente aparecem — o padrão systemd configurado globalmente o apontaria para o journal, onde elas não estão.

Passo 8: Combine com SSH apenas por chave, ou melhor ainda, uma VPN

O Fail2ban só é realmente útil quando usado com autenticação por chave. Em um arquivo de configuração em /etc/ssh/sshd_config.d/ — por exemplo, /etc/ssh/sshd_config.d/00-hardening.conf — defina:

PasswordAuthentication no
KbdInteractiveAuthentication no

Depois, execute sudo systemctl restart ssh. Com senhas desativadas, ataques de brute force tornam-se impossíveis; o Fail2ban passa a servir apenas para reduzir o ruído nos logs e banir scanners rapidamente. Uma estratégia ainda mais segura é remover o SSH da internet pública: coloque o SSH atrás de uma VPN WireGuard própria e feche a porta 22 no firewall para que ela responda apenas via túnel. Ninguém consegue realizar brute force em uma porta inacessível, e o Fail2ban torna-se uma camada de proteção secundária em vez de linha de frente.

O Fail2ban não serve apenas para o SSH. Qualquer serviço que registre falhas de login pode ter uma jail — um servidor de e-mail, um site nginx ou um gerenciador de senhas Vaultwarden próprio cujo login web você prefira não deixar exposto a ataques de credential stuffing. Assim que um web app estiver atrás de um site nginx com certificado Let's Encrypt, aponte um filtro do Fail2ban para o log de acesso da aplicação, da mesma forma que a jail do SSH aponta para o journal.

Modos de falha, com as strings exatas que você verá

"Have not found any log file for sshd jail", e o Fail2ban não inicia. Este é o antigo problema auth.log, e no Ubuntu 24.04 você só o encontrará se algo tiver sobrescrito o padrão do pacote — uma instalação pip sem defaults-debian.conf, um container sem journal, ou um backend = auto perdido que você colou em jail.local. Em um backend de arquivo sem /var/log/auth.log, o jail do sshd não consegue encontrar seu log e o daemon aborta completamente. fail2ban.log mostra:

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

Como esse erro é fatal, o serviço nunca inicia, e o fail2ban-client status então reporta o sintoma subsequente:

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

A linha "socket path" não significa que o Fail2ban está quebrado — significa que ele nunca iniciou porque um jail não conseguiu encontrar seu log. Configurar backend = systemd em [DEFAULT], o que o pacote do Ubuntu já faz por você, corrige ambas as mensagens de uma vez.

O jail está ativo, mas o Total failed nunca se move. O daemon está rodando e o journal está sendo lido, mas falhas reais se acumulam em journalctl -u ssh enquanto o contador permanece em 0. Primeiro descarte o óbvio: você está testando de um endereço listado em ignoreip, então suas próprias falhas são isentas por design. Se não for isso, você está em uma build do OpenSSH onde o worker por conexão é sshd-session (9.8 e posteriores), cujo journal _COMM é sshd-session, não sshd, então o match padrão não o encontra. Amplie o match no bloco [sshd]:

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

Reinicie, falhe um login propositalmente de um endereço que não esteja em ignoreip e confirme que o Total failed finalmente aumenta.

Você se baniu: Connection refused. Você deixou seu próprio endereço fora de ignoreip, testou alguns logins 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 padrão da ação do nftables fazendo o trabalho dele — contra você. Corrija como no Passo 6: dê unban de uma sessão em um endereço diferente e não banido, ou pelo console do provedor — uma sessão já aberta do endereço banido também trava. Em seguida, adicione seu endereço ao ignoreip para que isso não ocorra novamente.

O Fail2ban diz que um endereço está banido, mas ele ainda consegue conectar. O contador em status sshd aumenta, mas o endereço ainda alcança a porta 22. Isso é um descompasso entre a ban-action e o firewall, e no Ubuntu 24.04 quase sempre significa que você sobrescreveu o banaction = nftables funcional com um banaction = iptables-multiport copiado de um guia antigo, em uma máquina sem camada iptables. fail2ban.log mostra:

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

Delete essa sobrescrita e mantenha a ação nftables do pacote ou, se você gerencia o firewall inteiramente via ufw e quer que os bans apareçam lá, configure banaction = ufw em [DEFAULT]. Reinicie e confirme que a regra aparece com sudo nft list ruleset | grep f2b.

O Fail2ban não inicia após editar o jail.local. Um erro de digitação — um cabeçalho perdido ou um valor de tempo inválido — faz o serviço recusar a inicialização. Peça ao Fail2ban para verificar a configuração antes de rodar:

sudo fail2ban-client -t

Ele nomeia o arquivo e o jail com o problema, por exemplo Errors in jail 'sshd'. Skipping..., para que você corrija a origem em vez de tentar adivinhar.

FAQ

O Fail2ban padrão no Ubuntu 24.04 realmente bane ataques de SSH?

Sim. O pacote inclui /etc/fail2ban/jail.d/defaults-debian.conf, que habilita a jail sshd, define backend = systemd para ler o systemd journal em vez do inexistente /var/log/auth.log, e define banaction = nftables para aplicar os bans via firewall real do Ubuntu. Um apt install fail2ban simples protege o SSH desde o primeiro boot. Confirme com sudo fail2ban-client status sshd e verifique se o valor de Total failed é diferente de zero.

Por que o Fail2ban não está banindo nada no meu servidor?

Verifique as três causas comuns nesta ordem. Você pode estar testando de um endereço em ignoreip, que é isento por padrão. Você pode ter sobrescrito a configuração padrão ao colar backend = auto em jail.local seguindo um guia antigo, o que impede a leitura do journal em imagens sem auth.log. Ou você pode estar dentro de um container sem systemd journal para leitura. Verifique Total failed em fail2ban-client status sshd: se o valor não aumentar enquanto journalctl -u ssh mostra falhas reais, a jail está lendo o local errado.

Como eu desbanimento meu próprio endereço IP?

Execute sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, que retorna 1 em caso de sucesso, ou sudo fail2ban-client unban --all para limpar todos os bans. Se você estiver bloqueado no SSH, use o console web ou VNC do seu provedor para executar o mesmo comando — o ban rejeita todos os pacotes do seu endereço para a porta 22, portanto, até uma sessão já aberta parará de funcionar. Em seguida, adicione seu endereço ao ignoreip para evitar que o bloqueio ocorra novamente.

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

O arquivo jail.conf contém os padrões originais do Fail2ban e é sobrescrito em cada atualização do pacote; qualquer edição nele será perdida. O pacote Debian/Ubuntu aplica suas próprias configurações através do jail.d/defaults-debian.conf. Suas alterações devem ser feitas no jail.local, que é o último arquivo lido e tem prioridade sobre os outros, e que nunca é alterado por atualizações. Use o jail.conf apenas como referência de leitura.

O Fail2ban substitui a autenticação SSH por chave?

Não. O Fail2ban limita a taxa de tentativas de falha repetidas de um único endereço; ele não protege contra ataques de força bruta distribuídos e lentos, onde cada endereço permanece abaixo do limite. A autenticação apenas por chave (PasswordAuthentication no) torna o ataque de senha impossível, enquanto o Fail2ban apenas reduz o ruído nos logs e remove scanners rapidamente. Utilize ambos e, idealmente, mantenha o SSH fora da internet pública.