Instalando e usando Fail2ban no Debian 12
Nesta página
- Como funciona
Configurando Fail2ban
- Habilitando uma prisão
- Siga os registros
- Solução de problemas
- Lista de permissões de endereços IP próprios
- Banir manualmente
- Desbanindo manualmente
- Conclusão
Fail2ban monitora arquivos de log em busca de falhas de login e proíbe temporariamente o endereço IP de origem propenso a falhas de acessar o host. Esta é uma defesa contra ataques de força bruta para adivinhação de senhas. É muito útil ter fail2ban em hosts expostos à Internet.
A versão do fail2ban no Debian 12 é 1.0.2.
root@posti:~# fail2ban-client version
1.0.2
Para ver se o fail2ban está em execução no momento, envie ao servidor o comando ping com fail2ban-client. O servidor Fail2ban responde "pong" se estiver em execução.
root@posti:/etc/fail2ban# fail2ban-client ping
Server replied: pong
root@posti:/etc/fail2ban#
Como funciona
Fail2ban coleta filtros, ações e arquivos monitorados em uma prisão. Várias prisões acompanham a distribuição. Eles precisam estar habilitados para começar a funcionar. filter especifica como detectar falhas de autenticação. A ação define como acontece o banimento e o desbanimento.
As tentativas de intrusão acionam o banimento se durante o findtime pelo menos falhas de login de maxretry forem detectadas no mesmo número IP. Então o IP é banido por segundos de banimento. Depois que o banimento estiver em vigor por alguns segundos, o banimento será suspenso e o IP poderá acessar novamente o host. Fail2ban pode lidar com IPv4 e IPv6.
Mais informações podem ser lidas nos arquivos no diretório /usr/share/doc/fail2ban/.
Configurando Fail2ban
Em sistemas Debian GNU/Linux, o fail2ban é instalado por padrão com o sshd jail habilitado com configurações razoáveis. Isso é feito no arquivo /etc/fail2ban/jail.d/defaults-debian.conf. Essa é a única prisão que funciona por padrão. Outras jails devem ser habilitadas pelo administrador do sistema.
Portanto, se você deseja apenas que os logins ssh sejam monitorados e os intrusos que se comportam mal sejam banidos, nenhuma configuração adicional é necessária.
Infelizmente, no Debian 12, fail2ban pode não funcionar com configurações padrão. O Debian 12 marcou o pacote rsyslog como opcional, o que significa que ele pode não ser instalado, portanto os logs são coletados apenas no journald [wiki.debian.org/Rsyslog].
Em sistemas ISPConfig, o fail2ban funciona, pois o autoinstalador ISPConfig instala o rsyslog e o tutorial do servidor ISPConfig Perfect instrui a instalar o rsyslog.
Com o rsyslog, os arquivos de log aparecem no diretório /var/log/, portanto, a configuração padrão do fail2ban encontra os arquivos de log. Se o rsyslog não estiver instalado, a configuração do fail2ban deverá ser modificada para que ele leia os logs do diário do systemd. Adicione à seção padrão jail.local backend=systemd, assim
[DEFAULT]
backend = systemd
Habilitando uma prisão
A documentação recomenda colocar todas as modificações próprias nos arquivos .local. Isto evita problemas quando os arquivos fornecidos pela distribuição são atualizados ou modificados pelo mantenedor [Leia o arquivo /usr/share/doc/fail2ban/README.Debian.gz].
Por exemplo, habilitar o jail-ftpd puro é feito adicionando ao arquivo /etc/fail2ban/jail.local (crie o arquivo se ele ainda não existir) as linhas
[pure-ftpd]
enabled = true
O nome da prisão entre colchetes inicia a seção de configurações dessa prisão.
Ao terminar as modificações, force a releitura dos arquivos de configuração com o comando
systemctl reload fail2ban
A prisão agora deve estar em execução, o que pode ser verificado com fail2ban-client:
root@posti:/etc/fail2ban# fail2ban-client status pure-ftpd
Status for the jail: pure-ftpd
|- Filter
| |- Currently failed: 0
| |- Total failed: 106
| `- File list: /var/log/syslog
`- Actions
|- Currently banned: 0
|- Total banned: 4
`- Banned IP list:
root@posti:/etc/fail2ban#
Como jail.local possui apenas a configuração "ativada" para essa prisão, todas as outras configurações são configurações padrão da distribuição. Geralmente eles têm bons valores, portanto configurações adicionais são desnecessárias. Se necessário, a seção jail.local dessa prisão pode conter configurações que substituem o que foi definido nos arquivos .conf.
Este exemplo altera findtime, maxretry e bantime para jail-ftpd puro:
[pure-ftpd]
enabled = true
findtime = 2h
maxretry = 6
bantime = 1d
O Fail2ban-client mostra os tempos em segundos, mas os tempos podem ser inseridos nos arquivos de configuração em um formato mais fácil, por exemplo 10h em vez de 36.000 segundos. man jail.conf no capítulo "FORMATO DE ABREVIAÇÃO DE TEMPO" explica os formatos de entrada de tempo amigáveis.
fail2ban-client tem a opção de converter de um formato de hora amigável para segundos.
# fail2ban-client --str2sec 1d3h7m
97620
Siga os registros
Para determinar quais jails devem ser ativadas, siga os logs criados pelos serviços em execução no host. Uma ferramenta que cria resumos de logs, como logwatch ou pflogsumm, é útil. Ler logs brutos é demorado e tedioso.
Verifique se há uma prisão disponível para um serviço em execução no host, talvez lendo jail.conf.
Assim que os registros mostrarem algo interessante ou preocupante, é hora de examinar. Por exemplo, pflogsumm enviou um resumo por e-mail com linhas como esta:
136 unknown[91.224.92.40]: SASL LOGIN authentication failed: UGFzc3...
136 hostname srv-91-224-92-40.serveroffer.net does not resolve to a...
123 unknown[193.32.162.23]: SASL LOGIN authentication failed: UGFzc...
123 hostname mail.whatami.co does not resolve to address 193.32.162.23
Isso mostra que o IP 91.224.92.40 falhou 136 vezes ao registrar no e-mail e outro caso semelhante. Fail2ban deveria ter evitado tantas tentativas. Para ver por que isso não aconteceu, examine o log fail2ban.
root@posti:/etc/apt/apt.conf.d# grep 91.224.92.40 /var/log/fail2ban.log | head
2024-02-18 00:01:38,718 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:01:38
2024-02-18 00:11:50,261 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:11:50
2024-02-18 00:21:54,337 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:21:54
2024-02-18 00:32:14,232 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:32:14
2024-02-18 00:42:37,921 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:42:37
2024-02-18 00:53:06,796 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:53:06
2024-02-18 01:03:35,293 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:03:35
2024-02-18 01:14:03,765 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:14:03
2024-02-18 01:24:24,628 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:24:24
2024-02-18 01:34:43,876 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:34:43
root@posti:/etc/apt/apt.conf.d#
Esse IP tenta conectar-se em intervalos de cerca de 10 minutos e o fail2ban jail postfix-sasl o detecta.
É uma boa ideia descobrir se esse IP pertence a um usuário legítimo do host, que apenas possui uma senha antiga no smartphone ou algum outro dispositivo tentando se conectar em intervalos regulares. Eu uso o geoiplookup, ele mostra de que país é o IP. Meus usuários são do meu país, então usuários estrangeiros tendem a ser malfeitores. geoiplookup vem dos pacotes Debian geoip-database e geoip-bin.
$ geoiplookup 91.224.92.40
GeoIP Country Edition: LT, Lithuania
Para descobrir por que o IP não foi banido, examine o findtime dessa prisão:
root@posti:/etc/apt/apt.conf.d# fail2ban-client get postfix-sasl findtime
600
root@posti:/etc/apt/apt.conf.d#
Recentemente, vi esses ataques lentos, o perpetrador sabe que o tempo de localização é de 10 minutos, então tenta evitar ser banido tentando logins em intervalos mais longos. Isso funcionou neste caso. Para fazer com que logins com falha causem banimentos, aumente o tempo de localização da prisão, por exemplo, para 10 horas. Adicione ao arquivo jail.local na seção [postfix-sasl]:
findtime = 10h
Então, após systemctl recarregar fail2ban, a prisão terá um tempo de localização mais longo:
root@posti:/etc/fail2ban# fail2ban-client get postfix-sasl findtime
36000
root@posti:/etc/fail2ban#
Outra forma de os intrusos tentarem invadir é sendo persistentes. Mesmo que o intruso seja banido, espere até o banimento terminar e continue adivinhando a senha. O período de banimento poderia ser prolongado, mas isso causa problemas para usuários legítimos, que podem digitar a senha incorretamente e não conseguir acessar sua conta até que o período de banimento termine. Existe uma prisão para reincidentes chamada reincidente. Ele funciona procurando banimentos repetidos para um IP no log do fail2ban e depois banindo por um longo período, por exemplo, uma semana.
A listagem a seguir é do relatório logwatch:
--------------------- pam_unix Begin ------------------------
sshd:
Authentication Failures:
unknown (212.70.149.150): 59 Time(s)
Pesquisar esse IP no arquivo de log mostra:
2024-02-21 03:42:39,121 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 03:42:38
2024-02-21 03:42:39,508 fail2ban.actions [895]: NOTICE [sshd] Ban 212.70.149.150
2024-02-21 03:52:38,386 fail2ban.actions [895]: NOTICE [sshd] Unban 212.70.149.150
2024-02-21 03:54:33,560 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 03:54:33
2024-02-21 03:54:35,364 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 03:54:35
2024-02-21 04:00:37,017 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:00:36
2024-02-21 04:00:39,021 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:00:38
2024-02-21 04:06:43,036 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:06:42
2024-02-21 04:06:45,039 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:06:44
2024-02-21 04:06:45,426 fail2ban.actions [895]: NOTICE [sshd] Ban 212.70.149.150
2024-02-21 04:16:44,302 fail2ban.actions [895]: NOTICE [sshd] Unban 212.70.149.150
2024-02-21 04:19:04,868 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:19:04
Fail2ban funciona como esperado, encontrando logins errados e banindo por 10 minutos. Durante este banimento, o infrator é impedido de acessar este host, mas continua após o banimento ser suspenso. Este parece ser o caso de uma tentativa séria de invasão. A solução é permitir a prisão recidiva com tentativas baixas e banimentos longos.
Gosto de usar um banimento inicial curto, digamos 10 minutos. Se um usuário real for banido, ele estará apenas aguardando esse momento, usando o tempo para descobrir qual é a senha correta e tentar novamente. Aqueles que forem banidos novamente no mesmo dia serão banidos por uma semana. Os valores padrão de prisão recidiva podem ser encontrados no arquivo jail.conf, há bantime de 1 semana e findtime de 1 dia, esses parecem bons para mim. Mas eu configurei maxretry para 2, os infratores são banidos mais rapidamente. Adicionei ao arquivo jail.local:
[recidive]
enabled = true
maxretry = 2
Proibições por mais de 1 semana não valem a pena, na minha opinião. Eventualmente, o endereço IP antigo é banido ou colocado na lista negra em todos os lugares, então o infrator obtém um novo IP. O IP antigo é dado a algum novo usuário inocente da Internet, que não deve ser punido pelas coisas ruins das quais o proprietário anterior desse IP é culpado.
Solução de problemas
Depois de inicializar o sistema operacional ou reiniciar, o estado fail2ban é restaurado, então os banimentos continuam até que o tempo de banimento termine. Assim, os testes e a solução de problemas podem envolver reinicializações.
Para testar a configuração, existe uma opção de teste:
fail2ban-server --test
Para descobrir se um IP foi banido, versões recentes do fail2ban podem fazer
# fail2ban-client banned 43.131.9.186
[['recidive']]
O comando mostra a lista de prisões onde determinado IP está atualmente banido.
Versões mais antigas do fail2ban não possuem esse comando. Testar cada prisão uma por uma pode ser feito assim:
# fail2ban-client status recidive | tr " " "\n" | grep 43.163.219.232
43.163.219.232
Se a saída mostrar o IP, então ele estava na lista de números IP banidos. O comando tr existe para quebrar a lista de números IP banidos (é uma linha longa) para um IP por linha.
Para ver o que está acontecendo com um determinado IP, procure em fail2ban.log:
root@posti:/etc/mysql# grep 43.131.9.186 /var/log/fail2ban.log | cut --characters=-80
2024-03-06 09:00:40,295 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:02:53,954 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:02:55,958 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:04:34,193 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:04:36,195 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:04:36,388 fail2ban.actions [3574846]: NOTICE [sshd] Ban 43
2024-03-06 09:04:36,626 fail2ban.filter [3574846]: INFO [recidive] Fo
2024-03-06 09:14:35,180 fail2ban.actions [3574846]: NOTICE [sshd] Unban
2024-03-06 09:15:10,073 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:16:55,919 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:16:58,522 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:18:44,972 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:20:30,018 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:20:30,499 fail2ban.actions [3574846]: NOTICE [sshd] Ban 43
2024-03-06 09:20:30,620 fail2ban.filter [3574846]: INFO [recidive] Fo
2024-03-06 09:20:30,899 fail2ban.actions [3574846]: NOTICE [recidive] Ba
2024-03-06 09:20:32,021 fail2ban.filter [3574846]: INFO [sshd] Found
2024-03-06 09:30:29,289 fail2ban.actions [3574846]: NOTICE [sshd] Unban
O despejo detalhado da configuração do fail2ban mostra as configurações para exame:
# fail2ban-client -vvv -d
Lista de permissões de endereços IP próprios
Talvez seus próprios hosts sejam banidos ou você queira garantir que alguns hosts estrangeiros nunca sejam banidos, mesmo que se comportem mal. Esses números IP podem ser colocados na lista de permissões. Por padrão, nada está na lista de permissões, você pode verificar isso com:
root@posti:~# fail2ban-client get sshd ignoreip
No IP address/network is ignored
root@posti:~
A configuração ignoreip pode ser definida em cada seção de jails, mas esta configuração deve afetar todas as jails, portanto é melhor defini-la na seção DEFAULT. Talvez seja melhor definir ignore para a sub-rede interna, para que todos os seus hosts evitem banimentos. Isto é do início de jail.local:
[DEFAULT]
ignoreip = 92.237.123.96/27
A seção padrão pode ter outras configurações que afetam todas as prisões. Por exemplo, findtime=10h poderia ser adicionado lá.
Banir manualmente
Para testar o que acontece ao banir, defina o banimento manualmente. Teste primeiro com uma prisão com banimento curto, para que você volte eventualmente se se banir por engano. Por exemplo
# fail2ban-client set sshd banip 8.8.4.4</>
Se algum IP se comporta mal, mas você não consegue fazer com que o fail2ban o detecte e emita banimentos, definir o banimento manual na prisão recidiva elimina esse IP por uma semana.
# fail2ban-client set recidive banip 8.8.4.4
Banir uma sub-rede funciona usando a notação CIDR:
fail2ban-client set recidive banip 5.188.87.0/24
Desbanindo manualmente
Remover um banimento é possível, mas considere que se o mau comportamento continuar, o IP será banido novamente. Portanto, você deve descobrir o que está acontecendo (lendo os logs, por exemplo) e corrigir o mau comportamento.
# fail2ban-client set recidive unbanip 8.8.4.4
O IP pode ser banido em diversas prisões. Para desbanir um IP em todas as prisões, use
# fail2ban-client unban 8.8.4.4
Raramente preciso fazer isso, no entanto. Tenho 10 minutos de banimento, só que a prisão reincidente tem 1 semana, então só desbanio da prisão reincidente, outras prisões já expiraram. Se você não usar a prisão reincidente, o IP poderá ser banido em várias prisões ao mesmo tempo, então isso é útil.
Para desbanir todos os endereços IP de todas as prisões, faça
fail2ban-client unban --all
Conclusão
O Fail2ban torna mais difícil adivinhar as senhas, mas não impede completamente que os crackers tentem acessar o host. Para SSH, forçar o uso de chaves SSH oferece mais proteção ao impedir o login com senha. Para outros serviços, a autenticação multifator impede o login se apenas a senha for conhecida.