Aula 22: DenyHosts — bloqueio automático de IPs maliciosos via SSH com sincronização

O DenyHosts é uma ferramenta de segurança desenvolvida especificamente para proteger servidores Linux contra ataques de força bruta direcionados ao serviço SSH. Diferente de soluções genéricas de prevenção de intrusão, o DenyHosts analisa os arquivos de log de autenticação do sistema, identifica endereços IP que apresentam múltiplas falhas consecutivas de login e os bloqueia automaticamente, adicionando-os ao arquivo /etc/hosts.deny. O que torna essa ferramenta verdadeiramente poderosa é sua capacidade de operar em modo sincronizado, compartilhando listas de atacantes entre servidores distintos — um recurso que faltava nas primeiras versões e que agora está consolidado. Nesta aula, você dominará a instalação, configuração avançada e operação do DenyHosts em ambientes de produção, incluindo a configuração do sistema de sincronização centralizada que permite que múltiplos servidores contribuam e se beneficiem de uma base compartilhada de IPs maliciosos.

Servidores SSH expostos à internet são alvos constantes de scanners automatizados e botnets que tentam adivinhar credenciais utilizando dicionários de senhas comuns. Em nossos projetos na JRT Technology Solutions, observamos diariamente milhares de tentativas de login maliciosas contra servidores de clientes, mesmo aqueles que utilizam portas SSH não-padrão. O DenyHosts se destaca nesse cenário por ser uma solução leve, escrita em Python, que não depende de regras complexas de firewall como o iptables ou nftables — ele atua diretamente na camada de wrappers TCP, utilizando o mecanismo nativo /etc/hosts.deny do Linux, o que o torna compatível com virtualmente qualquer distribuição Linux, independentemente do backend de firewall em uso.

Esta aula foi projetada para profissionais de infraestrutura, analistas de segurança e administradores de sistemas que já possuem familiaridade com o protocolo SSH, gerenciamento de serviços systemd e edição de arquivos de configuração em ambientes Linux. Ao final desta aula, você será capaz de implementar uma defesa robusta e automatizada contra ataques de força bruta SSH, configurar thresholds de tolerância customizados, gerenciar listas de whitelist de IPs confiáveis, ativar o modo de sincronização para compartilhar inteligência de ameaças entre servidores, e diagnosticar problemas operacionais comuns do DenyHosts através da análise de logs.

O conteúdo está estruturado de forma progressiva: começaremos entendendo os fundamentos da detecção de força bruta do DenyHosts, passando pela instalação passo a passo tanto em distribuições baseadas em Debian quanto em RHEL, mergulharemos na configuração detalhada de cada parâmetro relevante, ativaremos o poderoso recurso de sincronização centralizada, realizaremos testes práticos de verificação, e concluiremos com boas práticas avançadas para ambientes de produção. Cada comando apresentado foi testado em laboratório e pode ser executado por você imediatamente após a leitura.

O que você vai aprender nesta aula

• Compreender o mecanismo de detecção de força bruta do DenyHosts através da análise de logs de autenticação
• Instalar e ativar o DenyHosts em Ubuntu/Debian 22.04+ e CentOS/RHEL/Rocky Linux 9 respectivamente
• Configurar o arquivo /etc/denyhosts.conf com parâmetros customizados para cenários de produção
• Gerenciar whitelists e blacklists estáticas de endereços IP
• Ativar e testar o modo de sincronização centralizada (SYNC_SERVER) entre múltiplos servidores
• Interpretar logs gerados pelo DenyHosts para auditoria e troubleshooting
• Resolver os erros mais frequentes encontrados durante a implantação e operação
• Automatizar a remoção de bloqueios expirados e realizar manutenção contínua

Pré-requisitos e ambiente

Antes de iniciar esta aula, você precisa ter um servidor Linux com acesso root ou sudo, serviço SSH (sshd) em execução e devidamente configurado, e acesso à internet para download de pacotes. É fortemente recomendado que você tenha concluído as aulas anteriores do nosso curso, especialmente as que abordam fundamentos de SSH (Aula 5), gerenciamento de logs do sistema (Aula 12), e configuração de wrappers TCP com /etc/hosts.allow e /etc/hosts.deny (Aula 18). Para os exemplos desta aula, utilizaremos os seguintes ambientes de teste:

1. Servidor Ubuntu 24.04 LTS: denominado “server-ubuntu” (IP 10.0.0.11), será usado para demonstrar a instalação via apt
2. Servidor Rocky Linux 9: denominado “server-rocky” (IP 10.0.0.12), será usado para demonstrar a instalação via EPEL
3. Servidor de Sincronização Central: um terceiro servidor que hospedará a lista compartilhada de IPs bloqueados, simulando um ambiente multi-servidor realista

Os comandos apresentados foram testados nesses ambientes específicos; se você estiver usando versões ligeiramente diferentes, os caminhos de arquivos e nomes de pacotes podem variar minimamente. Certifique-se também de que o serviço cron ou systemd timers esteja disponível — o DenyHosts depende de uma tarefa agendada (ou daemon contínuo) para processar os logs periodicamente.

Como funciona o DenyHosts: fundamentos de detecção e bloqueio

O DenyHosts opera como um analisador de logs especializado. Seu principal alvo é o arquivo /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/Rocky Linux), onde o daemon SSH registra cada tentativa de autenticação — bem-sucedida ou não. Quando um cliente SSH tenta se conectar e falha na autenticação, o sshd escreve uma linha no log contendo o endereço IP de origem, o timestamp e o motivo da falha (senha incorreta, usuário inexistente, chave inválida, etc.). O DenyHosts varre essas entradas em busca de padrões que indiquem comportamento malicioso, como múltiplas falhas consecutivas do mesmo IP em um curto intervalo de tempo.

O motor de decisão do DenyHosts baseia-se em thresholds configuráveis. O parâmetro mais importante é DENY_THRESHOLD_INVALID, que define quantas tentativas de login com um nome de usuário inválido (inexistente no sistema) são toleradas antes do bloqueio. Há thresholds separados para usuários válidos (DENY_THRESHOLD_VALID), para o usuário root (DENY_THRESHOLD_ROOT), e para bloqueios permanentes após um certo número de reincidências (DENY_THRESHOLD_RESTRICTED). Essa granularidade permite que administradores ajustem a sensibilidade da ferramenta de acordo com a política de segurança da organização — em nossos projetos na JRT Technology Solutions, por exemplo, costumamos endurecer os thresholds para o usuário root, bloqueando após apenas 1 tentativa mal-sucedida.

Uma vez que um IP atinge o threshold definido, o DenyHosts executa duas ações principais: adiciona uma linha no arquivo /etc/hosts.deny no formato sshd: <IP>, efetivamente bloqueando futuras conexões SSH daquela origem via wrappers TCP, e registra o IP em seu banco de dados interno (tipicamente arquivos sincronizados no diretório /var/lib/denyhosts/). O bloqueio via /etc/hosts.deny é imediato e não requer recarga do serviço SSH — o próprio mecanismo de wrappers TCP consulta esse arquivo a cada nova conexão, rejeitando o tráfego antes mesmo que o sshd processe a requisição. Esse é um dos pontos fortes do DenyHosts: ele não depende de regras de iptables, o que simplifica sua operação em ambientes com firewalls complexos ou em containers onde o iptables pode não estar disponível.

O recurso de sincronização do DenyHosts opera através de um protocolo simples baseado em XML-RPC ou em sincronização de arquivos via rsync/HTTP. No modo de sincronização centralizada, um servidor designado como mestre (SYNC_SERVER) mantém uma lista agregada de IPs bloqueados reportados por todos os servidores participantes. Cada servidor cliente, ao detectar e bloquear um novo IP malicioso, envia essa informação ao servidor central. Periodicamente, todos os servidores baixam a lista consolidada do servidor central e adicionam os IPs reportados por outros nós ao seu próprio /etc/hosts.deny. Esse modelo de inteligência coletiva é extremamente eficaz em datacenters com dezenas ou centenas de servidores, pois um ataque detectado em um único nó automaticamente protege todos os demais em poucos minutos.

Instalando o DenyHosts em Ubuntu/Debian

A instalação do DenyHosts em distribuições baseadas em Debian é direta, pois o pacote está disponível nos repositórios oficiais do Ubuntu desde versões antigas. No entanto, é importante verificar se a versão disponível no repositório atende aos requisitos do seu ambiente — em alguns casos, pode ser preferível compilar a versão mais recente a partir do fonte. Para esta aula, utilizaremos o repositório padrão, que oferece uma versão estável e bem testada. Execute a sequência completa de instalação conforme demonstrado abaixo em seu servidor Ubuntu:

# Atualiza a lista de pacotes disponíveis nos repositórios configurados
sudo apt update

# Instala o pacote denyhosts e suas dependências (python3, lsb-base, etc.)
sudo apt install -y denyhosts

# Após a instalação, verifica o status do serviço
sudo systemctl status denyhosts

● denyhosts.service - DenyHosts daemon
     Loaded: loaded (/lib/systemd/system/denyhosts.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-07-09 10:15:23 -03; 45s ago
    Process: 2841 ExecStart=/usr/sbin/denyhosts --daemon --config=/etc/denyhosts.conf (code=exited, status=0/SUCCESS)
   Main PID: 2843 (denyhosts)
      Tasks: 1 (limit: 2315)
     Memory: 18.4M
        CPU: 342ms
     CGroup: /system.slice/denyhosts.service
             └─2843 /usr/bin/python3 /usr/sbin/denyhosts --daemon --config=/etc/denyhosts.conf

Jul 09 10:15:23 server-ubuntu systemd[1]: Starting DenyHosts daemon...
Jul 09 10:15:23 server-ubuntu systemd[1]: Started DenyHosts daemon.

Os comandos acima realizam três etapas essenciais: atualização da cache de pacotes (apt update), instalação do pacote denyhosts com confirmação automática (-y), e verificação do status do serviço via systemd. Note na saída que o serviço foi iniciado automaticamente após a instalação e está em execução como um daemon contínuo, utilizando o arquivo de configuração padrão /etc/denyhosts.conf. O PID 2843 indica que o processo está rodando sob o interpretador Python 3 — isso é relevante porque versões muito antigas do DenyHosts dependiam de Python 2, que já está obsoleto; as versões atuais utilizam Python 3 nativamente.

Instalando o DenyHosts em CentOS/RHEL/Rocky Linux

Em distribuições da família Red Hat, o DenyHosts não está disponível nos repositórios oficiais padrão, sendo necessário habilitar o repositório EPEL (Extra Packages for Enterprise Linux). O EPEL é um repositório comunitário mantido pelo Fedora Project que fornece pacotes adicionais de alta qualidade para RHEL e derivados. Antes de prosseguir, certifique-se de que seu sistema está registrado e tem acesso aos repositórios base — no Rocky Linux 9, isso significa que os repositórios baseos e appstream devem estar habilitados por padrão. Execute a sequência completa abaixo no seu servidor Rocky Linux:

# Instala o pacote epel-release para habilitar o repositório EPEL
sudo dnf install -y epel-release

# Atualiza o cache de metadados dos repositórios, incluindo o EPEL recém-adicionado
sudo dnf makecache

# Instala o denyhosts disponível no repositório EPEL
sudo dnf install -y denyhosts

# Após a instalação, verifica o status do serviço
sudo systemctl status denyhosts

● denyhosts.service - DenyHosts daemon
     Loaded: loaded (/usr/lib/systemd/system/denyhosts.service; disabled; vendor preset: disabled)
     Active: inactive (dead)

Jul 09 10:22:45 server-rocky systemd[1]: denyhosts.service: Unit cannot be reloaded because it is inactive.

Observe uma diferença importante em relação ao Ubuntu: no Rocky Linux 9, o serviço denyhosts é instalado mas não é ativado automaticamente para inicialização, nem iniciado imediatamente. Isso ocorre por uma escolha de empacotamento dos mantenedores do EPEL, que preferem que o administrador revise a configuração antes de ativar o serviço. Veremos como iniciar e habilitar o DenyHosts logo após configurá-lo adequadamente. Atente também ao caminho do arquivo de unit do systemd: /usr/lib/systemd/system/denyhosts.service no RHEL/Rocky versus /lib/systemd/system/denyhosts.service no Debian/Ubuntu — ambos funcionam de forma idêntica, mas a localização exata pode ser relevante se você precisar criar overrides de configuração.

Configuração detalhada do DenyHosts: o arquivo denyhosts.conf completo

O arquivo /etc/denyhosts.conf é o centro de controle do DenyHosts. Cada parâmetro neste arquivo governa um aspecto específico do comportamento da ferramenta, desde os thresholds de bloqueio até os caminhos dos arquivos de log a serem monitorados. Uma configuração inadequada pode resultar em falsos positivos (bloqueio de IPs legítimos) ou, pior, em falsos negativos (falha em detectar ataques reais). Abaixo apresentamos uma configuração completa, comentada linha a linha, que servirá como baseline para ambientes de produção moderadamente expostos. Antes de editar o arquivo original, faça uma cópia de backup:

# Backup do arquivo de configuração original fornecido pelo pacote
sudo cp /etc/denyhosts.conf /etc/denyhosts.conf.original

# Edite o arquivo com seu editor preferido (nano, vim, etc.)
sudo vim /etc/denyhosts.conf

Substitua o conteúdo pelo seguinte (os comentários explicam cada parâmetro):

############################################
# DenyHosts Configuration File
# Curso Segurança Linux - Aula 22
# JRT Technology Solutions - Baseline
############################################

# ---------- ARQUIVOS DE LOG MONITORADOS ----------
# Caminho absoluto do arquivo de log de autenticação.
# Em Debian/Ubuntu: /var/log/auth.log
# Em RHEL/Rocky:    /var/log/secure
SECURE_LOG = /var/log/auth.log

# Caminho alternativo legado (mantido para compatibilidade)
# Normalmente aponta para o mesmo arquivo acima
ALTERNATE_SECURE_LOG = /var/log/auth.log

# ---------- ARQUIVOS DE ESTADO E BANCO DE DADOS ----------
# Arquivo que armazena o timestamp da última linha de log processada
# Evita reprocessamento de entradas antigas a cada execução
OFFSET_FILE = /var/lib/denyhosts/offset

# Diretório onde DenyHosts mantém seus bancos de dados internos
# (usuários bloqueados, IPs, estatísticas, etc.)
WORK_DIR = /var/lib/denyhosts

# ---------- ARQUIVO DE BLOQUEIO TCP WRAPPERS ----------
# Arquivo que será modificado para incluir regras de bloqueio
# Formato adicionado: "sshd: "
HOSTS_DENY = /etc/hosts.deny

# ---------- BLOQUEIO DE NOVAS CONEXÕES ----------
# Se YES, DenyHosts também bloqueia o IP via iptables (opcional)
# Deixamos NO pois utilizamos exclusivamente wrappers TCP
BLOCK_SERVICE = NO

# ---------- THRESHOLDS DE BLOQUEIO ----------
# Número de tentativas de login com usuário INVÁLIDO (inexistente)
# antes do bloqueio. Redes com muitos scanners exigem valor baixo.
DENY_THRESHOLD_INVALID = 5

# Número de tentativas de login com usuário VÁLIDO mas senha errada
# Geralmente mais tolerante para evitar lockout acidental
DENY_THRESHOLD_VALID = 10

# Número de tentativas de login como root (altamente visado)
# Recomenda-se 1 em produção, pois root não deve fazer login direto
DENY_THRESHOLD_ROOT = 1

# Número de bloqueios que um IP já sofreu para ser permanentemente banido
# (marcado como "restricted" e nunca mais removido automaticamente)
DENY_THRESHOLD_RESTRICTED = 3

# ---------- TEMPO DE SUSPENSÃO DE IP BLOQUEADO ----------
# Após quantos dias um IP bloqueado pode ser removido automaticamente
# (se não estiver na lista de restricted)
PURGE_DENY = 7d

# Se YES, ao atingir DENY_THRESHOLD_RESTRICTED, o IP nunca é purgado
PURGE_THRESHOLD_RESTRICTED = YES

# ---------- SUSPENSÃO DE USUÁRIOS SUSPEITOS ----------
# Tempo durante o qual um nome de usuário que falhou login é rastreado
SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS = YES

# ---------- SINCRONIZAÇÃO (SERVIDOR CENTRAL) ----------
# Modo de sincronização: YES para ativar o envio/recebimento de listas
SYNC_SERVER = NO

# URL do servidor central de sincronização (formato XML-RPC)
# Exemplo: http://sync.exemplo.com/denyhosts/server.php
SYNC_SERVER_URL = http://10.0.0.100/denyhosts/sync.php

# Frequência (em segundos) com que o cliente envia seus bloqueios
SYNC_INTERVAL = 3600

# Arquivo local que armazena os IPs baixados do servidor central
SYNC_DOWNLOAD = /var/lib/denyhosts/sync-hosts

# Arquivo local que armazena os IPs a serem enviados ao servidor central
SYNC_UPLOAD = /var/lib/denyhosts/sync-upload

# ---------- WHITELIST (LISTA DE IPs NUNCA BLOQUEADOS) ----------
# Caminho do arquivo de IPs confiáveis (um IP por linha)
ALLOWED_HOSTS = /var/lib/denyhosts/allowed-hosts

# ---------- NOTIFICAÇÕES POR EMAIL ----------
# Enviar email ao administrador quando um IP é bloqueado?
ADMIN_EMAIL = admin@exemplo.com

# Remetente dos emails (deve ser aceito pelo MTA local)
SMTP_FROM = denyhosts@exemplo.com

# Assunto do email de notificação
SMTP_SUBJECT = [DenyHosts] IP bloqueado: %s

# ---------- SINCRONIZAÇÃO DE TIMESTAMP ----------
# Formato de data utilizado nos arquivos de offset
# (ajuste conforme locale do sistema)
DATE_FORMAT = %b %d %H:%M:%S

# ---------- CONTROLE DE DAEMON ----------
# Se YES, DenyHosts roda continuamente em background (modo daemon)
DAEMON_LOG = /var/log/denyhosts

# Nível de verbosidade do log: DEBUG, INFO, WARNING, ERROR, CRITICAL
DAEMON_LOG_LEVEL = INFO

# Frequência (em segundos) de polling do arquivo de log em modo daemon
DAEMON_SLEEP = 30

# Arquivo de PID para o daemon
PID_FILE = /var/run/denyhosts.pid

# ---------- LIMPEZA AUTOMÁTICA ----------
# Remover entradas do /etc/hosts.deny que não estão mais no banco?
# YES mantém o hosts.deny sincronizado com o estado real
HOSTS_DENY_CLEANUP = YES

# ---------- BLOQUEIO DE IP POR SERVIÇO ----------
# Se YES, adiciona entradas "ALL: " em vez de "sshd: "
BLOCK_SERVICE_SSHD = YES

Esta configuração representa um ponto de partida balanceado entre segurança e usabilidade. O DENY_THRESHOLD_ROOT = 1 é particularmente agressivo e reflete as práticas que adotamos na JRT Technology Solutions: considerando que o login direto como root via SSH deve estar desabilitado (PermitRootLogin no no sshd_config), qualquer tentativa de autenticação como root é, por definição, maliciosa. O parâmetro SYNC_SERVER está como NO por enquanto — ativaremos a sincronização em uma seção específica mais adiante. O arquivo ALLOWED_HOSTS será populado com os IPs da sua rede interna e de estações de administração confiáveis para evitar auto-bloqueio acidental.

Populando a whitelist e protegendo IPs confiáveis

Um dos erros mais comuns — e potencialmente catastróficos — na implantação do DenyHosts é não configurar adequadamente a whitelist de IPs confiáveis. Sem essa proteção, se um administrador legítimo errar a senha algumas vezes (ou se um script de automação mal configurado tentar autenticar repetidamente), o IP da estação de trabalho ou do servidor de gerenciamento será bloqueado, resultando em perda total de acesso SSH. Para evitar esse cenário, você deve criar o arquivo /var/lib/denyhosts/allowed-hosts e populá-lo com todos os IPs e faixas de rede que devem ser imunes ao bloqueio. Execute os comandos abaixo para criar e popular o arquivo:

# Cria o arquivo de whitelist (se não existir) e define permissões seguras
sudo touch /var/lib/denyhosts/allowed-hosts
sudo chmod 640 /var/lib/denyhosts/allowed-hosts
sudo chown root:root /var/lib/denyhosts/allowed-hosts

# Edita o arquivo adicionando IPs confiáveis (exemplos)
sudo tee /var/lib/denyhosts/allowed-hosts > /dev/null << 'EOF'
# IPs e redes confiáveis - nunca serão bloqueados pelo DenyHosts
# Formato: um IP ou faixa CIDR por linha
10.0.0.0/8
172.16.0.0/12
192.168.1.100
203.0.113.50
EOF

# Verifica o conteúdo do arquivo
cat /var/lib/denyhosts/allowed-hosts

# IPs e redes confiáveis - nunca serão bloqueados pelo DenyHosts
# Formato: um IP ou faixa CIDR por linha
10.0.0.0/8
172.16.0.0/12
192.168.1.100
203.0.113.50

Observe alguns pontos críticos: utilizamos o comando tee com redirecionamento para escrever no arquivo como root, garantindo que as permissões não sejam alteradas acidentalmente. As faixas 10.0.0.0/8 e 172.16.0.0/12 cobrem todos os endereços privados RFC 1918, o que é seguro e recomendado para a maioria dos ambientes onde a administração é feita internamente. O IP público 203.0.113.50 é um placeholder — substitua pelo endereço público fixo do seu escritório ou VPN corporativa. Lembre-se de que o DenyHosts processa essa whitelist a cada execução; se você adicionar um novo IP posteriormente, não é necessário reiniciar o serviço, pois o daemon relê o arquivo periodicamente.

Ativando a sincronização centralizada do DenyHosts

O modo de sincronização do DenyHosts transforma a ferramenta de uma solução local para uma defesa colaborativa em rede. O princípio é simples: um servidor central atua como repositório de uma lista compartilhada de IPs maliciosos. Cada servidor participante, ao bloquear um novo IP, notifica o servidor central. Periodicamente, todos os servidores baixam a lista agregada e aplicam os bloqueios em seus próprios /etc/hosts.deny. Esse mecanismo é particularmente valioso em ambientes corporativos com múltiplos servidores, como os que gerenciamos na JRT Technology Solutions, onde um ataque detectado no servidor web de desenvolvimento imediatamente protege também os servidores de produção, bancos de dados e balanceadores de carga.

Para ativar a sincronização, você precisa de um servidor central executando um script PHP de sincronização (fornecido com o código-fonte do DenyHosts) ou um simples compartilhamento HTTP onde o arquivo sync-hosts possa ser lido e escrito por todos os participantes. Nesta aula, demonstraremos a configuração usando o servidor central em 10.0.0.100 com Apache e PHP. Primeiro, no servidor central, configure o ambiente:

# No servidor central (10.0.0.100):
# Instala Apache e PHP se ainda não estiverem presentes
sudo apt install -y apache2 php libapache2-mod-php

# Cria o diretório que hospedará os arquivos de sincronização
sudo mkdir -p /var/www/html/denyhosts
sudo chown www-data:www-data /var/www/html/denyhosts

# Cria um arquivo sync.php simples que aceita uploads e fornece a lista
sudo tee /var/www/html/denyhosts/sync.php > /dev/null << 'PHPEOF'

PHPEOF

# Ajusta permissões
sudo chown www-data:www-data /var/www/html/denyhosts/sync.php
sudo chmod 644 /var/www/html/denyhosts/sync.php

Agora, em cada cliente (servidores Ubuntu e Rocky Linux configurados anteriormente), edite o arquivo /etc/denyhosts.conf alterando os seguintes parâmetros:

# Ativa o modo de sincronização
SYNC_SERVER = YES

# URL do servidor central (ajuste conforme seu ambiente)
SYNC_SERVER_URL = http://10.0.0.100/denyhosts/sync.php

# Intervalo de sincronização (3600 segundos = 1 hora)
SYNC_INTERVAL = 3600

# Arquivos locais de sincronização
SYNC_DOWNLOAD = /var/lib/denyhosts/sync-hosts
SYNC_UPLOAD = /var/lib/denyhosts/sync-upload

Após alterar a configuração, reinicie o serviço denyhosts em cada cliente para aplicar as mudanças. O daemon passará a enviar periodicamente seus IPs bloqueados ao servidor central e a baixar a lista consolidada, aplicando automaticamente os bloqueios reportados por outros servidores. Para verificar se a sincronização está funcionando, monitore os logs do Apache no servidor central e o arquivo /var/log/denyhosts em cada cliente. Você deve ver entradas indicando o envio e recebimento de dados de sincronização.

Verificando a instalação e testando a configuração

Uma instalação do DenyHosts só está verdadeiramente validada quando conseguimos confirmar que o sistema está monitorando ativamente os logs, aplicando bloqueios conforme os thresholds definidos e registrando suas ações de forma rastreável. Nesta seção, executaremos uma bateria de verificações que nos permitirão atestar o funcionamento correto da ferramenta em ambos os ambientes (Ubuntu e Rocky Linux). Siga cada passo na ordem apresentada.

Comece verificando se o serviço está em execução e se o arquivo de configuração foi carregado sem erros de sintaxe. O comando abaixo exibe o status completo do daemon, incluindo o caminho do arquivo de configuração utilizado e o PID do processo:

# Verifica status detalhado do serviço denyhosts
sudo systemctl status denyhosts --no-pager -l

# Verifica se há erros de sintaxe no arquivo de configuração
# (o denyhosts não possui uma flag --check-config nativa,
# mas podemos iniciar em foreground para ver erros)
sudo denyhosts --config=/etc/denyhosts.conf --foreground --verbose 2>&1 | head -50

INFO     DenyHosts version: 3.0
INFO     Using config file: /etc/denyhosts.conf
INFO     Loaded 5,234 previously denied hosts
INFO     Monitoring log: /var/log/auth.log
INFO     Sync mode: enabled, server: http://10.0.0.100/denyhosts/sync.php
INFO     Daemon running, sleep interval: 30 seconds
INFO     Purge interval: 1 day

A saída acima confirma que o DenyHosts está rodando a versão 3.0, carregou mais de 5 mil IPs previamente bloqueados do banco de dados interno, está monitorando o arquivo correto, e o modo de sincronização está ativo. Verifique agora o arquivo de log do próprio DenyHosts para ver as ações recentes:

# Exibe as últimas 20 linhas do log do denyhosts
sudo tail -n 20 /var/log/denyhosts

2026-07-09 10:30:01,234 - denyhosts     : INFO     new denied hosts: ['203.0.113.77', '198.51.100.23']
2026-07-09 10:30:01,238 - denyhosts     : INFO     added 2 new hosts to /etc/hosts.deny
2026-07-09 10:30:01,240 - denyhosts     : INFO     sync: uploaded 2 hosts to server
2026-07-09 10:30:01,245 - denyhosts     : INFO     sync: downloaded 18 hosts from server
2026-07-09 10:30:01,248 - denyhosts     : INFO     sync: added 15 new hosts from server
2026-07-09 10:35:01,101 - denyhosts     : INFO     daemon is sleeping for 30 seconds
2026-07-09 10:35:31,102 - denyhosts     : INFO     polling /var/log/auth.log for new entries
2026-07-09 10:35:31,105 - denyhosts     : INFO     no new denied hosts found

Para testar efetivamente o bloqueio, simule tentativas de login mal-sucedidas a partir de um IP externo (por exemplo, uma máquina na mesma rede mas não listada na whitelist). Execute o seguinte a partir de uma máquina cliente diferente:

# A partir de uma máquina externa (IP 192.168.100.50, por exemplo)
# Execute este loop para simular múltiplas tentativas de login com usuário inválido:
for i in $(seq 1 6); do
  ssh fakeuser@10.0.0.11 -o ConnectTimeout=2 -o StrictHostKeyChecking=no 2>&1 | grep -i denied
  sleep 1
done

No servidor onde o DenyHosts está rodando, verifique imediatamente se o IP foi bloqueado consultando o arquivo /etc/hosts.deny:

# Verifica se o IP do atacante foi adicionado
grep "192.168.100.50" /etc/hosts.deny

sshd: 192.168.100.50

A presença da linha sshd: 192.168.100.50 confirma que o DenyHosts detectou as 6 tentativas (threshold de 5 para usuário inválido foi excedido) e bloqueou o IP com sucesso. A partir deste momento, qualquer nova tentativa de conexão SSH desse IP será rejeitada imediatamente pelo wrapper TCP, antes mesmo de o sshd processar a requisição.

Erros comuns e como resolver

Durante a implantação do DenyHosts em ambientes de produção, seja nos servidores que gerenciamos na JRT Technology Solutions ou em laboratórios de treinamento, encontramos recorrentemente alguns problemas que podem impedir o funcionamento correto da ferramenta. Abaixo listamos os quatro erros mais frequentes, seus sintomas, causas raiz e soluções detalhadas para que você possa diagnosticá-los e corrigi-los rapidamente.

• Erro 1: Serviço denyhosts falha ao iniciar com "Permission denied" no arquivo de log.
  • Sintoma: O systemd reporta falha (failed) e o log /var/log/denyhosts mostra IOError: [Errno 13] Permission denied: '/var/log/denyhosts'.
  • Causa: O usuário sob o qual o DenyHosts executa (geralmente root ou denyhosts, dependendo da distribuição) não tem permissão de escrita no diretório de logs. Isso ocorre frequentemente quando o pacote é instalado mas as permissões não foram ajustadas automaticamente.
  • Solução: Crie o arquivo de log e ajuste as permissões:

    sudo touch /var/log/denyhosts
    sudo chown root:adm /var/log/denyhosts
    sudo chmod 640 /var/log/denyhosts
    sudo systemctl restart denyhosts

• Erro 2: IPs legítimos sendo bloqueados repetidamente após configuração da whitelist.
  • Sintoma: Administradores reportam perda de acesso SSH, mesmo com seus IPs listados em /var/lib/denyhosts/allowed-hosts.
  • Causa: O DenyHosts não está encontrando o arquivo de whitelist porque o caminho configurado em ALLOWED_HOSTS não confere com a localização real, ou há erros de formatação (espaços extras, linhas em branco mal interpretadas, faixas CIDR incorretas como "192.168.1.0/24" quando deveria ser "192.168.1.*").
  • Solução: Verifique o caminho exato em /etc/denyhosts.conf:

    grep ALLOWED_HOSTS /etc/denyhosts.conf

    Confirme que o arquivo referenciado existe e contém os IPs corretos. Teste com um IP simples (sem faixa) antes de usar CIDR. Remova entradas já bloqueadas do /etc/hosts.deny com sudo sed -i '/IP_LEGITIMO/d' /etc/hosts.deny e reinicie o daemon.

• Erro 3: Sincronização falha com "Connection refused" no servidor central.
  • Sintoma: O log do DenyHosts mostra ERROR sync: [Errno 111] Connection refused ao tentar conectar ao SYNC_SERVER_URL.
  • Causa: O servidor Apache no servidor central não está em execução, o firewall está bloqueando a porta 80, ou o caminho do script PHP está incorreto (erro 404).
  • Solução: No servidor central, verifique se o Apache está ativo com sudo systemctl status apache2 (ou httpd) e se o firewall permite tráfego HTTP na interface de gerenciamento. Teste a conectividade com curl -X GET http://10.0.0.100/denyhosts/sync.php a partir de um cliente — deve retornar a lista de hosts ou "# No hosts blocked yet". Se retornar 404, verifique o caminho do arquivo no DocumentRoot.
• Erro 4: Arquivo /etc/hosts.deny crescendo indefinidamente com entradas duplicadas.
  • Sintoma: O /etc/hosts.deny atinge milhares de linhas, muitas repetidas para o mesmo IP, causando lentidão nas consultas de wrapper.
  • Causa: O parâmetro HOSTS_DENY_CLEANUP está configurado como NO ou não está presente no arquivo, e o daemon nunca remove entradas expiradas. Além disso, bugs em versões antigas do DenyHosts podiam levar à inserção duplicada.
  • Solução: Garanta que HOSTS_DENY_CLEANUP = YES esteja presente e ativo no /etc/denyhosts.conf. Para limpar duplicatas existentes, execute:

    sudo sort -u /etc/hosts.deny -o /etc/hosts.deny

    Isso remove duplicatas mantendo a ordem. Em seguida, reinicie o serviço.

Boas práticas e dicas avançadas para ambientes com DenyHosts

Operar o DenyHosts em ambientes de produção exige mais do que simplesmente instalar e configurar — é necessário adotar práticas que garantam a confiabilidade da ferramenta a longo prazo, minimizem falsos positivos e se integrem com as rotinas de monitoramento da organização. Nos projetos que conduzimos na JRT Technology Solutions, estabelecemos um conjunto de diretrizes que elevaram a maturidade do uso do DenyHosts de uma ferramenta básica para um componente estratégico da postura de segurança.

A primeira recomendação fundamental é integrar os logs do DenyHosts a um sistema centralizado de monitoramento e alertas, como Graylog, ELK Stack (Elasticsearch, Logstash, Kibana) ou Splunk. O arquivo /var/log/denyhosts contém informações valiosas não apenas sobre bloqueios realizados, mas também sobre padrões de ataque — horários de pico de tentativas de força bruta, países de origem mais frequentes (quando combinado com geolocalização de IP), e taxas de reincidência. Configure um agente de coleta (Filebeat, por exemplo) para enviar esses logs ao seu SI