Como proteger o SSH com o Fail2Ban no Debian 11

Introdução

O SSH é o método de facto para conectar a 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 principal 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 ou vetor de ataque através do qual as pessoas podem tentar obter acesso.

Qualquer serviço exposto à rede é um alvo potencial dessa forma. Se você revisar os registros do seu serviço SSH em qualquer servidor com muito tráfego, frequentemente verá tentativas repetidas e sistemáticas de login que representam ataques de força bruta tanto por usuários quanto por bots. Embora você possa fazer algumas otimizações em seu serviço SSH para reduzir a chance de esses ataques terem sucesso quase zero, como desativar a autenticação por senha em favor de 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 da internet externa sem abstração de software adicional ou gateways. Essas soluções de VPN são amplamente confiáveis, mas adicionam complexidade e podem quebrar algumas automações ou outros ganchos de software pequenos.

Antes de ou além de se comprometer com uma configuração completa de VPN, você pode implementar uma ferramenta chamada Fail2ban. O Fail2ban pode mitigar significativamente os 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 malsucedidas. 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á de:

• 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 você usará para testar sendo banido deliberadamente.

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 ser instalado. 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 características.

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
# customize as configurações para a 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 em 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.
#
# Fornecer personalizações em um arquivo jail.local ou jail.d/customisation.local.
# Por exemplo, para alterar o bantime padrão para todos os jails e para ativar o
# jail ssh-iptables, o seguinte (descomentado) apareceria no arquivo .local.
# Veja 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 e não 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 na 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 na 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 serão aplicadas sobre as predefinições.

[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 é definido para 10 minutos.

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

Os próximos dois parâmetros são findtime e maxretry. Eles trabalham juntos para estabelecer as condições nas 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 dentro de uma janela de tempo definida 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 você precisar receber alertas por email quando o Fail2ban tomar medidas, você deve avaliar as configurações destemail, sendername e mta. O parâmetro destemail define o endereço de email que deve receber as mensagens de proibição. O sendername define o valor do campo “De” no email. O parâmetro mta configura qual serviço de correio será usado para enviar o email. Por padrão, isso é 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 uma proibição. 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 proibição expire.

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

…
# proibir e enviar um email 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"]

# proibir e enviar um email 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
#
# proibir e enviar um email 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"]

# proibir IP no CloudFlare e enviar um email 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 realiza uma ação e envia um email, action_mwl realiza uma ação, envia um email e inclui o registro, e action_cf_mwl faz tudo isso além de enviar uma atualização para a API do Cloudflare associada à sua conta para banir o infrator lá também.

Configurações Individuais de Prisão

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

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

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

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

O valor do filter na verdade é uma referência a um arquivo localizado no diretório /etc/fail2ban/filter.d, com a extensão .conf removida. Esses arquivos contêm expressões regulares (uma forma comum de análise de texto) que determinam se uma linha no registro é uma tentativa de autenticação falhada. Não vamos cobrir esses arquivos em detalhes neste guia, pois 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ê ver um arquivo que parece relacionado a um serviço que você está usando, você deve abri-lo com um editor de texto. A maioria dos arquivos está bem comentada e você deverá ser capaz de pelo menos saber que tipo de condição o script foi projetado para proteger contra. A maioria desses filtros possui seções apropriadas (desativadas) no arquivo jail.conf que podemos habilitar 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 bombardeada 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, pode reiniciar o serviço Fail2ban usando systemctl:

sudo systemctl restart fail2ban

Na próxima etapa, 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 obtendo esse segundo servidor banido. Após fazer login no seu segundo servidor, tente fazer SSH no servidor Fail2ban. Você pode tentar 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 indica 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 de baixo nível no seu servidor. Se você seguiu o guia da DigitalOcean para a configuração inicial do servidor, estará usando ufw para gerenciar regras de firewall em um nível mais alto. Executar iptables -S 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ê direcionar a saída do iptables -S para o grep para procurar dentro dessas regras pela 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 será adicionada pelo Fail2ban e deve refletir o endereço IP do seu segundo servidor.

Conclusão

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

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