{"id":1380,"date":"2026-07-04T11:44:08","date_gmt":"2026-07-04T14:44:08","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/07\/04\/sshguard-denyhosts-protecao-blindagem-definitiva-contra-brut\/"},"modified":"2026-07-04T11:44:08","modified_gmt":"2026-07-04T14:44:08","slug":"sshguard-denyhosts-protecao-blindagem-definitiva-contra-brut","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/07\/04\/sshguard-denyhosts-protecao-blindagem-definitiva-contra-brut\/","title":{"rendered":"SSHGuard DenyHosts prote\u00e7\u00e3o: blindagem definitiva contra brute force SSH"},"content":{"rendered":"

Quando falamos em SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong>, estamos nos referindo a uma camada cr\u00edtica de seguran\u00e7a que todo administrador de sistemas Linux precisa compreender profundamente. Os ataques de for\u00e7a bruta contra o protocolo SSH n\u00e3o s\u00e3o apenas persistentes \u2014 eles evolu\u00edram dramaticamente nos \u00faltimos anos. Segundo a pesquisa recente divulgada pela Help Net Security, mais de 99% dos logins registrados em honeypots SSH<\/strong> s\u00e3o agora ataques n\u00e3o-interativos, executados por scanners automatizados que rodam um \u00fanico comando e se desconectam imediatamente. Essa estat\u00edstica alarmante, publicada em julho de 2026, evidencia que o cen\u00e1rio de amea\u00e7as mudou: n\u00e3o se trata mais de invasores humanos tentando senhas manualmente, mas de ex\u00e9rcitos de bots altamente eficientes que vasculham a internet em busca de credenciais fracas, chaves mal configuradas e servi\u00e7os expostos.<\/p>\n

O ecossistema de ferramentas de defesa tamb\u00e9m se transformou para acompanhar essa realidade. Durante muito tempo, solu\u00e7\u00f5es como DenyHosts<\/strong> e Fail2ban<\/strong> dominaram o mercado de prote\u00e7\u00e3o reativa \u2014 analisando logs, detectando padr\u00f5es de falha e aplicando regras de firewall para bloquear IPs suspeitos. O DenyHosts, escrito em Python e focado exclusivamente em SSH, foi pioneiro nessa abordagem, mantendo arquivos como \/etc\/hosts.deny<\/code> para rejeitar conex\u00f5es de origens maliciosas. Entretanto, com o passar dos anos, limita\u00e7\u00f5es arquiteturais come\u00e7aram a aparecer: depend\u00eancia de parsing de logs textuais, suporte restrito a backends de firewall modernos e uma comunidade de desenvolvimento que perdeu f\u00f4lego. \u00c9 nesse contexto que o SSHGuard<\/strong> emergiu como alternativa nativa e mais robusta, ganhando destaque em distribui\u00e7\u00f5es como Ubuntu 24.04 LTS, Debian 12, CentOS Stream 9 e Rocky Linux 9.<\/p>\n

Na JRT Technology Solutions<\/strong>, nossos especialistas em seguran\u00e7a da informa\u00e7\u00e3o implementam diariamente solu\u00e7\u00f5es de blindagem para servidores corporativos e ambientes de miss\u00e3o cr\u00edtica. Ao longo deste post t\u00e9cnico, vamos mergulhar na arquitetura interna do SSHGuard, demonstrar como ele herda e supera conceitos do DenyHosts, e fornecer um roteiro completo de instala\u00e7\u00e3o e configura\u00e7\u00e3o que utilizamos em nossos projetos. Abordaremos a personaliza\u00e7\u00e3o de limiares de bloqueio, a integra\u00e7\u00e3o com backends como iptables<\/strong>, nftables<\/strong>, firewalld<\/strong> e UFW<\/strong>, a interpreta\u00e7\u00e3o inteligente de logs e at\u00e9 mesmo a simula\u00e7\u00e3o pr\u00e1tica de um ataque de for\u00e7a bruta para validar a prote\u00e7\u00e3o. Se voc\u00ea \u00e9 respons\u00e1vel pela infraestrutura de servidores Linux, este guia foi escrito para voc\u00ea \u2014 com o n\u00edvel de profundidade t\u00e9cnica que a sua opera\u00e7\u00e3o exige.<\/p>\n

Al\u00e9m disso, vamos contextualizar o papel do SSHGuard dentro de uma estrat\u00e9gia mais ampla de defesa em camadas. A not\u00edcia publicada no Blog DFT Inform\u00e1tica, que detalha a Aula 21 sobre SSHGuard, mostra que a comunidade t\u00e9cnica brasileira est\u00e1 cada vez mais atenta \u00e0 necessidade de dominar ferramentas nativas de prote\u00e7\u00e3o contra ataques a m\u00faltiplos servi\u00e7os \u2014 n\u00e3o apenas SSH, mas tamb\u00e9m FTP<\/strong>, SMTP<\/strong>, IMAP<\/strong> e POP3<\/strong>. A JRT Technology Solutions desenvolve e oferece suporte completo a essas tecnologias, garantindo que nossos clientes estejam protegidos contra as amea\u00e7as mais recentes. Vamos come\u00e7ar.<\/p>\n

SSHGuard DenyHosts prote\u00e7\u00e3o: entendendo a evolu\u00e7\u00e3o das ferramentas anti brute force<\/h3>\n

Para compreender por que o SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong> representa um salto qualitativo, \u00e9 essencial revisitar a hist\u00f3ria dessas ferramentas. O DenyHosts<\/strong> foi criado em 2005 por Phil Schwartz como um script Python que monitorava o arquivo \/var\/log\/auth.log<\/code> (ou \/var\/log\/secure<\/code> em sistemas Red Hat) em busca de tentativas de login SSH fracassadas. Quando um determinado IP excedia um limite configur\u00e1vel de falhas \u2014 tipicamente 5 ou 10 tentativas \u2014 o DenyHosts inseria automaticamente uma entrada no arquivo \/etc\/hosts.deny<\/code>, bloqueando todas as conex\u00f5es futuras daquele endere\u00e7o via TCP Wrappers. Adicionalmente, o IP podia ser reportado a um servi\u00e7o centralizado de sincroniza\u00e7\u00e3o, permitindo que outros administradores se beneficiassem da intelig\u00eancia coletiva de bloqueios.<\/p>\n

O modelo funcionou bem durante anos, mas apresentava fragilidades estruturais. Primeiro, o TCP Wrappers<\/strong> perdeu relev\u00e2ncia \u00e0 medida que os backends de firewall nativos do kernel Linux evolu\u00edram \u2014 hoje, nftables<\/strong> \u00e9 o subsistema padr\u00e3o, e o iptables legado ainda coexiste em muitas distribui\u00e7\u00f5es. Segundo, o DenyHosts dependia exclusivamente de parsing textual de logs, o que introduzia lat\u00eancia e n\u00e3o oferecia uma integra\u00e7\u00e3o nativa com os daemons de log modernos como o systemd-journald<\/strong>. Terceiro, o projeto original entrou em um longo per\u00edodo de estagna\u00e7\u00e3o \u2014 o \u00faltimo release oficial no SourceForge data de 2015, e embora forks como denyhosts-ng<\/code> tenham surgido, a ado\u00e7\u00e3o nunca foi massiva. A JRT Technology Solutions frequentemente se depara com servidores legados que ainda executam DenyHosts, e nossa recomenda\u00e7\u00e3o \u00e9 sempre migrar para o SSHGuard como parte do processo de moderniza\u00e7\u00e3o da stack de seguran\u00e7a.<\/p>\n

O SSHGuard<\/strong>, por sua vez, nasceu com uma abordagem mais modular e agn\u00f3stica em rela\u00e7\u00e3o ao backend de firewall. Escrito em C para m\u00e1ximo desempenho, ele monitora logs atrav\u00e9s de pipes ou diretamente do journald, detecta padr\u00f5es de ataque em tempo real e aplica bloqueios usando o backend configurado \u2014 seja iptables<\/strong>, nftables<\/strong>, firewalld<\/strong>, UFW<\/strong>, pf<\/strong> (em sistemas BSD) ou at\u00e9 mesmo hosts.deny<\/strong> para compatibilidade retroativa com a abordagem do DenyHosts. Essa flexibilidade \u00e9 crucial em ambientes heterog\u00eaneos, onde diferentes servidores podem estar executando firewalls distintos dependendo da distribui\u00e7\u00e3o e da vers\u00e3o do kernel. Na JRT Technology Solutions, implementamos SSHGuard tanto em clusters Ubuntu 24.04 com UFW quanto em servidores Rocky Linux 9 com firewalld, mantendo uma pol\u00edtica de seguran\u00e7a consistente em toda a infraestrutura.<\/p>\n

Outro diferencial fundamental do SSHGuard em rela\u00e7\u00e3o ao DenyHosts \u00e9 o suporte a m\u00faltiplos servi\u00e7os<\/strong> simultaneamente. Enquanto o DenyHosts focava quase exclusivamente em SSH, o SSHGuard monitora e protege nativamente servi\u00e7os como FTP<\/strong> (vsftpd, proftpd), SMTP<\/strong> (Postfix, Exim), IMAP\/POP3<\/strong> (Dovecot, Courier), al\u00e9m de HTTP<\/strong> b\u00e1sico e DNS<\/strong>. Isso significa que um \u00fanico daemon pode consolidar a prote\u00e7\u00e3o de toda a stack de servi\u00e7os expostos, simplificando a gest\u00e3o e reduzindo a superf\u00edcie de configura\u00e7\u00e3o. Para profissionais de TI que gerenciam dezenas ou centenas de servidores, essa consolida\u00e7\u00e3o \u00e9 um multiplicador de efici\u00eancia operacional.<\/p>\n

Do ponto de vista da SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong>, a transi\u00e7\u00e3o de uma ferramenta para outra n\u00e3o implica apenas em trocar o software, mas em redefinir a estrat\u00e9gia de defesa. Com o SSHGuard, \u00e9 poss\u00edvel definir limiares de bloqueio espec\u00edficos por servi\u00e7o<\/strong>, tempos de blacklist din\u00e2micos e whitelists de IPs confi\u00e1veis \u2014 tudo em um \u00fanico arquivo de configura\u00e7\u00e3o. Al\u00e9m disso, a capacidade de interpretar logs de forma inteligente reduz drasticamente os falsos positivos, um problema cr\u00f4nico no DenyHosts quando usu\u00e1rios leg\u00edtimos erravam a senha algumas vezes seguidas. A pesquisa da Help Net Security que citamos no in\u00edcio deste artigo refor\u00e7a a import\u00e2ncia dessa precis\u00e3o: em um cen\u00e1rio onde 99% dos logins SSH s\u00e3o ataques automatizados, o sistema de defesa precisa distinguir com clareza entre tr\u00e1fego malicioso e opera\u00e7\u00f5es leg\u00edtimas de administra\u00e7\u00e3o.<\/p>\n

Arquitetura interna do SSHGuard: backends, parsers e o ciclo de bloqueio<\/h3>\n

A arquitetura do SSHGuard \u00e9 elegantemente simples, por\u00e9m poderosa. O daemon opera em tr\u00eas camadas distintas: a camada de monitoramento de logs<\/strong>, a camada de detec\u00e7\u00e3o de padr\u00f5es<\/strong> e a camada de aplica\u00e7\u00e3o de bloqueios<\/strong>. Na primeira camada, o SSHGuard pode ler logs de m\u00faltiplas fontes simultaneamente \u2014 arquivos de log tradicionais monitorados via tail -f<\/code> interno, pipes nomeados, ou diretamente do systemd-journald<\/strong> atrav\u00e9s da API nativa. Essa \u00faltima op\u00e7\u00e3o \u00e9 particularmente eficiente em distribui\u00e7\u00f5es modernas, pois elimina a necessidade de parsing de arquivos em disco e oferece acesso estruturado aos campos de cada entrada de log, como PID do processo, UID do usu\u00e1rio e mensagem exata.<\/p>\n

A camada de detec\u00e7\u00e3o<\/strong> utiliza parsers espec\u00edficos para cada tipo de servi\u00e7o. O parser de SSH, por exemplo, \u00e9 calibrado para reconhecer mensagens cl\u00e1ssicas do OpenSSH como Failed password for root from 192.168.1.100 port 22 ssh2<\/code>, Invalid user admin from 203.0.113.50<\/code> ou Connection closed by authenticating user<\/code>. Cada parser extrai o endere\u00e7o IP de origem e classifica a tentativa como suspeita. O SSHGuard mant\u00e9m uma tabela de estado em mem\u00f3ria<\/strong> que rastreia quantas tentativas mal-sucedidas cada IP acumulou dentro de uma janela de tempo configur\u00e1vel (por padr\u00e3o, 120 segundos). Quando o limiar de bloqueio \u00e9 atingido \u2014 tipicamente 4 tentativas para SSH \u2014 o IP \u00e9 adicionado temporariamente a uma blacklist interna e o bloqueio \u00e9 aplicado atrav\u00e9s da camada de firewall.<\/p>\n

A camada de aplica\u00e7\u00e3o de bloqueios<\/strong> \u00e9 onde o SSHGuard realmente brilha em compara\u00e7\u00e3o com o DenyHosts. Utilizando um conceito de backend plug\u00e1vel<\/strong>, o daemon pode invocar comandos espec\u00edficos para manipular regras de firewall no formato adequado ao sistema. Para iptables<\/strong>, ele insere regras na chain sshguard<\/code> (criada automaticamente) que redirecionam pacotes do IP ofensor para DROP ou REJECT. Para nftables<\/strong>, utiliza a sintaxe nativa de sets din\u00e2micos, que s\u00e3o muito mais eficientes em termos de desempenho quando a lista de bloqueio cresce. Para firewalld<\/strong>, cria rich-rules que se integram perfeitamente \u00e0 gest\u00e3o de zonas do firewall. E para UFW<\/strong>, adiciona regras numeradas que podem ser facilmente inspecionadas com ufw status<\/code>. Na JRT Technology Solutions, nossa pr\u00e1tica padr\u00e3o \u00e9 utilizar o backend nftables por sua efici\u00eancia, mas mantemos documenta\u00e7\u00e3o completa para todos os cen\u00e1rios.<\/p>\n

Um aspecto frequentemente negligenciado, mas crucial, \u00e9 o mecanismo de expira\u00e7\u00e3o autom\u00e1tica<\/strong> dos bloqueios. Diferentemente do DenyHosts, onde uma entrada no \/etc\/hosts.deny<\/code> permanecia indefinidamente a menos que um cron job a removesse, o SSHGuard aplica bloqueios com TTL (time-to-live) configur\u00e1vel. Ap\u00f3s o per\u00edodo de blacklist \u2014 padr\u00e3o de 420 segundos, ou 7 minutos \u2014 o IP \u00e9 automaticamente removido do firewall. Isso evita o ac\u00famulo infinito de regras que, em servidores com alto volume de ataques, poderia degradar o desempenho do firewall. Al\u00e9m disso, o SSHGuard implementa um gargabe collector interno<\/strong> que periodicamente varre IPs expirados e libera mem\u00f3ria, garantindo que o daemon permane\u00e7a leve mesmo ap\u00f3s semanas de opera\u00e7\u00e3o cont\u00ednua sob ataque intenso.<\/p>\n

A tabela a seguir resume os principais backends de firewall suportados pelo SSHGuard e suas caracter\u00edsticas de implementa\u00e7\u00e3o:<\/p>\n\n\n\n\n\n\n\n\n\n
Backend<\/th>\nDistribui\u00e7\u00f5es t\u00edpicas<\/th>\nDesempenho<\/th>\nObserva\u00e7\u00f5es<\/th>\n<\/tr>\n<\/thead>\n
iptables<\/td>\nDebian 11, CentOS 7, Ubuntu 20.04<\/td>\nBom para listas com at\u00e9 ~5000 IPs<\/td>\nLegado, mas ainda funcional; regras lineares causam overhead em listas grandes<\/td>\n<\/tr>\n
nftables<\/td>\nDebian 12, Ubuntu 24.04, Rocky 9<\/td>\nExcelente; sets din\u00e2micos suportam milhares de IPs sem degrada\u00e7\u00e3o<\/td>\nRecomendado pela JRT para novos deployments; sintaxe moderna e eficiente<\/td>\n<\/tr>\n
firewalld<\/td>\nCentOS Stream 9, Rocky 9, RHEL 9<\/td>\nMuito bom; integra\u00e7\u00e3o com zonas e servi\u00e7os<\/td>\nIdeal para ambientes corporativos com pol\u00edticas de zona; rich-rules flex\u00edveis<\/td>\n<\/tr>\n
UFW<\/td>\nUbuntu (todas as vers\u00f5es)<\/td>\nAdequado para cen\u00e1rios com poucas dezenas de bloqueios simult\u00e2neos<\/td>\nSimplicidade para iniciantes; limita\u00e7\u00f5es em escala, mas suficiente para a maioria dos servidores<\/td>\n<\/tr>\n
hosts.deny<\/td>\nQualquer distribui\u00e7\u00e3o com TCP Wrappers<\/td>\nModerado; compat\u00edvel com DenyHosts<\/td>\nCompatibilidade retroativa; n\u00e3o recomendado para novos projetos<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

SSHGuard DenyHosts prote\u00e7\u00e3o na pr\u00e1tica: instala\u00e7\u00e3o em Ubuntu, Debian, CentOS Stream e Rocky Linux<\/h3>\n

A instala\u00e7\u00e3o do SSHGuard \u00e9 notavelmente simples em todas as principais distribui\u00e7\u00f5es Linux, o que contrasta com o processo de configura\u00e7\u00e3o do DenyHosts \u2014 que frequentemente exigia a instala\u00e7\u00e3o manual de depend\u00eancias Python e scripts de inicializa\u00e7\u00e3o personalizados. Em distribui\u00e7\u00f5es baseadas em Debian, como o Ubuntu 24.04 LTS<\/strong> e o Debian 12<\/strong>, o SSHGuard est\u00e1 dispon\u00edvel diretamente nos reposit\u00f3rios oficiais. Basta executar apt update && apt install sshguard -y<\/code> para obter a vers\u00e3o est\u00e1vel compilada e pronta para uso. O pacote inclui o bin\u00e1rio principal, o arquivo de configura\u00e7\u00e3o \/etc\/sshguard\/sshguard.conf<\/code> (em algumas vers\u00f5es, \/etc\/sshguard.conf<\/code>), um servi\u00e7o systemd e scripts de integra\u00e7\u00e3o com os backends de firewall mais comuns.<\/p>\n

Para distribui\u00e7\u00f5es da fam\u00edlia Red Hat, como CentOS Stream 9<\/strong> e Rocky Linux 9<\/strong>, o SSHGuard est\u00e1 dispon\u00edvel no reposit\u00f3rio EPEL<\/strong> (Extra Packages for Enterprise Linux). Ap\u00f3s habilitar o EPEL com dnf install epel-release -y<\/code>, o comando dnf install sshguard -y<\/code> instala o pacote e suas depend\u00eancias. Uma diferen\u00e7a importante \u00e9 que nessas distribui\u00e7\u00f5es, o backend padr\u00e3o pode ser configurado para firewalld<\/strong> em vez de iptables, refletindo a prefer\u00eancia do ecossistema Red Hat. Na JRT Technology Solutions, ajustamos essa configura\u00e7\u00e3o durante o playbook de deploy automatizado que utilizamos para provisionar servidores: o Ansible detecta a distribui\u00e7\u00e3o e aplica o backend de firewall correto automaticamente.<\/p>\n

Ap\u00f3s a instala\u00e7\u00e3o, \u00e9 fundamental configurar o backend de firewall antes de iniciar o servi\u00e7o. O arquivo de configura\u00e7\u00e3o principal (geralmente \/etc\/sshguard\/sshguard.conf<\/code>) cont\u00e9m a diretiva BACKEND<\/code>, que deve ser ajustada conforme o ambiente. Para servidores Ubuntu com UFW, a configura\u00e7\u00e3o recomendada \u00e9:<\/p>\n