Percio Castelo.
EN Início
Proteja servidores HestiaCP com lista de ipset
← Voltar para blog

Proteja servidores HestiaCP com lista de ipset

Atualizado em 19/09/2026 · Publicado em 07/06/2026 · 7 min · Infraestrutura · 528 visualizações

O HestiaCP, combinado com os daemons Fail2ban e Iptables, oferece uma base sólida para a defesa e endurecimento (hardening) de servidores Linux. Contudo, gerenciar milhares de regras individuais no Iptables gera gargalo de CPU e latência de rede. É aqui que o IPset se torna indispensável: ele gerencia listas dinâmicas de IPs na memória do kernel (estruturas hash super rápidas), permitindo bloqueios volumétricos eficientes com baixo overhead de hardware.

Neste artigo, estruturo a verificação de pré-requisitos, backups obrigatórios das regras do firewall, criação de whitelists para mitigar lockouts acidentais, auditorias sintáticas de scripts e procedimentos sistemáticos de monitoramento e rollback.


1) Verificação de pré-requisitos do sistema#

Antes de iniciar as configurações e agendar tarefas automatizadas no HestiaCP, garanta que todas as dependências e binários necessários estejam instalados no sistema e que o painel esteja operacional:

# 1. Verificar se o utilitário IPset está instalado e qual sua versão
which ipset
ipset --version

# 2. Verificar se o Fail2ban está instalado e respondendo
which fail2ban-client
fail2ban-client --version

# 3. Validar se o HestiaCP está ativo e rodando (o nome do serviço pode ser hestia, hestia-web ou hestiacp)
systemctl list-units --type=service | grep -i hestia
# E verificar o status do serviço específico encontrado (ex: hestia)
systemctl status hestia

# 4. Verificar se o script nativo de blacklist do HestiaCP está no local correto
ls -la /usr/local/hestia/install/common/firewall/ipset/blacklist.sh

2) Backup preventivo obrigatório do firewall#

Qualquer modificação na tabela de roteamento e regras de firewall ativa o risco de lockout (perda de acesso ao console). Realize o backup com carimbo de data (timestamp) de todas as regras atuais do Iptables e tabelas do IPset:

# 1. Exportar e fazer backup de todas as regras vigentes do Iptables
iptables-save > /root/iptables-backup-$(date +%Y%m%d).rules

# 2. Fazer backup da configuração e listagem atual do IPset
ipset list > /root/ipset-backup-$(date +%Y%m%d).txt

# 3. Opcional: Se utilizando CSF (ConfigServer Security & Firewall) em paralelo, faça backup do diretório
tar czf /root/csf-backup-$(date +%Y%m%d).tar.gz /etc/csf/

3) Whitelist de IPs (prevenção de lockouts)#

Para evitar que administradores, integradores e ferramentas de monitoramento confiáveis sejam bloqueados pelas listas globais de spam ou reputação, crie um set exclusivo de whitelist e defina uma regra prioritária que aceite as requisições antes do bloco de rejeições:

# 1. Criar o set de whitelist na memória do kernel (tipo hash:net para suportar IPs individuais e sub-redes CIDR)
ipset create WHITELIST hash:net

# 2. Adicionar os IPs e sub-redes de confiança na lista
ipset add WHITELIST 10.0.0.1
ipset add WHITELIST 192.168.1.0/24
# Opcional: Adicione seu próprio IP público dinâmico (caso seja fixo)
# ipset add WHITELIST 203.0.113.50
AVISO DE LOCKOUT: Certifique-se de validar se o seu próprio IP público atual (ou o IP da sua VPN/Monitoramento) está adicionado à WHITELIST antes de configurar qualquer bloqueio. Mantenha sempre uma sessão SSH de backup aberta em paralelo para não perder o acesso ao servidor.
# 3. Criar a regra de aceitação prioritária no Iptables (inserida no topo da chain)
iptables -I INPUT -m set --match-set WHITELIST src -j ACCEPT

Tabela Comparativa: Regras Lineares do Iptables vs Tabelas Hash do IPset#

RecursoIptables Puro (Regras Lineares)IPset Integrado ao HestiaCP
Complexidade de Busca$O(N)$ — Avalia cada regra sequencialmente pacote por pacote$O(1)$ — Busca instantânea indexada por tabela hash
Consumo de CPU com 20k IPsAlto (Gargalo em pacotes de rede e interrupções de hardware)Mínimo (Processamento ultra-leve no kernel space)
Tempo de Reload / InicializaçãoSegundos a minutos recriando milhares de chainsInstantâneo via ipset restore atômico
Risco de Lockout AdministrativoAlto se uma regra geral preceder o SSHBaixo quando combinado com chain WHITELIST prioritária
Recomendação OperacionalApenas para regras específicas de portas ou políticas locaisPadrão ouro para blacklists volumétricas e feeds de reputação

4) Validação do script de blacklist do HestiaCP#

O HestiaCP traz um script utilitário projetado para coletar bases públicas de IPs maliciosos. Certifique-se de validar sua integridade e permissões de execução antes de agendá-lo no cron:

# 1. Garantir que o script possui permissões de execução para o root
chmod +x /usr/local/hestia/install/common/firewall/ipset/blacklist.sh

# 2. Testar a análise sintática do script (Dry Run de compilação do bash)
bash -n /usr/local/hestia/install/common/firewall/ipset/blacklist.sh

# 3. Executar em modo verbose para diagnóstico de download e processamento de IPs
sudo bash -x /usr/local/hestia/install/common/firewall/ipset/blacklist.sh 2>&1 | head -n 50

# 4. Executar o script manualmente em primeiro plano para carregar as listas iniciais
sudo /usr/local/hestia/install/common/firewall/ipset/blacklist.sh

Esse script integra diversas fontes de feeds públicos e de reputação cibernética, livre de placeholders:


5) Cadastro das listas no HestiaCP#

No painel administrativo HestiaCP, gerencie a integração do IPset de forma visual:

  1. Acesse Configurações do Servidor (ícone de engrenagem).
  2. Vá até a aba Firewall.
  3. Clique em Listas de IP Set.
  4. Selecione Adicionar lista de IP.

Preencha as opções conforme a tabela de homologação:

  • Nome: BLOCK-LIST
  • Fonte de dados: Selecione a lista de IPs maliciosos ou confirme o seletor da sua versão do HestiaCP (versões recentes utilizam url: para feeds remotos; se a opção script: não estiver disponível, cadastre a lista via URL direta dos feeds da seção 4). Valide a presença do binário canônico de atualização de ipset com: ls -la /usr/local/hestia/bin/v-update-firewall-ipset.
  • Versão IP: IPv4
  • Atualização Automática: Sim

6) Configuração das regras do firewall HestiaCP#

Fluxo de bloqueio ipset + HestiaCP#

┌────────────────────────── KERNEL ──────────────────────────┐
│                                                            │
│   IPSET BLOCK-LIST ──match──▶ iptables INPUT               │
│     (hash:ip)                      │  DROP / REJECT        │
│                                    ▼                       │
│   Pacote malicioso ◀── descartado ◀┘                       │
└────────────────────────────────────────────────────────────┘
    ▲ alimenta           ▲ ban dinâmico          ▲ regras DROP/REJECT
    │                    │                      │
  blacklist.sh        Fail2ban          HestiaCP Firewall UI
    ▲
    │ gatilho — cron diário 03:00

Crie regras específicas para associar a lista IPset às ações de bloqueio no HestiaCP:

Regra 1: Negar tráfego TCP (entrada)#

  • Ação: REJECT
  • Protocolo: TCP
  • Porta: 0 (aplica-se a todas as portas)
  • Endereço: ipset:BLOCK-LIST
  • Comentário: DROP_BAD_TCP

Regra 2: Negar tráfego UDP (entrada/saída)#

  • Ação: DROP
  • Protocolo: UDP
  • Porta: 0
  • Endereço: ipset:BLOCK-LIST
  • Comentário: DROP_BAD_UDP

(Nota: O uso de DROP para UDP e ICMP é a prática de segurança recomendada em vez de REJECT, pois evita o envio de mensagens ICMP Port Unreachable de volta ao remetente, o que revelaria a existência do host).

Regra 3: Negar pacotes ICMP (ping)#

  • Ação: DROP
  • Protocolo: ICMP
  • Porta: 0
  • Endereço: ipset:BLOCK-LIST
  • Comentário: DROP_BAD_ICMP

7) Verificação pós-configuração e homologação#

Após criar a lista e cadastrar as regras no HestiaCP, realize a validação operacional para certificar que o bloqueio está sendo processado pelo kernel:

# 1. Verificar se a lista IPset BLOCK-LIST foi de fato criada
ipset list BLOCK-LIST | head -n 10

# 2. Contar a quantidade total de IPs carregados na lista (evitando cabeçalhos)
ipset save BLOCK-LIST | grep -c "^add "
# Ou
ipset list BLOCK-LIST -o save | grep "^add" | wc -l

# 3. Auditar a vinculação da tabela IPset nas regras do Iptables
iptables-save | grep -- "-m set --match-set"
# Ou, na saída human-readable
iptables -L -n | grep -E "set (BLOCK-LIST|WHITELIST)"

# 4. Adicionar um IP de teste temporário para simular um bloqueio
ipset add BLOCK-LIST 192.0.2.1

# 5. Confirmar se o IP de teste consta na lista ativa
ipset test BLOCK-LIST 192.0.2.1

8) Atualização das listas ipset via cron#

As listas de IPs maliciosos mudam constantemente. Para garantir que as atualizações ocorram em segundo plano, configure um agendamento do cron job:

# Executar a atualização manualmente para teste
sudo /usr/local/hestia/install/common/firewall/ipset/blacklist.sh

# Adicionar a tarefa no cron do root (ex: atualiza diariamente às 3:00 da manhã)
# Use o 'flock' para evitar execuções concorrentes se o download das listas demorar ou falhar
# 0 3 * * * /usr/bin/flock -n /var/run/blacklist-ipset.lock /usr/local/hestia/install/common/firewall/ipset/blacklist.sh > /dev/null 2>&1

### 8-b) persistência do ipset pós-reboot

Por padrão, as tabelas do IPset ficam salvas apenas na memória do kernel e são perdidas no reboot. Para torná-las persistentes, salve as regras e crie um script ou serviço systemd de restauração:

Salvar os sets atuais para um arquivo de regras#

ipset save > /etc/ipset.rules


Crie o arquivo `/etc/systemd/system/ipset-restore.service`:

[Unit] Description=Restaurar Regras do IPset no Boot Before=network.target

[Service] Type=oneshot ExecStart=/sbin/ipset restore -f /etc/ipset.rules ExecStop=/sbin/ipset save -f /etc/ipset.rules RemainAfterExit=yes

[Install] WantedBy=multi-user.target


Ative o serviço:

systemctl daemon-reload systemctl enable ipset-restore.service


9) Monitoramento do ipset e Fail2ban#

Implemente monitoramento para garantir a integridade dos sets. A indisponibilidade de rede ou falha de escrita pode corromper as atualizações:

# 1. Verificar jails e status do Fail2ban
fail2ban-client status
fail2ban-client status sshd

# 2. Verificar IPs banidos ativamente no jail sshd
fail2ban-client status sshd | grep -i "banned"

# 3. Monitorar logs do Fail2ban em tempo real
tail -n 100 /var/log/fail2ban.log

Script de monitoramento de integridade (monitor-ipset.sh)#

Crie este script em /usr/local/sbin/monitor-ipset.sh para auditar periodicamente o tamanho da sua lista, verificando se o set existe e contando os IPs de forma correta:

monitor-ipset.sh — Script de monitoramento de integridade da lista
GistVer código
#!/bin/bash
# monitor-ipset.sh - Verifica o tamanho mínimo da lista de bloqueio
SET_NAME="${1:-BLOCK-LIST}"
MIN_IPS="${2:-100}"

if ! ipset list "$SET_NAME" >/dev/null 2>&1; then
    MSG="CRITICAL: IPset $SET_NAME não existe!"
    logger -t monitor-ipset "$MSG"
    which mail >/dev/null 2>&1 && echo "$MSG" | mail -s "Alerta de Seguranca: IPset" [email protected]
    exit 2
fi

# Contar apenas as entradas add (desconsiderando o cabeçalho)
COUNT=$(ipset save "$SET_NAME" | grep -c "^add ")

if [ "$COUNT" -lt "$MIN_IPS" ]; then
    MSG="ALERTA: A lista IPset $SET_NAME está anormalmente pequena: $COUNT IPs carregados."
    logger -t monitor-ipset "$MSG"
    which mail >/dev/null 2>&1 && echo "$MSG" | mail -s "Alerta de Seguranca: IPset" [email protected]
    exit 1
else
    echo "OK: IPset $SET_NAME operando normalmente com $COUNT IPs."
    exit 0
fi

(Nota: O envio de alertas por e-mail via terminal requer o pacote mailutils: sudo apt install mailutils).


10) Procedimento de rollback e contingência#

Em caso de indisponibilidade ou travamento de acessos legítimos devido às listas, execute a remoção rápida das regras e o restabelecimento do Iptables:

# 1. Remover a vinculação da lista no Iptables (Exclui as regras de Drop/Reject baseadas na lista)
iptables -D INPUT -m set --match-set BLOCK-LIST src -j DROP 2>/dev/null
iptables -D INPUT -m set --match-set BLOCK-LIST src -j REJECT 2>/dev/null

# 2. Destruir os sets de IPset criados para limpar a memória do kernel
ipset destroy BLOCK-LIST
ipset destroy WHITELIST

# 3. Restaurar as regras de firewall padrão a partir do backup preventivo mais recente
RESTORE_FILE=$(ls -t /root/iptables-backup-*.rules | head -1)
echo "Restaurando: $RESTORE_FILE"
iptables-restore < "$RESTORE_FILE"

11) Diagnóstico dinâmico através dos arquivos de log#

Caso ocorram problemas de rede ou erros na sincronização de pacotes do HestiaCP, consulte os arquivos de logs:

  • Logs do IPset e Systemd:

journalctl --since "1 hour ago" | grep -i "ipset"

  • Logs de Bloqueio do Iptables/Kernel:

journalctl -k --since "1 hour ago" | grep -i -E "DROP|REJECT" (ou tail -100 /var/log/messages | grep -i -E "DROP|REJECT" em distribuições com syslog tradicional)

  • Logs do HestiaCP (Erros do sistema de firewall):

tail -100 /usr/local/hestia/log/system.log


Checklist: ipset no HestiaCP#

Utilize este roteiro de auditoria e validação técnica em novos setups HestiaCP:

  • [ ] Pré-requisitos: IPset, Fail2ban e arquivo blacklist.sh validados no servidor.
  • [ ] Backups: Backup do Iptables (iptables-save) e listagens vigentes do IPset efetuados.
  • [ ] Prevenção: Whitelist com IPs administrativos criada no IPset (tipo hash:net) e cadastrada no painel.
  • [ ] Execução: Script blacklist.sh analisado sintaticamente com bash -n e executado manualmente com sucesso.
  • [ ] Cadastro: Lista cadastrada no HestiaCP mapeando BLOCK-LIST com atualização automática.
  • [ ] Regras: Regras de bloqueio TCP, UDP e ICMP configuradas com ações REJECT (TCP) e DROP (UDP/ICMP) no painel.
  • [ ] Sincronismo: Tarefa de sincronismo automático ativada e cron configurado às 3:00h.
  • [ ] Monitoramento: Logs monitorados e script de tamanho mínimo da lista (monitor-ipset.sh) operacional.
  • [ ] Contingência: Runbook de rollback documentado e acessível.

Perguntas Frequentes (FAQ de Troubleshooting)#

O que fazer se eu for bloqueado acidentalmente pelo IPset no HestiaCP?#

Acesse o servidor pelo console de emergência da sua nuvem/VPS (VNC ou serial console do provedor). Execute ipset flush BLOCK-LIST para esvaziar imediatamente a tabela em memória, ou reinicie as regras com v-stop-firewall para derrubar temporariamente o bloqueio e adicionar o seu IP à whitelist.

Por que o comando iptables -L fica extremamente lento com listas de IPset?#

O comando iptables -L tenta resolver o DNS reverso de cada endereço IP listado por padrão. Utilize sempre iptables -L -n (ou iptables -S) com o parâmetro -n (numérico) para desabilitar a resolução reversa e obter a saída instantânea.

Como garantir que as listas do IPset persistam após o reboot do servidor?#

O HestiaCP inclui rotinas no boot para restaurar o firewall. Para garantir persistência nativa em nível de sistema operacional no Debian ou Ubuntu, instale o pacote ipset-persistent ou netfilter-persistent com suporte ao plugin do ipset (netfilter-persistent save).


Conclusão#

Proteger servidores HestiaCP com IPset combina a eficiência do processamento em hash no kernel com a facilidade de gerenciamento visual do painel. Neste guia estruturei a prevenção contra lockouts com a WHITELIST em hash:net, a automação de feeds de segurança sem sobrecarga de CPU e o procedimento seguro de rollback. Com a persistência configurada via systemd e o monitoramento periódico ativo, o servidor se mantém protegido contra milhares de ameaças diárias com baixo uso de hardware e máxima estabilidade.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

528 leituras
Creative Commons Atribuição-NãoComercial

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.

0 comentários