O que é o Reaction e por que o FSF o usa

A Free Software Foundation (FSF) publicou em julho de 2026 um artigo detalhando como seus administradores de sistema combatem botnets usando uma ferramenta chamada Reaction. O nome pode ser desconhecido, mas o conceito e familiar: monitora logs em tempo real e bloqueia automaticamente IPs que apresentam comportamento suspeito.

O Reaction e uma alternativa moderna ao clássico Fail2Ban, escrita em Go. A proposta e ser mais rápida, mais simples de configurar e consumir menos recursos. O FSF adotou porque seus servidores lidam com ataques constantes de botnets tentando forcas brutas em SSH, SMTP e serviços web.

A publicação do FSF e interessante porque vai além do básico: mostra configurações reais, decisões de arquitetura e o racional por trás de cada escolha. E um caso de uso real, em produção, em uma organização que valoriza software livre e transparência.

💡
Dica

O Reaction e open source (licença Apache 2.0) e disponível no GitHub. Funciona em qualquer distribuição Linux moderna com suporte a systemd.

Como o Reaction funciona

O mecanismo central do Reaction e simples: ele observa arquivos de log ou streams de eventos via journald, aplica expressões regulares para identificar padrões de ataque, e quando um IP ultrapassa um limiar configurado, executa uma ação - normalmente adicionar o IP em uma regra de iptables ou nftables para bloquear o tráfego.

A diferença em relação ao Fail2Ban esta na implementação. O Reaction e um binário único em Go, sem dependências Python, com um ciclo de processamento de logs mais eficiente. Em servidores com alta taxa de tentativas de ataque, a diferença de uso de CPU e memoria e perceptivel.

Outro diferencial e a configuração declarativa em YAML. Cada serviço (SSH, NGINX, Postfix, etc.) tem um arquivo de configuração separado que define: quais logs monitorar, quais padrões indicam ataque, quantas tentativas antes do bloqueio, e por quanto tempo bloquear. Isso torna a configuração auditavel e versionavel no Git.

⚠️
Atenção

O Reaction precisa de privilégios root para modificar regras de firewall. Sempre revise as expressões regulares dos seus filtros em ambiente de teste antes de ativar em produção - um regex mal escrito pode bloquear tráfego legítimo.

Principais recursos do Reaction

O conjunto de funcionalidades do Reaction cobre os casos de uso mais comuns em segurança de servidores:

  • Monitoramento via journald: integração nativa com o sistema de logs do systemd, sem precisar parsear arquivos de texto diretamente
  • Múltiplos backends de firewall: suporte a iptables, nftables e ipset para maior flexibilidade
  • Configuração por serviço: filtros separados para SSH, HTTP, SMTP, FTP e qualquer serviço com logs
  • Whitelist permanente: IPs ou subredes que nunca serão bloqueados (seu próprio IP, rede interna)
  • Desbloqueio automático: IPs são liberados após o tempo configurado, evitando banimentos permanentes acidentais
  • Métricas e status: comando de status mostra IPs bloqueados, contagem de eventos e configuração ativa

O FSF destaca especialmente a integração com journald como vantagem sobre o Fail2Ban, que exige configuração adicional para esse mesmo nível de integração.

Como começar: instalação e configuração básica

O Reaction não esta nos repositórios oficiais das distribuições principais, então a instalação e via binário pre-compilado ou compilação a partir do código fonte.

Passo 1: Baixe o binário para Linux x86_64 a partir do GitHub:

# Baixar o binário mais recente
curl -L https://GitHub.com/firefly-zero/reaction/releases/latest/download/reaction-Linux-amd64 -o /usr/local/bin/reaction
chmod +x /usr/local/bin/reaction

# Verificar instalação
reaction --version

Passo 2: Crie o diretório de configuração e um filtro para SSH:

mkdir -p /etc/reaction/filters

# Criar filtro para SSH (/etc/reaction/filters/sshd.yaml)
cat > /etc/reaction/filters/sshd.yaml << EOF
name: sshd
regexes:
  - pattern: 'Failed password for .* from (?P[\d.]+)'
threshold: 5
window: 60s
ban_time: 3600s
EOF

Passo 3: Configure o serviço systemd e inicie:

# Criar serviço systemd (/etc/systemd/system/reaction.service)
[Unit]
Description=Reaction - Intrusion Prevention System
After=network.target

[Service]
ExecStart=/usr/local/bin/reaction -config /etc/reaction
Restart=always

[Install]
WantedBy=multi-user.target

# Ativar e iniciar
systemctl daemon-reload
systemctl enable --now reaction

Passo 4: Verifique o status e IPs bloqueados:

reaction status
reaction list-bans

Exemplo prático: configuração real do FSF

O artigo do FSF detalha como eles estruturam os filtros para diferentes serviços. Para o servidor SSH, o filtro detecta tentativas de login com senha incorreta e bloqueia o IP após 5 falhas em 60 segundos por 1 hora.

Para o servidor web NGINX, o filtro e diferente: detecta requisições a rotas suspeitas (scanners de vulnerabilidade que tentam acessar /wp-admin, /phpmyadmin, etc.) e bloqueia imediatamente após 3 tentativas em 30 segundos por 24 horas.

# Filtro NGINX para scanners (/etc/reaction/filters/nginx-scanner.yaml)
name: nginx-scanner
regexes:
  - pattern: '(?P[\d.]+) .* "(GET|POST) /(wp-admin|phpmyadmin|.env|admin).*'
threshold: 3
window: 30s
ban_time: 86400s  # 24 horas

O FSF também menciona o uso de whitelist para IPs de monitoramento externo e para IPs dos próprios administradores, evitando o risco de se bloquear por acidente durante manutenção.

Comparação com alternativas

Fail2Ban: o padrão de mercado, disponível em todos os repositórios, amplamente documentado, mas escrito em Python com um daemon mais pesado. Para servidores com muito log, o Fail2Ban pode adicionar latência perceptivel no processamento. Configuração mais verbosa mas com mais recursos avançados.

CrowdSec: solução moderna com inteligência coletiva - compartilha reputação de IPs maliciosos entre usuários. Muito mais poderoso que Reaction, mas também muito mais complexo. Adequado para empresas que querem segurança de nível enterprise.

nftables puro com scripts: solução minimalista onde você escreve os scripts de monitoramento e bloqueio manualmente. Máximo controle, máximo trabalho. Para sysadmins avançados que preferem entender cada linha do que funciona no sistema.

O Reaction ocupa um nicho específico: mais simples que CrowdSec, mais eficiente que Fail2Ban, mais pronto que scripts manuais. Ideal para servidores pessoais, VPSs e pequenas empresas.

🚀
Pro tip

Combine o Reaction com o ipset para performance máxima em servidores com muitos IPs bloqueados. O ipset agrupa IPs em estruturas hash que o kernel do Linux verifica muito mais rápido do que regras individuais de iptables.

Pontos positivos e limitações

Os pontos positivos do Reaction são claros: binário único sem dependências, configuração declarativa em YAML, integração nativa com journald e baixo uso de recursos. Para quem já sofreu com o Fail2Ban travando em momentos de pico de ataque, isso faz diferença.

As limitações também existem. A documentação e menor que a do Fail2Ban, que tem anos de tutoriais e exemplos acumulados. O projeto e relativamente novo, então a comunidade e menor e suporte e mais limitado. Algumas distribuições mais antigas podem ter incompatibilidades com as versões de Go usadas na compilação.

Outro ponto: o Reaction e reativo por natureza. Ele bloqueia IPs depois que o ataque começa, não antes. Para uma camada de proteção proativa, combinar com listas de reputação de IP (como as do Spamhaus) ou com soluções como CrowdSec e recomendado.

Casos de uso reais

VPS pessoal com SSH exposto: se você tem um servidor na nuvem com acesso SSH pela porta padrão ou alternativa, os logs de autenticação mostram centenas ou milhares de tentativas por dia. O Reaction resolve isso automaticamente sem intervenção manual.

Servidor de e-mail (SMTP/IMAP): servidores de e-mail são alvos constantes de ataques de enumeração de usuários e tentativas de relay aberto. O Reaction monitora os logs do Postfix e Dovecot e bloqueia os atacantes antes que causem dano.

Servidor web com painel admin: qualquer servidor rodando WordPress, Laravel, Django ou similar recebe varreduras automáticas buscando painéis de administração. O Reaction pode bloquear esses scanners baseado nos padrões de URL.

Infraestrutura de pequena empresa: para empresas sem equipe de segurança dedicada, o Reaction oferece uma camada de proteção automatizada que roda sem intervenção e manda logs para análise posterior.

Dicas e boas práticas

💡
Dica

Sempre adicione seu próprio IP e a subnet da sua empresa na whitelist antes de ativar qualquer regra. Isso evita o pesadelo de se bloquear do próprio servidor durante uma configuração.

⚠️
Atenção

Teste as expressões regulares dos seus filtros com logs reais antes de ativar em produção. Um regex muito amplo pode bloquear usuários legítimos. Use o comando `reaction test-filter` para validar.

🚀
Pro tip

Versione suas configurações do Reaction no Git. Isso facilita auditoria, rollback em caso de problemas, e compartilhamento de filtros eficazes com sua equipe.

🔴
Cuidado

Não use ban_time muito longo (semanas ou permanente) sem ter certeza absoluta. IPs podem ser compartilhados (NAT corporativo, CGNAT de operadoras) e um banimento longo pode bloquear usuários legítimos que compartilham o IP com um atacante.

Vale a pena trocar o Fail2Ban pelo Reaction?

Se você já tem o Fail2Ban funcionando bem, não ha urgência em migrar. O Fail2Ban e estável, documentado e resolvido problema. A migração tem custo de tempo e risco de configuração incorreta.

Se você esta configurando proteção de botnet em um servidor novo, o Reaction e uma boa escolha: mais simples, mais rápido, configuração mais limpa. O artigo do FSF serve como referência prática e mostra que a ferramenta e madura o suficiente para ambientes de produção reais.

O próximo passo: leia o artigo original do FSF (linkado abaixo), depois instale o Reaction em um servidor de teste e configure o filtro de SSH. Em 30 minutos você vai ver os primeiros IPs sendo bloqueados automaticamente.