Como proteger o SSH com Fail2Ban no Debian 11

Introdução

O SSH é o método padrão de conexão com um servidor na nuvem. É durável e extensível – à medida que novos padrões de criptografia são desenvolvidos, eles podem ser usados para gerar novas chaves SSH, garantindo que o protocolo central permaneça seguro. No entanto, nenhum protocolo ou pilha de software é totalmente infalível, e o fato de o SSH ser tão amplamente implantado pela Internet significa que ele representa uma superfície de ataque muito previsível, através da qual as pessoas podem tentar obter acesso.

Qualquer serviço exposto à rede é um alvo em potencial dessa maneira. Se você revisar os logs do seu serviço SSH em um servidor de alto tráfego, frequentemente verá tentativas de login sistemáticas e repetidas que representam ataques de força bruta por parte de usuários e bots. Embora você possa fazer algumas otimizações no seu serviço SSH para reduzir a chance de esses ataques terem sucesso para próximo de zero, como desabilitar a autenticação por senha em favor das chaves SSH, eles ainda podem representar uma pequena responsabilidade contínua.

Implantações de produção em larga escala para as quais essa responsabilidade é completamente inaceitável geralmente implementarão uma VPN como o WireGuard na frente de seu serviço SSH, para que seja impossível se conectar diretamente à porta SSH padrão 22 a partir da internet externa sem software de abstração adicional ou gateways. Essas soluções de VPN são amplamente confiáveis, mas adicionam complexidade e podem quebrar algumas automações ou outros pequenos ganchos de software.

Antes de ou além de se comprometer com uma configuração de VPN completa, você pode implementar uma ferramenta chamada Fail2ban. O Fail2ban pode mitigar significativamente ataques de força bruta criando regras que alteram automaticamente a configuração do seu firewall para banir IPs específicos após um certo número de tentativas de login sem sucesso. Isso permitirá que seu servidor se proteja contra essas tentativas de acesso sem intervenção sua.

Neste guia, você verá como instalar e usar o Fail2ban em um servidor Debian 11.

Pré-requisitos

Para concluir este guia, você precisará:

• Um servidor Debian 11 e um usuário não-root com privilégios sudo. Você pode aprender mais sobre como configurar um usuário com esses privilégios em nosso guia Configuração Inicial do Servidor com Debian 11.

• Opcionalmente, um segundo servidor ao qual você pode se conectar a partir do seu primeiro servidor, que será usado para testar o banimento deliberado.

Passo 1 — Instalando o Fail2ban

O Fail2ban está disponível nos repositórios de software do Debian. Comece executando os seguintes comandos como um usuário não root para atualizar suas listagens de pacotes e instalar o Fail2ban:

sudo apt update
sudo apt install fail2ban

O Fail2ban configurará automaticamente um serviço em segundo plano após a instalação. Você pode verificar seu status usando o comando systemctl:

systemctl status fail2ban.service

Output
● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled
     Active: active (running) since Tue 2022-06-28 16:23:14 UTC; 17s ago
       Docs: man:fail2ban(1)
    Process: 1942 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS
   Main PID: 1943 (fail2ban-server)
      Tasks: 5 (limit: 1132)
     Memory: 15.8M
        CPU: 280ms
     CGroup: /system.slice/fail2ban.service
             └─1943 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Você pode continuar usando o Fail2ban com suas configurações padrão, mas primeiro você revisará algumas de suas funcionalidades.

Passo 2 – Configurando o Fail2ban

O serviço fail2ban mantém seus arquivos de configuração no diretório /etc/fail2ban. Há um arquivo com as configurações padrão chamado jail.conf. Vá para esse diretório e imprima as primeiras 20 linhas desse arquivo usando head -20:

cd /etc/fail2ban
head -20 jail.conf

Output
#
# AVISO: fortemente refatorado na versão 0.9.0. Por favor, revise e
# personalize as configurações para sua configuração.
#
# Mudanças: na maioria dos casos, você não deve modificar este
# arquivo, mas fornecer personalizações no arquivo jail.local,
# ou arquivos .conf separados no diretório jail.d/, por exemplo:
#
# COMO ATIVAR JAILS:
#
# VOCÊ NÃO DEVE MODIFICAR ESTE ARQUIVO.
#
# Provavelmente será sobrescrito ou melhorado em uma atualização de distribuição.
#
# Forneça personalizações em um arquivo jail.local ou em um jail.d/customizacao.local.
# Por exemplo, para alterar o bantime padrão para todos os jails e para habilitar o
# jail ssh-iptables, o seguinte (descomentado) apareceria no arquivo .local.
# Consulte o manual 5 jail.conf para detalhes.
#
# [DEFAULT]

Conforme você verá, as primeiras várias linhas deste arquivo estão comentadas – elas começam com caracteres # indicando que devem ser lidas como documentação em vez de como configurações. Como você também verá, esses comentários estão direcionando você a não modificar este arquivo diretamente. Em vez disso, você tem duas opções: criar perfis individuais para o Fail2ban em vários arquivos dentro do diretório jail.d/, ou criar e coletar todas as suas configurações locais em um arquivo jail.local. O arquivo jail.conf será periodicamente atualizado conforme o próprio Fail2ban é atualizado, e será usado como fonte de configurações padrão para as quais você não criou substituições.

Neste tutorial, você criará jail.local. Você pode fazer isso copiando jail.conf:

sudo cp jail.conf jail.local

Agora você pode começar a fazer alterações de configuração. Abra o arquivo no nano ou no seu editor de texto favorito:

sudo nano jail.local

Enquanto você estiver navegando pelo arquivo, este tutorial revisará algumas opções que você pode querer atualizar. As configurações localizadas sob a seção [DEFAULT] perto do topo do arquivo serão aplicadas a todos os serviços suportados pelo Fail2ban. Em outras partes do arquivo, existem cabeçalhos para [sshd] e para outros serviços, que contêm configurações específicas do serviço que se aplicarão sobre as configurações padrão.

[DEFAULT]
. . .
bantime = 10m
. . .

O parâmetro bantime define o período de tempo durante o qual um cliente será banido quando falhar na autenticação correta. Isso é medido em segundos. Por padrão, isso está definido para 10 minutos.

[DEFAULT]
. . .
findtime = 10m
maxretry = 5
. . .

Os dois próximos parâmetros são findtime e maxretry. Eles trabalham juntos para estabelecer as condições sob as quais um cliente é considerado um usuário ilegítimo que deve ser banido.

A variável maxretry define o número de tentativas que um cliente tem para autenticar-se dentro de um intervalo de tempo definido por findtime, antes de ser banido. Com as configurações padrão, o serviço fail2ban banirá um cliente que tentar fazer login sem sucesso 5 vezes dentro de uma janela de 10 minutos.

[DEFAULT]
. . .
destemail = root@localhost
sender = root@<fq-hostname>
mta = sendmail
. . .

Se precisar receber alertas por e-mail quando o Fail2ban tomar medidas, você deve avaliar as configurações destemail, sendername e mta. O parâmetro destemail define o endereço de e-mail que deve receber as mensagens de banimento. O sendername define o valor do campo “De” no e-mail. O parâmetro mta configura qual serviço de correio será usado para enviar o e-mail. Por padrão, este é o sendmail, mas você pode querer usar o Postfix ou outra solução de correio.

[DEFAULT]
. . .
action = $(action_)s
. . .

Este parâmetro configura a ação que o Fail2ban toma quando deseja instituir um banimento. O valor action_ é definido no arquivo pouco antes deste parâmetro. A ação padrão é atualizar a configuração do seu firewall para rejeitar o tráfego do host infrator até que o tempo de banimento expire.

Há outros scripts de action_ fornecidos por padrão que você pode substituir $(action_) acima por:

…
# banir & enviar um e-mail com relatório whois para o destemail.
action_mw = %(action_)s
            %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]

# banir & enviar um e-mail com relatório whois e linhas de log relevantes
# para o destemail.
action_mwl = %(action_)s
             %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]

# Veja a nota IMPORTANTE em action.d/xarf-login-attack para quando usar esta ação
#
# banir & enviar um e-mail xarf para o contato de abuso do endereço IP e incluir linhas de log relevantes
# para o destemail.
action_xarf = %(action_)s
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]

# banir IP no CloudFlare & enviar um e-mail com relatório whois e linhas de log relevantes
# para o destemail.
action_cf_mwl = cloudflare[cfuser="%(cfemail)s", cftoken="%(cfapikey)s"]
                %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
…

Por exemplo, action_mw executa a ação e envia um e-mail, action_mwl executa a ação, envia um e-mail e inclui o registro, e action_cf_mwl faz tudo isso além de enviar uma atualização para a API da Cloudflare associada à sua conta para banir o infrator lá também.

Configurações Individuais da Prisão

Em seguida, está a parte do arquivo de configuração que trata dos serviços individuais. Estes são especificados por cabeçalhos de seção, como [sshd].

Cada uma dessas seções precisa ser ativada individualmente adicionando uma linha enabled = true sob o cabeçalho, juntamente com suas outras configurações.

[jail_to_enable]
. . .
enabled = true
. . .

Por padrão, o serviço SSH está ativado e todos os outros estão desativados.
.
Algumas outras configurações definidas aqui são o filter que será usado para decidir se uma linha em um log indica uma autenticação falha e o logpath que informa ao fail2ban onde os logs para aquele serviço específico estão localizados.

O valor do filter é na verdade uma referência a um arquivo localizado no diretório /etc/fail2ban/filter.d, com sua extensão .conf removida. Esses arquivos contêm expressões regulares (um atalho comum para análise de texto) que determinam se uma linha no log é uma tentativa de autenticação falhada. Não vamos cobrir esses arquivos detalhadamente neste guia, porque eles são bastante complexos e as configurações predefinidas correspondem bem às linhas apropriadas.

No entanto, você pode ver que tipo de filtros estão disponíveis olhando para esse diretório:

ls /etc/fail2ban/filter.d

Se você encontrar um arquivo que pareça relacionado a um serviço que está usando, você deve abri-lo com um editor de texto. A maioria dos arquivos está bastante comentada e você deverá conseguir pelo menos identificar o tipo de condição para a qual o script foi projetado para proteger. A maioria desses filtros tem seções apropriadas (desativadas) no arquivo jail.conf que podemos ativar no arquivo jail.local se desejado.

Por exemplo, imagine que você está servindo um site usando o Nginx e percebe que uma parte protegida por senha do seu site está sendo atacada com tentativas de login. Você pode dizer ao fail2ban para usar o arquivo nginx-http-auth.conf para verificar essa condição dentro do arquivo /var/log/nginx/error.log.

Isso já está configurado em uma seção chamada [nginx-http-auth] no seu arquivo /etc/fail2ban/jail.conf. Você só precisaria adicionar o parâmetro enabled:

. . .
[nginx-http-auth]

enabled = true
. . .

Quando terminar de editar, salve e feche o arquivo. Se você fez alguma alteração, você pode reiniciar o serviço Fail2ban usando systemctl:

sudo systemctl restart fail2ban

No próximo passo, você demonstrará o Fail2ban em ação.

Passo 3 — Testando as Políticas de Bloqueio (Opcional)

De outro servidor, um que não precisará fazer login no seu servidor Fail2ban no futuro, você pode testar as regras fazendo com que esse segundo servidor seja banido. Após fazer login no seu segundo servidor, tente fazer SSH para o servidor Fail2ban. Você pode tentar se conectar usando um nome inexistente:

ssh blah@your_server

Insira caracteres aleatórios no prompt de senha. Repita isso algumas vezes. Em algum momento, o erro que você está recebendo deve mudar de Permissão negada para Conexão recusada. Isso sinaliza que seu segundo servidor foi banido do servidor Fail2ban.

No seu servidor Fail2ban, você pode ver a nova regra verificando a saída do seu iptables. iptables é um comando para interagir com regras de porta e firewall em um nível mais baixo no seu servidor. Se você seguiu o guia de configuração inicial do servidor da DigitalOcean, você estará usando o ufw para gerenciar regras de firewall em um nível mais alto. Executar iptables -S irá mostrar todas as regras de firewall que o ufw já criou:

sudo iptables -S

Output
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N f2b-sshd
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
…

Se você redirecionar a saída do comando iptables -S para o grep para procurar dentro dessas regras a string f2b, você pode ver as regras que foram adicionadas pelo fail2ban:

sudo iptables -S | grep f2b

Output
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 134.209.165.184/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN

A linha contendo REJECT --reject-with icmp-port-unreachable terá sido adicionada pelo Fail2ban e deve refletir o endereço IP do seu segundo servidor.

Conclusão

Agora você deverá ser capaz de configurar algumas políticas de banimento para seus serviços. O Fail2ban é uma maneira útil de proteger qualquer tipo de serviço que utilize autenticação. Se você quiser aprender mais sobre como o fail2ban funciona, pode conferir nosso tutorial sobre como as regras e arquivos do fail2ban funcionam.

Para obter informações sobre como usar o fail2ban para proteger outros serviços, você pode ler sobre Como Proteger um Servidor Nginx com Fail2Ban e Como Proteger um Servidor Apache com Fail2Ban.