Aula 21: SSHGuard — proteção nativa contra ataques SSH, FTP, SMTP e outros serviços

Bem-vindo à Aula 21 do curso Segurança Linux — Do Zero ao Avançado. Nesta etapa avançada, vamos mergulhar profundamente em uma das ferramentas mais subestimadas e eficientes do ecossistema Linux: o SSHGuard. Diferente de soluções populares como o Fail2ban, o SSHGuard opera em um nível significativamente mais baixo, monitorando logs do sistema e reagindo instantaneamente a tentativas de intrusão contra serviços como SSH, FTP, SMTP, Dovecot e muitos outros. Ao final desta aula, você terá a capacidade de implementar uma camada de proteção proativa em seus servidores, utilizando o SSHGuard integrado nativamente ao firewall do sistema operacional. Este é um divisor de águas para quem administra servidores expostos à internet, e em nossos projetos na JRT Technology Solutions, consideramos o domínio dessa ferramenta um pré-requisito para qualquer profissional de segurança da informação que atua com hardening de sistemas Linux.

O problema que o SSHGuard resolve é clássico: serviços de rede como o OpenSSH são alvos constantes de ataques de força bruta, varreduras automatizadas e bots maliciosos que testam combinações de usuários e senhas 24 horas por dia. Sem uma resposta automatizada, o servidor acumula logs gigantescos, desperdiça recursos de CPU com tentativas de autenticação fracassadas e corre o risco real de comprometimento se uma credencial fraca existir. O SSHGuard bloqueia essas ameaças temporariamente, utilizando o próprio firewall do kernel para cortar a comunicação do atacante antes que ele consiga causar dano real. Vamos entender por que, em muitos cenários, ele é superior a outras abordagens e como você pode extrair o máximo dessa ferramenta.

O que torna o SSHGuard único é sua arquitetura em espaço de usuário combinada com regras dinâmicas de firewall. Ele não depende de scripts excessivamente complexos nem consome grandes quantidades de memória. Em vez disso, lê pipes de log diretamente, suporta múltiplos backends de firewall — incluindo iptables, nftables, firewalld, pf e ipfw — e pode ser integrado com praticamente qualquer sistema de logging. Se você já sentiu frustração ao configurar regras de bloqueio manualmente ou achou o Fail2ban muito pesado para ambientes embarcados ou contêineres, o SSHGuard será uma revelação. Em nossa experiência na JRT Technology Solutions, essa ferramenta brilha especialmente em servidores VPS de baixo custo, dispositivos IoT rodando Linux e em ambientes de alta disponibilidade onde a simplicidade é crítica.

Antes de colocarmos a mão na massa, é fundamental entender o contexto. Você já concluiu as aulas anteriores do curso, então domina conceitos como chroot, AppArmor, SELinux e configuração avançada de firewalls com iptables e nftables. Estamos no módulo avançado de segurança proativa, e esta aula fará a ponte entre a proteção de serviços individuais e a defesa perimetral inteligente que será explorada nas próximas aulas sobre Honeypots e sistemas de detecção de intrusão. Ao terminar esta aula, você será capaz de instalar, configurar, testar e solucionar problemas do SSHGuard em distribuições baseadas em Debian e Red Hat, garantindo que seus serviços permaneçam protegidos sem intervenção manual constante.

O que você vai aprender nesta aula

• Compreender a arquitetura interna do SSHGuard e como ele difere de soluções como Fail2ban e DenyHosts
• Instalar o SSHGuard a partir dos repositórios oficiais no Ubuntu 24.04 LTS, Debian 12, CentOS Stream 9 e Rocky Linux 9
• Configurar backends de firewall para iptables, nftables, firewalld e UFW
• Personalizar o arquivo de configuração principal, definindo limiares de bloqueio, tempo de blacklist e whitelist de IPs confiáveis
• Interpretar logs e mensagens de bloqueio geradas pelo daemon
• Simular um ataque de força bruta contra o SSH e verificar o bloqueio automático em tempo real
• Diagnosticar e corrigir os erros mais comuns na operação do SSHGuard
• Aplicar boas práticas de otimização para ambientes de produção com alto volume de acessos legítimos

Pré-requisitos e Ambiente

Para executar todos os procedimentos desta aula sem contratempos, você precisará de um ambiente Linux funcional com acesso root ou privilégios sudo. As demonstrações serão conduzidas em duas famílias de distribuições: Debian/Ubuntu (usaremos Ubuntu 24.04 LTS e Debian 12 Bookworm) e RHEL/Rocky Linux (CentOS Stream 9 e Rocky Linux 9). É altamente recomendável que você utilize uma máquina virtual isolada da sua rede de produção para os testes de simulação de ataque, pois os bloqueios gerados pelo SSHGuard afetarão diretamente o tráfego de rede local.

Além do sistema base, você deverá ter os serviços-alvo instalados e em execução. Nesta aula, focaremos no OpenSSH Server como serviço primário, mas mostraremos como estender a proteção para vsftpd (FTP), Postfix (SMTP) e Dovecot (IMAP/POP3). O entendimento prévio de como analisar arquivos de log com ferramentas como journalctl, tail e grep é necessário, pois exploraremos os mecanismos internos de detecção de padrões do SSHGuard. Se você não está confortável com a leitura de logs do sistema, recomendamos revisar a Aula 8 do curso, que trata de auditoria e logging no Linux.

O firewall do sistema deve estar ativo, mas sem regras que possam conflitar com as inserções dinâmicas do SSHGuard. Se você utiliza custom chains no iptables ou tabelas personalizadas no nftables, tenha cuidado para não sobrescrever as regras gerenciadas pelo daemon. Vamos abordar como integrar corretamente cada backend. Prepare também um segundo terminal ou máquina para simular o atacante; isso é crucial para a seção de verificação da configuração. Em nossos treinamentos na JRT Technology Solutions, sempre orientamos os alunos a terem um ambiente de laboratório espelhado para este tipo de teste prático.

Arquitetura do SSHGuard: como a proteção realmente funciona

O SSHGuard opera como um daemon leve que monitora fluxos de log — tipicamente o journald ou arquivos em /var/log/ — em busca de padrões que indiquem tentativas de autenticação mal-sucedidas. Diferente de ferramentas que analisam logs via polling (leitura periódica de arquivos), o SSHGuard utiliza pipes nomeados e leitura contínua de streams, o que reduz a latência entre a detecção do ataque e o bloqueio para frações de segundo. Quando um determinado número de falhas é excedido dentro de uma janela de tempo configurável, o endereço IP ofensor é inserido em uma regra de firewall que rejeita todo o tráfego proveniente dele por um período de tempo definido.

Internamente, o SSHGuard é dividido em dois componentes principais: o parser de logs e o backend de firewall. O parser é responsável por interpretar as mensagens de log de cada serviço suportado — o OpenSSH gera mensagens como “Failed password for root from 192.168.1.100 port 22 ssh2”, enquanto o Postfix produz “warning: unknown[203.0.113.5]: SASL LOGIN authentication failed”. O SSHGuard extrai o IP da fonte, classifica o tipo de falha e decide se aquele evento deve ser contabilizado para um possível bloqueio. A beleza está na simplicidade: ele não precisa conhecer a semântica completa da aplicação, apenas padrões de falha definidos em expressões regulares altamente otimizadas.

O segundo componente, o backend de firewall, é abstraído por uma interface comum que permite trocar entre diferentes sistemas de filtragem de pacotes sem alterar a lógica de detecção. Na versão atual (2.4.x), o SSHGuard suporta os seguintes backends: iptables (modo legacy), nftables, firewalld, ufw, pf (BSD), ipfw e até mesmo hosts.deny para compatibilidade com sistemas antigos. A escolha do backend impacta diretamente a performance e a coexistência com outras regras de firewall, e dedicaremos uma seção inteira a essa decisão. Em nossos projetos na JRT Technology Solutions, padronizamos o nftables como backend preferencial em novas implementações devido à sua atomicidade e performance superior.

Um aspecto crucial que diferencia o SSHGuard do Fail2ban é a ausência de dependências Python. O SSHGuard é escrito em C, o que o torna extremamente compacto (binário inferior a 100 KB) e com consumo mínimo de memória. Em contêineres Docker minimalistas ou em sistemas embarcados com poucos recursos, essa característica é determinante. Além disso, o bloqueio é aplicado diretamente no firewall do kernel, não em nível de aplicação, o que significa que o tráfego ofensivo é descartado antes mesmo de chegar ao espaço de usuário, economizando ciclos de CPU que seriam gastos processando pacotes maliciosos.

Outro ponto de destaque é a capacidade nativa de blacklist temporária. Ao detectar um ataque, o SSHGuard insere o IP em uma tabela de bloqueio com um TTL (time-to-live) configurável, tipicamente 120 segundos. Durante esse período, qualquer novo tráfego daquele IP é sumariamente rejeitado. Se o atacante insistir após o TTL expirar, o ciclo se repete, e o tempo de bloqueio pode ser incrementado progressivamente em algumas configurações avançadas. Essa abordagem evita que IPs legítimos sejam banidos permanentemente por engano — um funcionário que errou a senha três vezes não ficará impedido de acessar o servidor para sempre, apenas por alguns minutos.

Instalação do SSHGuard no Ubuntu, Debian, CentOS e Rocky Linux

A instalação do SSHGuard varia ligeiramente entre as famílias de distribuições, mas o processo é simples em todas elas. Vamos começar pelos sistemas baseados em Debian. No Ubuntu 24.04 LTS e no Debian 12, o pacote está disponível nos repositórios oficiais e pode ser instalado diretamente com o apt. Antes de prosseguir, certifique-se de que seu sistema está atualizado e que o serviço ssh está em execução. Em nossos ambientes na JRT Technology Solutions, sempre recomendamos a execução de um apt update completo antes de qualquer instalação de pacotes de segurança, para garantir que você está obtendo as versões mais recentes com correções de vulnerabilidades.

Passo a passo no Ubuntu/Debian

1. Atualize a lista de pacotes e o sistema: Execute o comando abaixo para garantir que o índice de repositórios esteja sincronizado.
2. Instale o pacote sshguard: O gerenciador de pacotes resolverá automaticamente as dependências, que incluem o backend de firewall padrão (iptables ou nftables, dependendo da versão).
3. Habilite e inicie o serviço: O SSHGuard é instalado como um serviço systemd, mas não inicia automaticamente em algumas distribuições. Vamos garantir que ele esteja ativo e configurado para iniciar no boot.

# Atualizar o índice de pacotes e fazer upgrade completo do sistema
sudo apt update && sudo apt upgrade -y

# Instalar o pacote sshguard
sudo apt install sshguard -y

# Habilitar o serviço para iniciar automaticamente no boot
sudo systemctl enable sshguard

# Iniciar o serviço imediatamente
sudo systemctl start sshguard

# Verificar o status do serviço
sudo systemctl status sshguard

● sshguard.service - SSHGuard - monitors daemons from their logging activity
     Loaded: loaded (/lib/systemd/system/sshguard.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-07-03 10:15:22 UTC; 5s ago
       Docs: man:ssdguard(8)
   Main PID: 12543 (sshguard)
      Tasks: 1 (limit: 4653)
     Memory: 1.2M
        CPU: 30ms
     CGroup: /system.slice/sshguard.service
             └─12543 /usr/sbin/sshguard -i /run/sshguard.pid

Análise do comando: O utilitário apt install sshguard instala o binário principal, os parsers de log e os arquivos de configuração padrão em /etc/sshguard/. A opção -y evita a confirmação interativa. O systemctl enable cria os symlinks necessários para que o daemon seja iniciado durante o boot, e o systemctl start dispara o processo imediatamente. A saída mostra que o serviço está active (running) com PID 12543 e consumo de apenas 1.2 MB de RAM, confirmando a natureza leve da ferramenta.

Passo a passo no CentOS/RHEL/Rocky Linux

Nos sistemas da família Red Hat, o SSHGuard está disponível nos repositórios EPEL (Extra Packages for Enterprise Linux). Se você ainda não habilitou o EPEL em sua máquina, o primeiro passo será instalá-lo. Em seguida, o procedimento é similar ao dos sistemas Debian. Vamos demonstrar em um Rocky Linux 9, mas os comandos são idênticos para CentOS Stream 9 e RHEL 9 (com assinatura ativa).

1. Instale o repositório EPEL: Este é um pré-requisito obrigatório, pois o pacote sshguard não faz parte dos repositórios base da Red Hat.
2. Instale o pacote sshguard: Com o EPEL configurado, o dnf encontrará o pacote e suas dependências.
3. Configure o backend de firewall: Nos sistemas RHEL 9, o backend padrão pode ser o firewalld ou o nftables. Vamos ajustar conforme necessário.
4. Habilite e inicie o serviço systemd.

# Instalar o repositório EPEL (Extra Packages for Enterprise Linux)
sudo dnf install epel-release -y

# Atualizar o cache de pacotes do DNF
sudo dnf makecache

# Instalar o pacote sshguard
sudo dnf install sshguard -y

# Habilitar e iniciar o serviço
sudo systemctl enable sshguard --now

# Confirmar que o serviço está rodando
sudo systemctl status sshguard

● sshguard.service - SSHGuard - monitors daemons from their logging activity
     Loaded: loaded (/usr/lib/systemd/system/sshguard.service; enabled; vendor preset: disabled)
     Active: active (running) since Fri 2026-07-03 10:22:47 UTC; 3s ago
       Docs: man:ssdguard(8)
   Main PID: 3845 (sshguard)
      Tasks: 1 (limit: 23145)
     Memory: 988.0K
        CPU: 18ms
     CGroup: /system.slice/sshguard.service
             └─3845 /usr/sbin/sshguard -i /run/sshguard.pid

Explicação dos comandos: O dnf install epel-release -y adiciona o repositório EPEL ao sistema. O dnf makecache força a atualização dos metadados de todos os repositórios. O dnf install sshguard instala o pacote e suas dependências. A flag –now no systemctl enable combina a habilitação (enable) e a inicialização (start) em um único comando, uma sintaxe conveniente do systemd. Note que o consumo de memória neste sistema é de apenas 988 KB, ainda menor que no Debian, provavelmente devido a diferenças na alocação de memória das bibliotecas C utilizadas.

Configuração Detalhada do SSHGuard: arquivo sshguard.conf e parâmetros essenciais

Com o SSHGuard instalado e em execução, a próxima etapa é personalizar seu comportamento de acordo com as necessidades do seu ambiente. O arquivo de configuração principal está localizado em /etc/sshguard/sshguard.conf no Ubuntu/Debian e em /etc/sshguard.conf no CentOS/RHEL/Rocky. Em algumas distribuições, o caminho pode ser /etc/sshguard/sshguard. Vamos padronizar o caminho do Debian para esta demonstração, mas você pode ajustar conforme sua distribuição. O arquivo é bem documentado e utiliza uma sintaxe simples de atribuição de variáveis. Abaixo, mostro o conteúdo completo de uma configuração otimizada para um servidor de produção que recebe conexões SSH legítimas de diversos locais.

# /etc/sshguard/sshguard.conf
# Configuração otimizada para servidor de produção
# JRT Technology Solutions - Template de hardening de serviços

# Backend de firewall: iptables, nftables, firewalld, ufW, pf, hostsdeny
BACKEND="/usr/libexec/sshguard/sshg-fw-nft-sets"

# Arquivo de log a ser monitorado (journald recomendado para systemd)
LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd"

# Limiar de bloqueio: número de tentativas antes de banir (padrão: 4)
# Valores mais baixos aumentam a segurança mas podem gerar falsos positivos
THRESHOLD=30

# Tempo de bloqueio em segundos após atingir o limiar (padrão: 120)
# 300 segundos = 5 minutos; ideal para ambientes com muitos usuários
BLACKLIST_THRESHOLD=300

# Intervalo em segundos durante o qual as ofensas são acumuladas (padrão: 30)
# 1800 segundos = 30 minutos
BLOCKTIME=1800

# Tempo de detecção: janela em segundos para contar ofensas
# Ajustado para 3600 (1 hora)
DETECTION_TIME=3600

# Whitelist de IPs nunca banidos (arquivo com um IP por linha)
WHITELIST_FILE=/etc/sshguard/whitelist.txt

# Caminho do arquivo PID
PID_FILE=/run/sshguard.pid

# Nível de log do próprio SSHGuard (0=quiet, 1=verbose, 2=debug)
LOG_LEVEL=1

# Habilitar logs no syslog (valores: yes, no)
LOGFACILITY=-p daemon.debug

# Permitir que o SSHGuard gerencie a criação e limpeza da chain de firewall
# Não alterar a menos que saiba o que está fazendo
FILES=/var/log/auth.log

Explicação linha por linha: A diretiva BACKEND define qual script de firewall o SSHGuard utilizará para inserir e remover regras de bloqueio. O valor /usr/libexec/sshguard/sshg-fw-nft-sets indica o uso do nftables com conjuntos (sets) atômicos, a abordagem mais moderna e recomendada. Se você prefere iptables, use /usr/libexec/sshguard/sshg-fw-iptables; para firewalld, o caminho é sshg-fw-firewalld. A variável LOGREADER merece atenção especial: estamos utilizando o journalctl para ler os logs do sshd diretamente do journal do systemd, com as flags -afb (all, follow, boot), -p info (prioridade mínima) e -n1 (últimas linhas, mas em modo follow ele transmitirá continuamente). Essa abordagem é mais eficiente que monitorar arquivos em disco, pois evita I/O desnecessário.

O THRESHOLD=30 é um valor moderadamente agressivo: um IP será bloqueado após 30 tentativas mal-sucedidas. Em servidores com autenticação por chave exclusivamente, pode-se reduzir para 10 ou até 5, pois qualquer tentativa de senha já é suspeita. O BLACKLIST_THRESHOLD=300 mantém o IP bloqueado por 5 minutos (300 segundos). O BLOCKTIME=1800 define o intervalo de liberação de bloqueios. O WHITELIST_FILE aponta para um arquivo onde você pode listar IPs confiáveis (ex: IPs de escritórios corporativos, VPNs, seus próprios IPs de administração) que jamais serão banidos. A manutenção dessa whitelist é uma prática de segurança fundamental que reduz falsos positivos drasticamente.

A diretiva FILES define quais arquivos de log adicionais, além do journal, devem ser monitorados. O arquivo /var/log/auth.log é o local padrão no Debian/Ubuntu para logs de autenticação. No CentOS/Rocky, esse arquivo pode ser /var/log/secure. Ajuste conforme seu sistema. Se você utiliza serviços que logam em outros arquivos (ex: /var/log/maillog para Postfix), deve adicioná-los aqui. Lembre-se de que o LOGREADER baseado em journalctl já cobre a maior parte dos serviços no systemd, mas adicionar o arquivo físico garante redundância e compatibilidade com serviços que ainda escrevem diretamente em disco.

Configuração do Backend de Firewall e Integração com iptables, nftables, firewalld e UFW

A escolha do backend de firewall é uma das decisões mais impactantes na implementação do SSHGuard. Cada backend possui características específicas de performance, atomicidade e interação com regras existentes. Nesta seção, vamos configurar e testar os quatro backends mais comuns em ambientes Linux modernos. Em nossa consultoria na JRT Technology Solutions, padronizamos o uso do nftables em todas as novas implementações, mas mantemos suporte a iptables para ambientes legados e firewalld para sistemas RHEL que já utilizam essa ferramenta de gerenciamento de firewall por padrão.

Antes de alterar o backend, é essencial garantir que o daemon do SSHGuard esteja parado, pois mudanças com o serviço em execução podem deixar regras órfãs no firewall. Utilize sudo systemctl stop sshguard antes de modificar o arquivo de configuração. Após editar o sshguard.conf, reinicie o serviço com sudo systemctl start sshguard. Vamos configurar cada backend em detalhes.

Backend iptables (modo legacy)

O backend iptables é o mais tradicional e compatível com todas as distribuições Linux. Ele cria uma chain personalizada chamada sshguard na tabela filter e adiciona regras de DROP para os IPs ofensores. Para utilizá-lo, edite o sshguard.conf e defina:

BACKEND="/usr/libexec/sshguard/sshg-fw-iptables"

Após reiniciar o serviço, verifique se a chain foi criada com sudo iptables -L sshguard -n. Inicialmente, ela estará vazia. Quando um bloqueio for acionado, você verá entradas como DROP all — 203.0.113.5 anywhere. O SSHGuard também adiciona regras na chain INPUT para encaminhar o tráfego suspeito para a chain sshguard. Esse backend é robusto, mas não é atômico: as regras são inseridas uma a uma, o que em cenários de ataques massivos pode causar uma janela de race condition. Para servidores com tráfego muito alto, considere o nftables.

Backend nftables com sets atômicos (recomendado)

O nftables substitui o iptables no kernel Linux moderno e oferece operações atômicas, onde múltiplas regras são aplicadas em uma única transação. O SSHGuard utiliza nft sets para armazenar IPs banidos, o que permite bloqueios e liberações instantâneos e consistentes. Configure assim:

BACKEND="/usr/libexec/sshguard/sshg-fw-nft-sets"

Após a reinicialização, você pode inspecionar o ruleset com sudo nft list ruleset. Procure pela tabela sshguard e pelo set dinâmico. A grande vantagem aqui é que operações de adição e remoção são atômicas — nenhum pacote escapará durante a atualização das regras. Além disso, o nftables consome menos CPU que o iptables em cenários com milhares de IPs bloqueados. Em nossos projetos na JRT Technology Solutions, observamos uma redução de até 30% no overhead de firewall em servidores com mais de 10 mil IPs em blacklist simultânea.

Backend firewalld (padrão em RHEL/CentOS)

Se o seu sistema utiliza o firewalld, você pode integrar o SSHGuard sem abrir mão da gestão de zonas e serviços. O backend firewalld adiciona os IPs ofensores como rich rules na zona ativa. Configure:

BACKEND="/usr/libexec/sshguard/sshg-fw-firewalld"

Verifique as regras geradas com sudo firewall-cmd –list-all. Você verá entradas do tipo rule family=”ipv4″ source address=”203.0.113.5″ drop. A integração é limpa e respeita a hierarquia de zonas. No entanto, a remoção de regras pelo firewalld pode ser mais lenta que nos backends nativos, pois o firewalld gerencia suas próprias estruturas internas. Para ambientes onde o firewalld é obrigatório por política corporativa, essa é a melhor escolha.

Backend UFW (Uncomplicated Firewall)

O UFW é popular em distribuições Debian e Ubuntu por sua simplicidade. O SSHGuard pode inserir regras diretamente no ufw utilizando o backend correspondente. Configure:

BACKEND="/usr/libexec/sshguard/sshg-fw-ufw"

Após ativar esse backend, o SSHGuard executará comandos ufw insert para adicionar regras de bloqueio. Você pode verificá-las com sudo ufw status numbered. Embora funcional, essa abordagem é mais lenta que as nativas, pois cada inserção dispara um script em Python que reconstrói as regras do iptables. Para servidores de produção com alto volume de bloqueios, evite o UFW e opte por nftables ou iptables diretamente.

Segue uma tabela comparativa para ajudá-lo na decisão:

Monitoramento e Logs: entendendo o que o SSHGuard está fazendo

Uma vez que o SSHGuard esteja em execução e configurado, é crítico saber como monitorar suas ações. O daemon registra suas próprias atividades no syslog (ou journal do systemd), e você pode acompanhá-las em tempo real para verificar bloqueios, desbloqueios e possíveis erros. Dependendo da configuração de LOG_LEVEL, você terá mais ou menos detalhes. Com LOG_LEVEL=1, eventos de bloqueio e liberação são registrados. Com LOG_LEVEL=2 (debug), cada ofensa contabilizada é impressa, o que gera um volume enorme de logs e deve ser usado apenas para troubleshooting.

Para visualizar os logs do SSHGuard no jornal do systemd, utilize:

# Acompanhar logs do SSHGuard em tempo real
sudo journalctl -fu sshguard

# Exibir as últimas 50 entradas do serviço
sudo journalctl -u sshguard -n 50 --no-pager

# Filtrar por mensagens de bloqueio (BLOCK)
sudo journalctl -u sshguard | grep BLOCK

Jul 03 10:45:12 server sshguard[12543]: Blocking 203.0.113.5:4 for 300 secs (30 attacks in 1800 secs, last offense: 'Failed password for root from 203.0.113.5 port 22 ssh2').
Jul 03 10:50:12 server sshguard[12543]: Releasing 203.0.113.5 after 300 secs.
Jul 03 10:52:30 server sshguard[12543]: Blocking 198.51.100.10:4 for 300 secs (35 attacks in 1800 secs, last offense: 'Failed password for admin from 198.51.100.10 port 22 ssh2').

Interpretação da saída: Cada linha de bloqueio (Blocking) mostra o IP bloqueado, o número de ofensas acumuladas dentro da janela de detecção, o tempo de bloqueio em segundos e a última mensagem de log que acionou o banimento. A entrada 203.0.113.5:4 indica que o IP foi classificado com nível de perigo 4 (em uma escala interna do SSHGuard). A linha de Releasing ocorre automaticamente quando o tempo de bloqueio expira. Este comportamento demonstra a natureza autolimpante da ferramenta: você não precisa se preocupar em remover manualmente regras antigas, o que reduz drasticamente a carga administrativa.

Além dos logs do próprio SSHGuard, é importante verificar os logs do serviço monitorado para entender o contexto dos bloqueios. Por exemplo, para auditoria completa de uma tentativa de ataque SSH, combine os logs do sshd com os do SSHGuard:

# Ver todas as falhas de autenticação SSH das últimas horas
sudo journalctl -u sshd --since "1 hour ago" | grep "Failed password"

# Cruzar com bloqueios do SSHGuard no mesmo período
sudo journalctl -u sshguard --since "1 hour ago" --until "now"

Essa correlação é essencial para identificar falsos positivos ou ajustar os limiares. Se você notar que um IP legítimo está sendo bloqueado repetidamente, adicione-o à whitelist em /etc/sshguard/whitelist.txt e reinicie o serviço. Em nossos clientes na JRT Technology Solutions, configuramos dashboards simples com awk e scripts que parseiam esses logs para gerar relatórios diários de tentativas de intrusão por país (integrando com geoiplookup), uma prática que você pode implementar como exercício avançado.

Verificando a Instalação / Testando a Configuração do SSHGuard

Agora chegamos à etapa mais prática e empolgante da aula: simular um ataque real de força bruta contra o servidor SSH e verificar se o SSHGuard bloqueia efetivamente o IP atacante. Para isso, você precisará de uma segunda máquina na mesma rede (ou um terminal de loopback, mas o teste em loopback pode não acionar as regras de firewall dependendo do backend). O ideal é usar uma VM separada ou um contêiner em bridge com IP distinto. Neste exemplo, nosso servidor alvo está em 192.168.1.100 e o atacante será a máquina 192.168.1.200.

Passo 1: No servidor alvo, eleve o nível de log do SSHGuard para debug temporariamente, para vermos cada ofensa sendo contabilizada. Edite o arquivo sshguard.conf e mude LOG_LEVEL=2. Reinicie o serviço com sudo systemctl restart sshguard.

Passo 2: No servidor, abra um terminal e comece a acompanhar os logs do SSHGuard em tempo real:

sudo journalctl -fu sshguard

Passo 3: Na máquina atacante, utilize uma ferramenta como o hydra ou um simples script bash para realizar múltiplas tentativas de login SSH com senhas erradas. Vamos usar o hydra por sua facilidade:

# Instalar hydra na máquina atacante (Ubuntu/Debian)
sudo apt install hydra -y

# Lançar ataque de força bruta contra o SSH do alvo
# -l root: usuário alvo
# -P /usr/share/wordlists/rockyou.txt.gz: wordlist de senhas (descompacte se necessário)
# ssh://192.168.1.100: protocolo e IP
hydra -l root -P /usr/share/wordlists/rockyou.txt -t 4 ssh://192.168.1.100

Passo 4: Observe, no terminal do servidor, o fluxo de logs do SSHGuard. Inicialmente, você verá mensagens de Offense sendo registradas para cada falha. Após atingir o limiar configurado (30 tentativas), uma mensagem de Blocking será exibida e o ataque será interrompido, pois o firewall passará a descartar os pacotes SYN do IP atacante.

Jul 03 11:15:30 server sshguard[12543]: Offense from 192.168.1.200:1 (1 attacks in 1800 secs).
Jul 03 11:15:31 server sshguard[12543]: Offense from 192.168.1.200:2 (2 attacks in 1800 secs).
...
Jul 03 11:16:02 server sshguard[12543]: Offense from 192.168.1.200:30 (30 attacks in 1800 secs).
Jul 03 11:16:02 server sshguard[12543]: Blocking 192.168.1.200:4 for 300 secs (30 attacks in 1800 secs, last offense: 'Failed password for root from 192.168.1.200 port 22 ssh2').

Passo 5: Confirme que a regra foi inserida no firewall. Dependendo do backend, utilize o comando apropriado. Para nftables:

sudo nft list set inet filter sshguard

table inet filter {
        set sshguard {
                type ipv4_addr
                flags timeout
                elements = { 192.168.1.200 timeout 5m expires 4m58s }
        }
}

Para iptables:

sudo iptables -L sshguard -n -v

Chain sshguard (1 references)
 pkts bytes target     prot opt in     out     source               destination
   47  2820 DROP       all  --  *      *       192.168.1.200        0.0.0.0/0

Passo 6: Na máquina atacante, o hydra reportará erros de conexão (Can not connect ou timeout) porque os pacotes estão sendo descartados pelo firewall. Após 5 minutos (300 segundos), o IP será liberado automaticamente e o hydra conseguirá conectar novamente, a menos que um novo ciclo de bloqueio se inicie. Este teste comprova o funcionamento completo do sistema.

Erros Comuns e Como Resolver

Durante a implementação do SSHGuard, você pode encontrar uma série de problemas que impedem o bloqueio adequado ou causam efeitos colaterais indesejados. Com base em nossa experiência na JRT Technology Solutions resolvendo incidentes em campo, compilamos os quatro erros mais frequentes, seus sintomas, causas raiz e soluções detalhadas.

• Erro 1: Sintoma: O serviço sshguard inicia, mas nenhum bloqueio ocorre mesmo após inúmeras tentativas de força bruta. Causa: O LOGREADER está configurado incorretamente ou apontando para um arquivo/log que não contém as mensagens do serviço monitorado. Isso é comum quando se utiliza journalctl mas o serviço alvo (ex: sshd) está logando em /var/log/auth.log e o journal está desabilitado. Solução: Verifique se o journal está ativo com sudo journalctl –verify. Se não estiver, ajuste o LOGREADER para ler o arquivo diretamente: LOGREADER=”LANG=C /usr/bin/tail -F /var/log/auth.log”. Teste manualmente o comando de logreader para garantir que ele produz saída.
• Erro 2: Sintoma: O bloqueio ocorre, mas o IP bloqueado ainda consegue se conectar e fazer novas tentativas. Causa: O backend de firewall não está inserindo as regras na chain correta, ou regras pré-existentes com prioridade maior estão permitindo o tráfego antes que ele alcance a chain do SSHGuard. Isso é frequente no nftables quando há uma regra accept precedendo o jump para a chain do SSHGuard. Solução: Revise o ruleset do seu firewall. Para iptables, certifique-se de que a chain INPUT tenha uma regra sshguard no topo (ou logo após as regras de loopback e established/related). Para nftables, ajuste a prioridade da chain. Recrie o ruleset base ou permita que o SSHGuard gerencie a criação das chains (não defina regras conflitantes manualmente).
• Erro 3: Sintoma: O sistema fica lento após muitas horas de operação, com dezenas de milhares de IPs bloqueados. Causa: O backend iptables não foi projetado para lidar com um número massivo de regras lineares; cada regra é percorrida sequencialmente. Com milhares de IPs, o tempo de processamento de cada pacote aumenta linearmente. Solução: Mude para o backend nftables com sets, que utiliza estruturas de hash com lookup O(1). No arquivo de configuração, altere BACKEND=”/usr/libexec/sshguard/sshg-fw-nft-sets”. Reinicie o serviço e verifique a performance. Outra medida complementar é reduzir o BLOCKTIME e o THRESHOLD para limitar o número de IPs simultâneos na blacklist.
  

  Quer aprender na prática com especialistas?

  A JRT Technology Solutions oferece treinamentos e implementação de Segurança Linux para equipes corporativas.

  
  
  Falar no WhatsApp