CrowdSec vs. Fail2Ban: diferenças na utilização prática

Entender corretamente o CrowdSec e o Fail2Ban

A escolha adequada não depende de qual a ferramenta considerada mais moderna, mas sim do servidor, dos dados de registo e do ponto de aplicação pretendido. Para um único serviço SSH com mensagens de erro claras, o Fail2Ban pode ser uma solução muito direta. O CrowdSec torna-se interessante quando é necessário avaliar e proteger em conjunto várias fontes de registos, diferentes níveis de proteção ou sistemas distribuídos.

Ambas as soluções servem para detecção de ataques baseada em registos: Detetam eventos relevantes para a segurança, como tentativas de início de sessão falhadas, classificam-nos de acordo com um padrão e podem bloquear um endereço IP. Para tal, o Fail2Ban combina filtros e ações em «jails». O CrowdSec processa os dados recolhidos através do seu motor de segurança e toma decisões, cuja implementação é assegurada por um componente de remediação separado.

O que é decisivo é o que é efetivamente registado. Sem carimbo de data/hora, um endereço IP de origem utilizável e uma fonte de registo adequada, nenhuma das ferramentas consegue atribuir um ataque de forma fiável. Além disso, um bloqueio só protege nos casos em que é tecnicamente aplicável: uma regra de firewall local não ajuda automaticamente se o tráfego de dados passar primeiro por um proxy reverso externo ou por um balanceador de carga.

Como Prevenção de intrusões Ambas as ferramentas complementam uma arquitetura de segurança, mas não a substituem. As atualizações de segurança corrigem vulnerabilidades conhecidas; um processo de início de sessão robusto e, na medida do possível, em várias etapas, limita o uso indevido de contas; e regras de base restritivas da firewall reduzem os serviços acessíveis. As cópias de segurança limitam os danos após um incidente, enquanto a monitorização contínua dos registos também revela problemas que não acionam um bloqueio.

A questão prática é, portanto: que padrões devem ser detetados, em que ponto deve ocorrer a reação e quem é responsável pela gestão das regras, exceções e registos? Só depois disso é possível decidir, com fundamento, se basta uma configuração local e simples de «jail» ou se os componentes separados do CrowdSec trazem um benefício adicional reconhecível para a infraestrutura.

Como o Fail2Ban associa as «jails» às ações

O Fail2Ban organiza a deteção e a resposta em Prisões. No SSH, por exemplo, um «jail» lê os protocolos de autenticação ou o registo do sistema. Um filtro procura nesses registos tentativas de início de sessão falhadas provenientes de um endereço IP de origem. Se, dentro do intervalo de tempo configurado, esse endereço ultrapassar o número permitido de tentativas falhadas, o Fail2Ban considera essa ocorrência como um caso de bloqueio.

A ação subsequente determina a reação. Frequentemente, complementa uma regra na firewall local, mas também são possíveis outras ações configuradas. Desta forma, a cadeia é compreensível: a fonte de registo fornece linhas, o filtro identifica eventos relevantes, a «jail» conta-os e a ação implementa a contramedida prevista. Isto facilita a deteção de erros, desde que o formato do registo e o filtro sejam compatíveis.

Um «jail» utiliza exatamente um filtro, mas pode executar várias ações. Assim, o mesmo caso de bloqueio de SSH detetado pode, por exemplo, desencadear uma ação do firewall e, além disso, gerar uma notificação. A existência de várias ações torna a reação mais flexível, mas não altera a base da deteção: todas dependem do mesmo filtro e da sua interpretação das linhas de registo.

Os textos escritos por nós próprios requerem um cuidado especial Filtro Regex. A documentação disponível sobre os filtros constitui expressamente um guia de desenvolvimento para o Fail2Ban 0.9.0.dev e não uma prova de funcionalidade para uma determinada versão estável do pacote. As suas orientações gerais continuam a ser úteis para o desenvolvimento de filtros: é necessário abranger variantes reais de formatos de registo, ao mesmo tempo que os padrões não devem ser demasiado abrangentes. Por conseguinte, os novos filtros devem ser testados inicialmente com linhas de exemplo anonimizadas, antes de ativarem bloqueios.

As alterações locais devem, em princípio, ser feitas em ficheiros com a extensão .local, e não nos entregues .conf-ficheiros. Desta forma, os valores personalizados relativos aos caminhos de registo, redes autorizadas ou ações mantêm-se mais fáceis de acompanhar nas atualizações de pacotes e não são simplesmente substituídos. Antes da implementação, deve também verificar-se se a fonte de registo selecionada existe efetivamente e se contém os eventos esperados.

O percurso da CrowdSec, desde o registo até ao bloqueio

O CrowdSec separa de forma mais clara a deteção e a aplicação em componentes individuais. Em primeiro lugar, as fontes de aquisição definem quais os registos ou fluxos de eventos que são lidos. Os analisadores normalizam esses dados; em seguida, os cenários avaliam padrões e comportamentos. Caso seja detetado um padrão correspondente, é gerado um alerta. Com base nos perfis configurados, a API local pode, a partir daí, tomar uma decisão, como, por exemplo, um bloqueio de IP temporário.

Um breve exemplo ilustra o processo: os erros de autenticação de um serviço chegam ao motor através da aquisição. Os analisadores identificam campos como a hora, o serviço e o IP de origem; um cenário avalia as tentativas falhadas repetidas. O alerta gerado a partir disso é transmitido à API local, que pode criar uma decisão com base num perfil adequado. Só uma Componente de remediação aplica esta decisão no ponto de proteção previsto.

Este componente é tradicionalmente também designado por «Bouncer». Dependendo da variante, pode aplicar decisões, por exemplo, num firewall, num proxy reverso ou num servidor web. Por si só, o Security Engine deteta incidentes e gere alertas e decisões através da API local, mas não bloqueia o tráfego de dados. Sem um Remediation Component corretamente ligado, uma decisão gerada permanece apenas como uma informação, sem qualquer bloqueio ativo da rede ou da aplicação.

Na prática, esta separação permite distribuir a deteção e o bloqueio por diferentes pontos da infraestrutura. No entanto, aumenta o âmbito das operações: a fonte de registo, a ligação à API local, as autorizações e a atribuição do Bouncer têm de estar em sintonia. Especialmente no caso de vários serviços, é necessário verificar se o Remediation Component se encontra efetivamente a montante do serviço cujos acessos deve bloquear com base numa decisão.

É necessário distinguir entre os resultados de cenários locais e a opção Lista de bloqueados da comunidade. No caso de participação voluntária, é possível contribuir com sinais e obter decisões selecionadas relativas a atacantes já conhecidos. Trata-se de uma fonte preventiva adicional, mas não substitui a deteção local nem constitui uma garantia de deteção de atacantes novos ou discretos. A origem de uma decisão de bloqueio deve, por isso, permanecer rastreável durante o funcionamento.

Comparar as ferramentas consoante a situação de utilização

A escolha entre o CrowdSec e o Fail2Ban começa pelo aspeto da proteção, e não por uma avaliação geral da qualidade. O Fail2Ban analisa as linhas de registo através de filtros e associa-as a ações em «jails». O CrowdSec processa fontes de registo através de analisadores e cenários para gerar alertas; a API local pode, a partir daí, utilizar perfis para tomar decisões que são implementadas por componentes de correção independentes. Ambos dependem de eventos registados corretamente.

A tabela não é uma classificação. No caso de poucos padrões de registo bem compreendidos, é frequentemente mais fácil verificar uma «jail» local: a fonte do registo, o filtro e a ação do firewall estão próximos uns dos outros. Assim que estiverem envolvidas várias fontes, sistemas a montante ou diferentes pontos de aplicação, a separação entre deteção e reação no CrowdSec pode fazer sentido. No entanto, isso exige também que as relações entre os componentes sejam geridas de forma compreensível.

No que diz respeito ao critério de proteção web, o nível técnico é determinante. Um CrowdSec Firewall-Bouncer aplica decisões ao nível da rede, mas não analisa o conteúdo HTTP. Numa configuração de AppSec suportada, um Bouncer adequado para o efeito encaminha os pedidos HTTP para o componente AppSec do Security Engine, onde as regras de AppSec são avaliadas. Esta verificação complementa o desenvolvimento seguro e as atualizações atempadas, em vez de corrigir vulnerabilidades conhecidas.

Caso prático de um único VPS com SSH

Num pequeno VPS Linux com SSH e uma pilha web de dimensões reduzidas, o Fail2Ban é frequentemente uma opção fácil de gerir. Primeiro, verifica se as tentativas falhadas de início de sessão SSH, com data e hora e IP de origem, aparecem de forma fiável no registo ou diário previsto para o efeito. Sem estes dados, uma «jail» não consegue contabilizar as tentativas falhadas de forma fiável nem passar o endereço correto para uma ação.

Em seguida, escolhe uma «jail» SSH adequada e verifica os filtros, o intervalo de tempo, o número permitido de tentativas falhadas e a duração do bloqueio, de acordo com a tua própria realidade de início de sessão. Uma «jail» associa um filtro a uma ou mais ações. Desta forma, é possível, por exemplo, delegar o bloqueio ao firewall local, sem duplicar a lógica de deteção. Para um único anfitrião, esta associação torna o processo, na maioria das vezes, transparente.

As redes administrativas, os acessos de emergência e os sistemas de monitorização necessitam de exceções definidas de forma deliberada. Estas devem ser estritamente limitadas e não isentar de forma generalizada as grandes redes de fornecedores. Além disso, antes da implementação, verifica quais as regras de firewall que a ação cria efetivamente e se os protocolos IPv4 e IPv6 se enquadram no conceito do servidor. Um arranque controlado, com registos monitorizados, é mais seguro do que um bloqueio imediato e de longa duração.

Próprio Filtro Regex só fazem sentido quando não existe nenhum filtro que abranja o formato de registo específico. O guia disponível para o desenvolvimento de filtros está identificado como documentação do Fail2Ban 0.9.0.dev e, por isso, não faz parte de nenhuma versão estável, como a 1.1.1. No entanto, as suas orientações de desenvolvimento são úteis: teste novos padrões com linhas de exemplo reais anonimizadas e com linhas semelhantes, mas legítimas. A ferramenta de teste fail2ban-regex serve para a validação do filtro; não altera qualquer bloqueio de produção.

As configurações locais devem ser definidas em .local-ficheiros, não incluídos na entrega .conf-ficheiros. Desta forma, as alterações efetuadas nas atualizações de pacotes permanecem rastreáveis e não são sobrescritas acidentalmente. Após cada alteração, verifica separadamente a entrada no registo, o estado da «jail» e a ação desencadeada; um serviço em execução, por si só, ainda não constitui uma cadeia de bloqueio eficaz.

Proxies, IP real do cliente e proteção na Web

Uma CDN, um balanceador de carga ou um proxy reverso alteram o endereço que o servidor vê. Se o servidor Web receber apenas o IP do proxy e o registar como cliente, um bloqueio baseado em registos poderá, na pior das hipóteses, identificar o intermediário comum em vez do visitante invasor. Por isso, antes de cada restrição de acesso, cada cenário e cada regra do WAF, é necessário esclarecer como é que o IP original do cliente é transmitido, aceite e registado de forma fiável.

Esta cadeia de confiança não deve simplesmente aceitar qualquer cabeçalho recebido. Apenas endereços de proxy conhecidos devem estar autorizados a fornecer um endereço reenviado; caso contrário, os clientes externos poderiam falsificar a identidade, na qual se baseiam a deteção e o bloqueio. Verifique, através de excertos de registos anonimizados, se a aplicação e o registo de acesso apresentam o mesmo IP do cliente. Documente também a transmissão de cabeçalhos entre o Edge e o Origin. Só após a verificação do IP do cliente é que uma reação a eventos HTTP suspeitos pode ser interpretada de forma sensata.

A Bloqueio de IP limita as ligações ao nível do firewall antes de estas chegarem à aplicação, mas não verifica o conteúdo dos pedidos. Numa configuração CrowdSec AppSec suportada, um «bouncer» adequado reencaminha os pedidos HTTP para o componente AppSec do Security Engine; onde são verificadas as regras de AppSec adequadas. Por outro lado, um «Bouncer» que funciona exclusivamente como firewall aplica decisões ao nível da rede e não realiza qualquer verificação HTTP. A variante mais adequada depende do ponto de entrada efetivo do tráfego e dos componentes utilizados.

Além disso, a deteção baseada em registos é sempre retrospectiva: primeiro, é necessário que um evento ocorra, seja corretamente registado e reconhecido como um padrão. Não impede uma única exploração bem-sucedida sem um evento subsequente suspeito, nem substitui as correções de segurança e as autenticações fortes. Por isso, os componentes a montante têm de se integrar na arquitetura de segurança global com as suas transmissões fiáveis, registos e pontos de proteção.

Na prática, isto significa o seguinte: decida primeiro se o acesso à rede, a solicitação HTTP ou ambos os níveis devem ser protegidos. Em seguida, documente o percurso desde o endereço público, passando pelo proxy, até à entrada no registo e teste os bloqueios com um endereço de teste autorizado. Desta forma, evita que uma solução que aparentemente funciona Prevenção de intrusões apenas atinge o componente de infraestrutura errado.

Proteger vários servidores de forma controlada

Sempre que estão envolvidos vários hosts, contentores ou registos recolhidos centralmente, a separação entre deteção e aplicação de medidas no CrowdSec torna-se prática. O Security Engine pode analisar eventos provenientes de fontes definidas, enquanto os Remediation Components adequados implementam as decisões nos pontos protegidos em questão. Para tal, o CrowdSec também documenta implementações distribuídas e a integração, para além de pipelines de registos centralizados.

Isso não reduz automaticamente os custos operacionais. Em primeiro lugar, deve ser possível identificar, para cada fonte de registo, a que serviço e a que cliente está atribuída. Depois, cada «bouncer» necessita de uma ligação claramente delimitada à API local, bem como de uma chave de acesso própria. Um «bouncer» de proxy reverso, por exemplo, não protege necessariamente um serviço SSH acessível separadamente; o Atribuição de seguranças tem de seguir os percursos reais dos dados.

Para o funcionamento, a monitorização deve, portanto, incluir a gestão de tokens, a acessibilidade da API, os registos de eventos e de erros, bem como a verificação da eficácia do bloqueio. Uma decisão é apenas um resultado de deteção até que o componente previsto a recupere e a aplique. Em caso de alterações em contentores, proxies ou regras de firewall, esta cadeia deve ser novamente verificada, para que uma deteção funcional não passe despercebida sem uma reação eficaz.

Se já existirem cadeias e regras próprias, o Firewall-Bouncer pode, no Modo «Set-only» gerir exclusivamente conjuntos previamente criados. A responsabilidade pelas regras e cadeias permanece, então, deliberadamente a cargo do operador. Isto enquadra-se em conceitos de firewall controlados e requisitos de conformidade, mas exige compreensão da ordem das regras existentes e não constitui uma simplificação para principiantes.

Verificar sistematicamente os erros típicos

Caso não ocorra o bloqueio, seguir uma sequência de verificação fixa é mais útil do que uma mudança precipitada da ferramenta. Em primeiro lugar, é necessário esclarecer se o evento esperado chega de facto com carimbos de data/hora plausíveis. Em seguida, é preciso verificar se a morada registada corresponde efetivamente ao IP do cliente. Só então é possível verificar de forma adequada se o filtro ou o cenário reconhece o padrão e se daí resulta uma decisão de bloqueio.

No Fail2Ban, após a entrada do registo, segue-se a verificação da «jail», do filtro e da contagem de ocorrências. Uma «jail» associa um filtro a uma ou mais ações; no caso de percursos de registo baseados em ficheiros, no arranque apenas são considerados os ficheiros já existentes que correspondam ao padrão «glob». No caso dos diários do systemd, o backend e os direitos de acesso devem ser verificados separadamente. Uma «jail» que pareça correta não oferece proteção se não ler a fonte real.

As expressões regulares personalizadas merecem especial atenção. O guia de filtragem disponível está identificado como documentação de desenvolvimento para o Fail2Ban 0.9.0.dev e não deve ser interpretado como referência para a versão 1.1.1 do Fail2Ban. No entanto, a sua recomendação é útil para o desenvolvimento de filtros próprios: verifique primeiro os padrões com linhas de exemplo anónimas e representativas, bem como com linhas deliberadamente inadequadas. Desta forma, é possível identificar variações no formato dos registos e possíveis falhas de classificação antes de um bloqueio em ambiente de produção.

No CrowdSec, após uma correspondência com um cenário, é necessário verificar adicionalmente toda a cadeia de execução: se surgir um alerta, a API local pode gerar uma decisão com base num perfil e essa decisão chega ao componente de correção previsto? Sem um Bouncer corretamente ligado, a decisão fica por si só, sem um bloqueio ativo. Em seguida, é necessário verificar o funcionamento do firewall ou do proxy no ponto de entrada adequado, sem se bloquear o próprio acesso administrativo.

Manter a solução adequada a funcionar a longo prazo

O Fail2Ban é frequentemente adequado para um único servidor com padrões de registo locais bem definidos, como tentativas repetidas e falhadas de ligação via SSH. As suas «jails», filtros e ações podem ser aplicados diretamente a um serviço específico. O CrowdSec torna-se mais interessante quando é necessário coordenar várias fontes de registos, diferentes pontos de aplicação ou proteção web com um componente adequado. O que é decisivo é o percurso comprovável dos dados, e não um julgamento generalizado sobre qual é a ferramenta mais moderna.

Ambas as soluções requerem um processo de alteração regulamentado: controlar as versões das configurações, testar inicialmente novos filtros ou cenários com exemplos de registos conhecidos e monitorizar os bloqueios. As atualizações merecem a mesma atenção. O Fail2Ban 1.1.1 foi lançado a 15 de agosto de 2026. As adaptações locais e as ações de firewall efetivamente implementadas devem ser comparadas com o ambiente de destino antes de uma atualização.

Prevenção de intrusões complementa a base de segurança, mas não a substitui: atualizações atempadas, autenticação forte e, na medida do possível, em várias etapas, regras restritivas de firewall, cópias de segurança e monitorização de registos continuam a ser necessárias. Especialmente em ambientes de alojamento, o tempo de execução das aplicações também deve ser mantido. O artigo sobre O CloudLinux Alt-PHP e os seus aspetos de segurança mostra por que razão as versões de tempo de execução separadas e bem mantidas fazem parte de um modelo operacional robusto.

No caso dos serviços web, o percurso completo desde o cliente, passando pela CDN ou pelo proxy reverso, até à origem deve também constar na documentação operacional. As alterações nos protocolos e nas vias de entrega podem influenciar qual o componente que aceita as ligações e qual o endereço que aparece no registo. O artigo sobre HTTP/2 Server Push na hospedagem explica, através de exemplos, como o navegador, a CDN e o servidor web interagem durante a entrega do conteúdo. Independentemente disso, para a lógica de bloqueio, é fundamental que o endereço IP do cliente, transmitido de forma fiável, esteja disponível no ponto de proteção correto.

A escolha a longo prazo deve permanecer passível de revisão: se os formatos de registo, os percursos de proxy, os serviços ou o número de servidores se alterarem, um conceito que antes era adequado pode apresentar lacunas. Por isso, define quais os eventos que devem ser detetados, onde as decisões são aplicadas e quem aprova as exceções. Estes Disciplina no trabalho transforma um bloqueio de IP numa medida de proteção controlável, em vez de uma alteração no firewall que ocorre sem supervisão.