{"id":2541,"date":"2026-08-29T12:05:52","date_gmt":"2026-08-29T15:05:52","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/08\/29\/sshguard-denyhosts-protecao-contra-brute-force-ssh-3\/"},"modified":"2026-08-29T12:05:52","modified_gmt":"2026-08-29T15:05:52","slug":"sshguard-denyhosts-protecao-contra-brute-force-ssh-3","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/08\/29\/sshguard-denyhosts-protecao-contra-brute-force-ssh-3\/","title":{"rendered":"SSHGuard DenyHosts prote\u00e7\u00e3o contra brute force SSH"},"content":{"rendered":"

Em um s\u00e1bado, 29 de agosto de 2026, o mundo acompanha as not\u00edcias sobre a remo\u00e7\u00e3o de minas no Estreito de Ormuz, anunciada por Trump e repercutida pela BBC, destacando como amea\u00e7as persistentes podem paralisar infraestrutura cr\u00edtica e gerar oscila\u00e7\u00f5es globais \u2014 no caso, nos pre\u00e7os do petr\u00f3leo. No campo digital, servidores Linux e Unix enfrentam um cen\u00e1rio igualmente minado: tentativas di\u00e1rias de brute force SSH<\/strong> que visam comprometer credenciais e assumir o controle de m\u00e1quinas expostas. \u00c9 exatamente nesse contexto que a combina\u00e7\u00e3o SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong> se torna uma blindagem essencial para profissionais de TI, administradores de sistemas e equipes de seguran\u00e7a da informa\u00e7\u00e3o.<\/p>\n

Ataques de for\u00e7a bruta contra o servi\u00e7o OpenSSH n\u00e3o s\u00e3o novidade, mas sua escala e sofistica\u00e7\u00e3o cresceram exponencialmente na \u00faltima d\u00e9cada. Bots distribu\u00eddos, redes de dispositivos comprometidos e ferramentas automatizadas vasculham intervalos IP inteiros atr\u00e1s de portas 22 abertas com senhas fracas ou credenciais padr\u00e3o. A aus\u00eancia de um mecanismo reativo de bloqueio transforma cada servidor em alvo f\u00e1cil, permitindo que um atacante tente milhares de combina\u00e7\u00f5es sem nenhuma consequ\u00eancia. \u00c9 aqui que ferramentas como SSHGuard<\/strong> e DenyHosts<\/strong> entram para monitorar logs, identificar padr\u00f5es maliciosos e aplicar contramedidas em tempo real.<\/p>\n

Historicamente, o DenyHosts<\/strong> foi uma das primeiras solu\u00e7\u00f5es amplamente adotadas para mitigar ataques de dicion\u00e1rio e for\u00e7a bruta em SSH. Escrito em Python, ele analisa o arquivo \/var\/log\/auth.log<\/code> (ou equivalentes) e adiciona IPs suspeitos ao \/etc\/hosts.deny<\/code>, bloqueando o acesso via TCP Wrappers. Por\u00e9m, com a evolu\u00e7\u00e3o das distribui\u00e7\u00f5es e a migra\u00e7\u00e3o para systemd e firewalls din\u00e2micos, o SSHGuard<\/strong> ganhou espa\u00e7o por sua arquitetura mais robusta, suporte a m\u00faltiplos backends de bloqueio e capacidade de monitorar diversos servi\u00e7os al\u00e9m do SSH, como FTP, SMTP e IMAP. A uni\u00e3o conceitual SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong> representa a soma das melhores pr\u00e1ticas dessas duas ferramentas complementares.<\/p>\n

Na JRT Technology Solutions<\/strong>, nossos especialistas implementam solu\u00e7\u00f5es de hardening de servidores que combinam SSHGuard<\/strong> e conceitos herdados do DenyHosts<\/strong> para reduzir drasticamente a superf\u00edcie de ataque. Ao longo deste post, voc\u00ea vai entender o cen\u00e1rio de amea\u00e7as em 2026, como cada ferramenta opera, as diferen\u00e7as t\u00e9cnicas, a instala\u00e7\u00e3o passo a passo, a integra\u00e7\u00e3o com firewalls e as melhores pr\u00e1ticas de configura\u00e7\u00e3o. O objetivo \u00e9 fornecer um guia completo para blindar seu ambiente SSH contra as investidas constantes de bots maliciosos, com o mesmo rigor t\u00e9cnico que aplicamos em nossos projetos de infraestrutura.<\/p>\n

Assim como a remo\u00e7\u00e3o de minas no Estreito de Ormuz exige intelig\u00eancia, monitoramento cont\u00ednuo e a\u00e7\u00e3o imediata para liberar a navega\u00e7\u00e3o, a seguran\u00e7a de servidores SSH demanda um sistema que identifique amea\u00e7as, bloqueie acessos indevidos e registre cada evento para auditoria. A combina\u00e7\u00e3o SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong> oferece exatamente isso: um escudo din\u00e2mico que transforma logs em intelig\u00eancia acion\u00e1vel, permitindo que administradores durmam tranquilos enquanto bots mal-intencionados s\u00e3o barrados antes de causar danos.<\/p>\n

Cen\u00e1rio de amea\u00e7as SSH em 2026: por que a prote\u00e7\u00e3o proativa \u00e9 indispens\u00e1vel<\/h3>\n

O ano de 2026 consolidou o brute force SSH<\/strong> como uma das t\u00e9cnicas mais utilizadas por atacantes para comprometer servidores. Dados de honeypots mantidos por empresas de seguran\u00e7a indicam que uma m\u00e1quina exposta na internet com a porta 22 aberta recebe, em m\u00e9dia, dezenas de milhares de tentativas de login por m\u00eas. Grande parte dessas tentativas vem de redes botnet que reciclam listas de credenciais vazadas, senhas padr\u00e3o de dispositivos IoT e combina\u00e7\u00f5es triviais como root\/root<\/code>, admin\/admin<\/code> ou ubuntu\/ubuntu<\/code>. Sem um sistema de SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong>, esses ataques passam despercebidos at\u00e9 que o pior aconte\u00e7a.<\/p>\n

A motiva\u00e7\u00e3o dos atacantes varia: minera\u00e7\u00e3o de criptomoedas, inclus\u00e3o do servidor em botnets para ataques DDoS, roubo de dados corporativos, sequestro de sites e at\u00e9 piv\u00f4 para acessar redes internas. Em infraestrutura de produ\u00e7\u00e3o, um \u00fanico acesso n\u00e3o autorizado pode resultar em paralisa\u00e7\u00e3o de servi\u00e7os, perda financeira e danos reputacionais irrevers\u00edveis. As not\u00edcias sobre a instabilidade no Estreito de Ormuz mostram como a interrup\u00e7\u00e3o de um ponto cr\u00edtico pode gerar caos global; no ambiente digital, um servidor comprometido pode ser o elo fraco que derruba uma empresa inteira.<\/p>\n

Al\u00e9m do volume, a sofistica\u00e7\u00e3o dos ataques aumentou. Ferramentas como Hydra, Ncrack e scripts em Python permitem rotacionar IPs de origem usando proxies ou servi\u00e7os de VPN, dificultando o bloqueio manual. Alguns atacantes utilizam credential stuffing<\/em> com milh\u00f5es de pares usu\u00e1rio\/senha, enquanto outros fazem ataques lentos e distribu\u00eddos para evadir limites de tentativas. Nesse cen\u00e1rio, solu\u00e7\u00f5es que apenas contam tentativas e bloqueiam ap\u00f3s um n\u00famero fixo j\u00e1 n\u00e3o bastam; \u00e9 preciso correlacionar eventos, analisar frequ\u00eancia e aplicar pol\u00edticas din\u00e2micas baseadas em reputa\u00e7\u00e3o de IP e comportamento temporal.<\/p>\n

A resposta da comunidade de software livre evoluiu para atender essa demanda. SSHGuard<\/strong> e DenyHosts<\/strong> representam duas gera\u00e7\u00f5es de ferramentas de preven\u00e7\u00e3o de intrus\u00e3o. O primeiro adota uma abordagem moderna, baseada em monitoramento de logs via tail e em filtros flex\u00edveis, bloqueando IPs diretamente em firewalls como iptables, nftables, pf ou ipfw. O segundo popularizou a t\u00e9cnica de lista negra no hosts.deny<\/em>, sendo leve e simples, mas limitado em ambientes modernos. A integra\u00e7\u00e3o SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong>, que discutiremos adiante, aproveita o melhor dos dois mundos.<\/p>\n

Na JRT Technology Solutions<\/strong>, realizamos auditorias peri\u00f3dicas de servidores e frequentemente encontramos registros de milhares de tentativas de login fracassadas em ambientes sem prote\u00e7\u00e3o. Implementamos SSHGuard<\/strong> com pol\u00edticas personalizadas e, em servidores legados, preservamos a l\u00f3gica do DenyHosts<\/strong> para compatibilidade. O resultado \u00e9 uma redu\u00e7\u00e3o de mais de 95% no ru\u00eddo de logs e a elimina\u00e7\u00e3o de acessos n\u00e3o autorizados por for\u00e7a bruta. A seguir, detalhamos o funcionamento de cada ferramenta e como combin\u00e1-las para m\u00e1xima efici\u00eancia.<\/p>\n

O que \u00e9 SSHGuard e como ele atua na prote\u00e7\u00e3o de servidores<\/h3>\n

SSHGuard<\/strong> \u00e9 um daemon de preven\u00e7\u00e3o de intrus\u00e3o desenvolvido originalmente por Mij, que monitora logs de servi\u00e7os como SSH, FTP, SMTP, IMAP, POP3 e at\u00e9 servi\u00e7os web, identificando padr\u00f5es de abuso e bloqueando os IPs ofensores por meio de backends de firewall. Diferentemente de scripts simples que leem arquivos periodicamente, o SSHGuard utiliza um leitor de logs cont\u00ednuo e eficiente, que processa eventos em tempo quase real. Ele \u00e9 escrito em C, o que lhe confere baixo consumo de recursos e alta performance, mesmo em servidores com grande volume de conex\u00f5es.<\/p>\n

O funcionamento do SSHGuard<\/strong> baseia-se em tr\u00eas componentes principais: o monitorador de logs<\/em>, que acompanha arquivos como \/var\/log\/auth.log<\/code>, \/var\/log\/secure<\/code> ou o journal do systemd; o motor de detec\u00e7\u00e3o<\/em>, que aplica regras para identificar tentativas maliciosas; e o backend de bloqueio<\/em>, que executa comandos para inserir regras de firewall ou listas de bloqueio. Entre os backends suportados est\u00e3o iptables<\/code>, nftables<\/code>, pf<\/code>, ipfw<\/code>, hosts.deny<\/code> e at\u00e9 nullroute<\/code>. Essa flexibilidade \u00e9 um dos grandes diferenciais da ferramenta.<\/p>\n

Na pr\u00e1tica, quando um atacante tenta realizar login SSH com credenciais inv\u00e1lidas repetidamente, o SSHGuard detecta o comportamento ap\u00f3s um n\u00famero configur\u00e1vel de tentativas (por exemplo, 5 em 120 segundos). Ele ent\u00e3o adiciona o IP de origem \u00e0 lista de bloqueio do firewall, impedindo que novas conex\u00f5es sejam estabelecidas, mesmo que o atacante tente outras portas ou protocolos monitorados. O bloqueio tem dura\u00e7\u00e3o padr\u00e3o configur\u00e1vel (por exemplo, 120 segundos na primeira ocorr\u00eancia, dobrando a cada reincid\u00eancia), e pode se tornar permanente ap\u00f3s m\u00faltiplas reincid\u00eancias, uma t\u00e9cnica conhecida como backoff exponencial<\/em>.<\/p>\n

Al\u00e9m do bloqueio de for\u00e7a bruta, o SSHGuard<\/strong> tamb\u00e9m protege contra port scanning<\/em> e ataques a outros servi\u00e7os monitorados. Por exemplo, se um IP faz varredura em portas FTP e SMTP, o bloqueio \u00e9 estendido a todos os servi\u00e7os gerenciados pelo daemon. Essa vis\u00e3o hol\u00edstica \u00e9 superior a ferramentas que cuidam apenas de SSH, pois um atacante que n\u00e3o consegue entrar via SSH pode tentar via FTP ou algum servi\u00e7o auxiliar. A integra\u00e7\u00e3o com firewalls modernos como nftables permite criar sets din\u00e2micos de IPs bloqueados, com inspe\u00e7\u00e3o em n\u00edvel de kernel e lat\u00eancia m\u00ednima.<\/p>\n

Na JRT Technology Solutions<\/strong>, nossos especialistas utilizam SSHGuard<\/strong> como primeira linha de defesa em servidores de clientes, configurando backends adequados a cada distribui\u00e7\u00e3o \u2014 Debian, Ubuntu, CentOS, Rocky Linux, AlmaLinux, FreeBSD e OpenBSD. Desenvolvemos playbooks Ansible e scripts de instala\u00e7\u00e3o padronizados que incluem regras de whitelist para IPs administrativos, evitando que um administrador leg\u00edtimo seja bloqueado por engano. Essa abordagem profissional garante seguran\u00e7a sem sacrificar a disponibilidade operacional.<\/p>\n

Um ponto importante \u00e9 que o SSHGuard<\/strong> n\u00e3o substitui boas pr\u00e1ticas de hardening, como desabilitar login root via senha, usar chaves SSH e alterar a porta padr\u00e3o. Ele atua como uma camada reativa inteligente, que responde automaticamente a ataques em andamento. A combina\u00e7\u00e3o de medidas preventivas e reativas forma a base da estrat\u00e9gia SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong> que recomendamos em todos os projetos, pois reduz a carga administrativa e aumenta significativamente o tempo necess\u00e1rio para um atacante comprometer um sistema.<\/p>\n

DenyHosts: a abordagem cl\u00e1ssica que ainda tem valor na prote\u00e7\u00e3o SSH<\/h3>\n

O DenyHosts<\/strong> surgiu em 2005, criado por Phil Schwartz, com o objetivo de analisar logs de autentica\u00e7\u00e3o SSH e bloquear IPs que exibissem comportamento de for\u00e7a bruta. A ferramenta se tornou um padr\u00e3o de fato em servidores Linux durante anos, gra\u00e7as \u00e0 sua simplicidade e efic\u00e1cia. Escrito em Python, ela funciona como um script que roda periodicamente (via cron ou daemon) e processa o arquivo \/var\/log\/auth.log<\/code> ou \/var\/log\/secure<\/code>, identificando tentativas de login mal sucedidas e adicionando os IPs ofensores ao arquivo \/etc\/hosts.deny<\/code>, utilizado pelo TCP Wrappers.<\/p>\n

O funcionamento do DenyHosts<\/strong> baseia-se em contadores e limites configur\u00e1veis. Por padr\u00e3o, se um IP exceder 5 tentativas de login inv\u00e1lidas para contas existentes, ele \u00e9 adicionado \u00e0 lista de bloqueio. A ferramenta tamb\u00e9m monitora tentativas contra usu\u00e1rios inexistentes, um forte indicador de ataque automatizado. O bloqueio no hosts.deny<\/code> impede que o servi\u00e7o SSH aceite conex\u00f5es do IP listado, desde que o OpenSSH esteja compilado com suporte a TCP Wrappers (o que nem sempre \u00e9 o caso em distribui\u00e7\u00f5es modernas).<\/p>\n

Um recurso interessante do DenyHosts<\/strong> \u00e9 o modo de sincroniza\u00e7\u00e3o<\/em>, que permitia compartilhar listas de bloqueio entre servidores, criando uma intelig\u00eancia coletiva contra atacantes. No passado, a central de sincroniza\u00e7\u00e3o do DenyHosts mantinha um banco de dados central de IPs maliciosos, mas esse servi\u00e7o foi descontinuado, limitando a utilidade dessa funcionalidade. Al\u00e9m disso, o DenyHosts pode bloquear IPs permanentemente ap\u00f3s reincid\u00eancias, manter whitelist e blacklist manual, e enviar e-mails de alerta ao administrador quando um novo bloqueio \u00e9 aplicado.<\/p>\n

Apesar de sua import\u00e2ncia hist\u00f3rica, o DenyHosts<\/strong> apresenta limita\u00e7\u00f5es em ambientes atuais. A principal delas \u00e9 a depend\u00eancia do TCP Wrappers, que foi removido ou descontinuado em muitas distribui\u00e7\u00f5es, como RHEL\/CentOS 7+ e vers\u00f5es recentes do Debian e Ubuntu. Outra limita\u00e7\u00e3o \u00e9 a aus\u00eancia de monitoramento em tempo real: o DenyHosts tradicional roda em intervalos, gerando uma janela de exposi\u00e7\u00e3o entre o in\u00edcio do ataque e o bloqueio. Tamb\u00e9m n\u00e3o oferece suporte nativo a firewalls como nftables ou iptables, exigindo scripts auxiliares para integra\u00e7\u00e3o.<\/p>\n

Entretanto, a l\u00f3gica do DenyHosts<\/strong> continua relevante e influenciou o design de ferramentas modernas. Na JRT Technology Solutions<\/strong>, implementamos solu\u00e7\u00f5es h\u00edbridas onde a an\u00e1lise de logs e a pol\u00edtica de bloqueio baseada em contadores s\u00e3o incorporadas ao SSHGuard<\/strong>, preservando a simplicidade do DenyHosts sem suas limita\u00e7\u00f5es t\u00e9cnicas. Para servidores legados que ainda usam TCP Wrappers, mantemos o DenyHosts como camada secund\u00e1ria, em paralelo ao SSHGuard com backend hosts.deny<\/code>, criando uma defesa em profundidade com redund\u00e2ncia.<\/p>\n

Ao comparar as duas ferramentas, fica claro que o conceito SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong> n\u00e3o se trata de escolher uma em detrimento da outra, mas de compreender como cada uma contribui para uma estrat\u00e9gia robusta. O DenyHosts trouxe a ideia de automatizar o bloqueio de IPs com base em logs, enquanto o SSHGuard elevou essa ideia a um novo patamar, com monitoramento em tempo real, m\u00faltiplos backends e detec\u00e7\u00e3o multi-servi\u00e7o. A seguir, apresentamos uma compara\u00e7\u00e3o detalhada entre as duas ferramentas.<\/p>\n

SSHGuard vs DenyHosts: compara\u00e7\u00e3o t\u00e9cnica e escolha da ferramenta certa<\/h3>\n

Para administradores que buscam implementar SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong>, \u00e9 fundamental entender as diferen\u00e7as t\u00e9cnicas entre as duas ferramentas para tomar a decis\u00e3o correta em cada cen\u00e1rio. O SSHGuard<\/strong> \u00e9 escrito em C, opera em tempo real monitorando logs com bloqueio imediato via firewall, enquanto o DenyHosts<\/strong> \u00e9 escrito em Python e trabalha de forma ass\u00edncrona, processando logs em intervalos e bloqueando via TCP Wrappers. Essas diferen\u00e7as impactam diretamente a performance, a lat\u00eancia de detec\u00e7\u00e3o e a compatibilidade com ambientes modernos.<\/p>\n

Uma vantagem significativa do SSHGuard<\/strong> \u00e9 o suporte nativo a m\u00faltiplos backends de bloqueio. Com ele, voc\u00ea pode bloquear IPs no iptables, nftables, pf, ipfw ou at\u00e9 mesmo no hosts.deny<\/code> (mantendo compatibilidade com a abordagem do DenyHosts). J\u00e1 o DenyHosts<\/strong> depende exclusivamente do \/etc\/hosts.deny<\/code>, o que exige que o OpenSSH seja compilado com suporte a TCP Wrappers \u2014 algo cada vez menos comum. Em distribui\u00e7\u00f5es como Ubuntu 20.04+ e Debian 11+, o suporte a TCP Wrappers n\u00e3o est\u00e1 mais presente por padr\u00e3o, tornando o DenyHosts ineficaz sem patches ou alternativas.<\/p>\n

Outro ponto de compara\u00e7\u00e3o \u00e9 o escopo de prote\u00e7\u00e3o. O SSHGuard<\/strong> monitora m\u00faltiplos servi\u00e7os simultaneamente: SSH, FTP, SMTP, IMAP, POP3, entre outros, permitindo bloquear um IP que ataca qualquer um deles. O DenyHosts<\/strong> foca exclusivamente em SSH, analisando logs de autentica\u00e7\u00e3o e ignorando ataques a outros daemons. Para ambientes que exp\u00f5em mais de um servi\u00e7o, o SSHGuard oferece uma defesa mais abrangente, enquanto o DenyHosts \u00e9 especializado e suficiente quando o SSH \u00e9 a \u00fanica porta aberta.<\/p>\n

A tabela a seguir resume as principais diferen\u00e7as entre as duas ferramentas, servindo como refer\u00eancia r\u00e1pida para profissionais de TI:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Caracter\u00edstica<\/th>\nSSHGuard<\/th>\nDenyHosts<\/th>\n<\/tr>\n<\/thead>\n
Linguagem<\/td>\nC (baixo consumo de recursos)<\/td>\nPython (maior consumo relativo)<\/td>\n<\/tr>\n
Tempo de detec\u00e7\u00e3o<\/td>\nTempo real (monitoramento cont\u00ednuo)<\/td>\nIntervalo agendado (cron\/daemon)<\/td>\n<\/tr>\n
Backends de bloqueio<\/td>\niptables, nftables, pf, ipfw, hosts.deny, nullroute<\/td>\nApenas \/etc\/hosts.deny (TCP Wrappers)<\/td>\n<\/tr>\n
Servi\u00e7os monitorados<\/td>\nSSH, FTP, SMTP, IMAP, POP3 e outros<\/td>\nApenas SSH<\/td>\n<\/tr>\n
Compatibilidade moderna<\/td>\nAlta (systemd, nftables, journal)<\/td>\nBaixa (depende de TCP Wrappers)<\/td>\n<\/tr>\n
Sincroniza\u00e7\u00e3o centralizada<\/td>\nN\u00e3o nativa, mas integr\u00e1vel<\/td>\nPossu\u00eda (servi\u00e7o descontinuado)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Na pr\u00e1tica, a escolha depende do contexto. Para servidores modernos com systemd e nftables, o SSHGuard<\/strong> \u00e9 a op\u00e7\u00e3o natural. Para ambientes legados ou com restri\u00e7\u00f5es espec\u00edficas, o DenyHosts<\/strong> pode ser mantido como camada adicional. Na JRT Technology Solutions<\/strong>, avaliamos cada infraestrutura individualmente e recomendamos a combina\u00e7\u00e3o SSHGuard DenyHosts prote\u00e7\u00e3o<\/strong> quando h\u00e1 necessidade de compatibilidade com sistemas antigos e novos, garantindo transi\u00e7\u00e3o suave e defesa redundante. A seguir, mostramos como instalar e configurar o SSHGuard em distribui\u00e7\u00f5es Linux populares.<\/p>\n

Instala\u00e7\u00e3o e configura\u00e7\u00e3o do SSHGuard em sistemas Linux<\/h3>\n

A instala\u00e7\u00e3o do SSHGuard<\/strong> varia de acordo com a distribui\u00e7\u00e3o, mas o processo \u00e9 simples e pode ser feito via gerenciador de pacotes. Em sistemas Debian, Ubuntu e derivados, utilize apt install sshguard<\/code>. Em distribui\u00e7\u00f5es RHEL, CentOS Stream, Rocky Linux e AlmaLinux, o pacote est\u00e1 dispon\u00edvel no reposit\u00f3rio EPEL e pode ser instalado com dnf install sshguard<\/code>. No Arch Linux, o pacote se encontra na comunidade e pode ser instalado com pacman -S sshguard<\/code>. Ap\u00f3s a instala\u00e7\u00e3o, \u00e9 necess\u00e1rio configurar o backend de firewall desejado e ajustar os par\u00e2metros de detec\u00e7\u00e3o.<\/p>\n

No Ubuntu e no Debian, o SSHGuard utiliza o sistema debconf<\/code> para configura\u00e7\u00e3o inicial. Durante a instala\u00e7\u00e3o, \u00e9 poss\u00edvel escolher o backend (iptables, nftables, hosts.deny, etc.) e definir o n\u00edvel de prote\u00e7\u00e3o. Caso prefira configura\u00e7\u00e3o manual, edite o arquivo \/etc\/sshguard\/sshguard.conf<\/code> ou crie um override no diret\u00f3rio \/etc\/sshguard\/<\/code>. Par\u00e2metros importantes incluem BACKEND<\/code> (ex.: nftables<\/code>), THRESHOLD<\/code> (n\u00famero de tentativas antes do bloqueio, padr\u00e3o 5), BLOCKTIME<\/code> (dura\u00e7\u00e3o do bloqueio em segundos, padr\u00e3o 120) e DETECTION_TIME<\/code> (janela de tempo para contagem das tentativas, padr\u00e3o 180 segundos).<\/p>\n

Para distribui\u00e7\u00f5es com systemd, o servi\u00e7o pode ser habilitado com systemctl enable --now sshguard<\/code>. \u00c9 fundamental verificar se o SSHGuard est\u00e1 lendo os logs corretamente. Em sistemas com journald, o SSHGuard pode ser configurado para ler diretamente do journal, enquanto em outros, ele monitora arquivos como \/var\/log\/auth.log<\/code>. O arquivo de configura\u00e7\u00e3o permite definir o caminho dos logs com a op\u00e7\u00e3o LOGFILE<\/code> ou usar o padr\u00e3o da distribui\u00e7\u00e3o. Testes de bloqueio podem ser realizados simulando tentativas de login inv\u00e1lidas a partir de outro IP, verificando se o bloqueio \u00e9 aplicado no firewall.<\/p>\n

A configura\u00e7\u00e3o de whitelist \u00e9 essencial para evitar que IPs leg\u00edtimos sejam bloqueados. No SSHGuard, pode-se criar o arquivo \/etc\/sshguard\/whitelist<\/code> contendo endere\u00e7os IP ou faixas CIDR, um por linha. Na JRT Technology Solutions<\/strong>, sempre adicionamos os IPs fixos dos administradores, o IP do escrit\u00f3rio e os intervalos de monitoramento \u00e0 whitelist antes de ativar o servi\u00e7o em produ\u00e7\u00e3o. Essa pr\u00e1tica previne situa\u00e7\u00f5es embara\u00e7osas de auto-bloqueio, que podem interromper o acesso administrativo e gerar incidentes operacionais.<\/p>\n

Outra configura\u00e7\u00e3o relevante \u00e9 o backoff exponencial<\/em>, que aumenta o tempo de bloqueio a cada reincid\u00eancia do mesmo IP. No SSHGuard, isso \u00e9 controlado pelas op\u00e7\u00f5es INITIAL_BLOCK_TIME<\/code>, MAX_BLOCK_TIME<\/code> e REPEAT_OFFENSE_TIME<\/code>. Por exemplo, um IP bloqueado pela primeira vez pode ficar 120 segundos sem acesso; na segunda reincid\u00eancia, 240; na terceira, 480, at\u00e9 atingir o m\u00e1ximo configurado. Essa abordagem desestimula atacantes persistentes e reduz a carga sobre o sistema, j\u00e1 que IPs reincidentes ficam bloqueados por per\u00edodos progressivamente maiores.<\/p>\n

Para ambientes com nftables, o SSHGuard cria uma<\/p>\n

\n

Gostou do conte\u00fado? Fale com nossos especialistas!<\/p>\n

A JRT Technology Solutions est\u00e1 pronta para implementar, configurar e dar suporte \u00e0s tecnologias abordadas neste artigo.<\/p>\n


\n <\/svg>
\n Falar no WhatsApp
\n <\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Em um s\u00e1bado, 29 de agosto de 2026, o mundo acompanha as not\u00edcias sobre a remo\u00e7\u00e3o de minas no Estreito de Ormuz, anunciada por Trump e repercutida pela BBC, destacando como amea\u00e7as persistentes podem paralisar infraestrutura cr\u00edtica e gerar oscila\u00e7\u00f5es globais \u2014 no caso, nos pre\u00e7os do petr\u00f3leo. No campo digital, servidores Linux e Unix … Ler mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":2540,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"iawp_total_views":0,"footnotes":""},"categories":[8],"tags":[3387],"class_list":["post-2541","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-falhas-de-seguranca","tag-sshguard-denyhosts-protecao-brute-force-ssh"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t