SSH é um método comum e seguro de se conectar a um servidor em nuvem ou remoto. No entanto, nenhum protocolo ou software é totalmente infalível, e o SSH sendo tão amplamente usado na Internet significa que ele representa um alvo de ataque muito previsível por meio do qual as pessoas podem tentar obter acesso. Sim, qualquer serviço exposto à rede é um alvo em potencial.
Em locais e empresas onde ter uma possibilidade de ataque é completamente inaceitável, geralmente implementam uma VPN como WireGuard na frente de seu serviço SSH, de modo que é impossível conectar-se diretamente à porta SSH padrão 22 da Internet externa sem abstração de software adicional ou entradas. Essas soluções VPN são amplamente confiáveis, mas adicionam complexidade e podem quebrar algumas automações ou outros pequenos acessos de software.
Veja: O que É Ataque de Força Bruta em Informática?
Mas você pode implementar uma ferramenta chamada Fail2ban. O Fail2ban pode mitigar significativamente os ataques por 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 sua intervenção.
Veja: Em Quanto Tempo uma Ferramenta de Ataque por Força Bruta Poderia Descobrir uma Senha?
Instalando o Fail2ban
EM RED HAT, CENTOS, ROCKY LINUX E DERIVADOS
dnf update -y
dnf install fail2ban
DEBIAN, UBUNTU E DERIVADOS
apt update -y
apt install fail2ban
Fail2ban estará desativado por padrão, porque algumas de suas configurações padrão podem causar efeitos indesejados.
Você pode habilitar o Fail2ban imediatamente, mas primeiro, você revisará alguns de seus recursos.
Criando Nosso Arquivo de Configuração para o Fail2ban
Configurando o Fail2ban
O serviço fail2ban mantém seus arquivos de configuração no diretório /etc/fail2ban. Existe um arquivo com padrões chamado jail.conf. Não mexa no arquivo jail.conf! Se fizer alguma alteração ela será apagada em atualizações. Em vez disso, você tem duas opções: criar perfis individuais para 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.
Vou optar por criar o arquivo jail.local. Você pode fazer isso copiando jail.conf. Podemos copiar o arquivo jail.conf para criar o jail.local
#1 Acesse a pasta /etc/fail2ban/
cd /etc/fail2ban/
#2 copie jail.conf para jail.local
cp jail.conf jail.local
Pronto, temos um novo arquivo criado com configurações aproveitadas de do arquivo jail.conf 🙂
#3 Acesse o arquivo /etc/fail2ban/jail.local usando seu editor de texto preferido. Pode ser o editor nano, vim, vi…
sudo nano jail.local
Configurando jail.local Fail2ban
Atenção: acrescente “enabled = true” somente no serviço que queira ativar. Se ativar um serviço que não exista será gerado erro.
As opções feitas em jail.local sobrescreverão as padrões que estão em jail.conf.
As configurações localizadas na seção [DEFAULT] próximo ao topo do arquivo serão aplicadas a todos os serviços suportados pelo Fail2ban.
Existem seções para [sshd] e para outros serviços, que contêm configurações específicas do serviço que serão aplicadas.
Vamos alterar algumas opções de dentro de jail.local
#1 O parâmetro bantime define o período de tempo que um cliente será banido quando falhar na autenticação correta. Isso é medido em segundos. Por padrão, isso é definido como 10 minutos.
Altere bantime para 20 minutos ou outro tempo que desejar
[DEFAULT] . . . bantime = 20m . . .
#2 Os próximos dois 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 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 em uma janela de 10 minutos.
[DEFAULT] . . . findtime = 10m maxretry = 5 . . .
#3 Se você precisar receber alertas de e-mail quando o Fail2ban entrar em ação, você deve ajustar os parâmetros destemail, sendername e mta.
- destemail define o endereço de e-mail que deve receber mensagens de banimento.
- sendername define o valor do campo “De” no e-mail.
- mta configura qual serviço de e-mail será usado para enviar e-mail. Por padrão, este é o sendmail, mas você pode querer usar o Postfix ou outra solução de correio.
[DEFAULT] . . . destemail = root@localhost sender = root@<fq-hostname> mta = sendmail . . .
#4 O parâmetro action configura a ação que o Fail2ban executa quando deseja instituir um banimento. O valor action_ é definido no arquivo logo antes deste parâmetro. A ação padrão é atualizar a configuração do firewall para rejeitar o tráfego do host ofensivo até que o tempo de banimento termine.
[DEFAULT] . . . action = $(action_)s . . .
Existem outros scripts action_ fornecidos por padrão que você pode substituir $(action_) acima.
Por exemplo, action_mw executa uma ação e envia um e-mail, action_mwl executa uma ação, envia um e-mail e inclui log, e action_cf_mwl faz todas as ações acima, além de enviar uma atualização para a API Cloudflare associada à sua conta para banir o infrator lá, também.
Veja exemplo:
# ban & send an e-mail with whois report to the destemail.
action_mw = %(action_)s
%(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(action_)s
%(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
# See the IMPORTANT note in action.d/xarf-login-attack for when to use this action
#
# ban & send a xarf e-mail to abuse contact of IP address and include relevant log lines
# to the destemail.
action_xarf = %(action_)s
xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]
# ban IP on CloudFlare & send an e-mail with whois report and relevant log lines
# to the 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"]
…
Configurações Individuais do jail
Há um “enabled = true” dentro da seção [DEFAULT]. Não ative ele! A não ser que queira ativar todos os serviços. [DEFAULT] é global, toda linha nessa seção aplica-se a tudo!
Acima vimos somente a parâmetros para a seção [DEFAULT]. Agora podemos ir para outras como a [sshd] ou [jail_to_enable]
Cada uma dessas seções precisa ser habilitada individualmente adicionando uma linha enabled = true abaixo do cabeçalho, 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 com falha e o logpath que informa ao fail2ban onde os logs para esse 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 com falha. Não abordaremos esses arquivos em profundidade 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 examinando esse diretório: /etc/fail2ban/filter.d
Se você vir um arquivo que parece relacionado a um serviço que está usando, abra-o com um editor de texto. A maioria dos arquivos é razoavelmente bem comentada e você deve ser capaz de pelo menos dizer que tipo de condição o script foi projetado para evitar. A maioria desses filtros possui seções apropriadas(desativadas) no arquivo jail.conf que podemos ativar no arquivo jail.local, se desejado.
Por exemplo, imagine que você usa e administra um site usando 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 no arquivo /var/log/nginx/error.log.
Na verdade, isso já está configurado em uma seção chamada [nginx-http-auth] em seu arquivo /etc/fail2ban/jail.conf. Você só precisaria adicionar o parâmetro habilitado:
. . . [nginx-http-auth] enabled = true . . .
Iniciando o fail2ban
Quando terminar de editar, salve e feche o arquivo. Neste ponto, você pode ativar seu serviço Fail2ban para que ele seja executado automaticamente a partir de agora. Primeiro, execute systemctl enable:
Habilite o início automático do fail2ban ao ligarmos o pc
sudo systemctl enable fail2ban
inicie manualmente pela primeira vez com systemctl start:
sudo systemctl start fail2ban
Veja o status, se está realmente iniciado
sudo systemctl status fail2ban
Testando as Políticas de Banimento
Vamos chamar nosso servidor onde está o fail2ban instalado de Fail2ban 🙂
De outro servidor, um que não precisará fazer login no seu servidor Fail2ban no futuro, você pode testar as regras fazendo com que o segundo servidor seja banido. Depois de fazer login em seu segundo servidor, tente conectar com SSH no servidor Fail2ban. Você pode tentar se conectar usando um nome inexistente apenas para gerar o banimento propositadamente.
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(Permission denied) para Conexão Recusada(Connection refused). 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 iptables. iptables é um comando para interagir com portas de baixo nível e regras de firewall em seu servidor. você poderá estar usando o ufw ou firewalld para gerenciar regras de firewall em um nível superior. A execução de iptables -S mostrará todas as regras de firewall que já criou:
Executando iptables -S verá algo como:
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ê filtrar a saída de iptables -S usando grep para pesquisar dentro dessas regras pela string f2b, poderá ver as regras que foram adicionadas por fail2ban:
sudo iptables -S | grep f2b