Alternativas ao Fail2Ban para servidores Linux modernos

Verificar a superfície de ataque antes de escolher a ferramenta

A Alternativa ao Fail2Ban só pode ser selecionado de forma adequada quando os serviços efetivamente acessíveis estiverem definidos. O SSH, o SMTP, o IMAP e uma aplicação HTTP têm processos de início de sessão, fontes de registo e padrões de danos diferentes. Por outro lado, um serviço de base de dados acessível ao público não deve, em regra, ter de ser protegido por uma lista de bloqueio da Internet: o seu acesso à rede deve limitar-se a aplicações necessárias e a redes de confiança.

No caso de admissões administrativas, têm Restrição de acesso e um processo de autenticação robusto tem prioridade sobre os bloqueios automáticos de IP. Um serviço SSH atrás de uma VPN, de um bastion host ou de redes de administração fixas oferece aos atacantes uma superfície de ataque significativamente menor do que uma porta aberta a nível mundial. Atualizações de segurança recentes, contas privilegiadas separadas e um processo de autenticação por palavra-passe cuidadosamente ponderado reduzem os riscos que uma lista de bloqueio, por si só, não elimina.

Se o SSH estiver deliberadamente acessível ao público, os limites e os bloqueios baseados em registos podem reduzir as tentativas repetidas de introdução de palavra-passe. No entanto, continuam a ser apenas um complemento: as pessoas por trás de um gateway NAT partilhado podem utilizar a mesma morada de origem, enquanto os ataques distribuídos utilizam muitas moradas. No caso dos serviços de correio eletrónico, é igualmente importante determinar quais os protocolos que estão efetivamente abertos a utilizadores externos e quais as tentativas de início de sessão falhadas que são registadas.

No caso das aplicações web, é necessário distinguir entre a acessibilidade do proxy reverso e a dos serviços de backend internos. Um Nginx público pode aceitar pedidos HTTP sem que seja necessário que a base de dados, a cache ou a interface de administração estejam acessíveis a partir da Internet. O Objetivo de proteção Por isso, o objetivo não é, de forma generalizada, „bloquear endereços IP“, mas sim limitar os acessos não autorizados em cada serviço, preservar a utilização legítima e evitar autorizações desnecessárias.

Antes de qualquer alteração, os responsáveis devem identificar quais as vias de acesso necessárias em caso de emergência e quais as redes de origem que acedem regularmente ao sistema. Este levantamento evita que uma regra de firewall demasiado restritiva bloqueie o próprio acesso de administração ou a manutenção automatizada. Só depois disso é que se pode decidir se a análise de registos, a limitação de ligações ou um conceito em várias fases é o mais adequado.

Além disso, um bloqueio não responde à questão de saber se um serviço tem, de facto, de ser público. Quem inverte esta ordem trata as ligações suspeitas, embora a exposição subjacente permaneça inalterada. Especialmente no caso de interfaces administrativas raramente utilizadas, uma via de acesso privada é frequentemente mais eficaz e mais fácil de gerir do que regras de deteção cada vez mais complexas.

Quatro abordagens em vez de uma alternativa ao Fail2Ban

Em vez de procurar uma única solução alternativa, vale a pena separar a deteção da reação. CrowdSec processa fontes de registo configuráveis com analisadores e cenários, para avaliar sequências de eventos e gerar decisões. O Security Engine não aplica estas decisões por si próprio; para tal, é necessário que um Componente de Remediação separado esteja ligado e em funcionamento.

Esta divisão é adequada quando se pretende que a mesma regra de deteção seja aplicada em diferentes pontos. Um componente de firewall pode aplicar decisões às ligações de rede, enquanto os componentes para servidores web ou proxies reversos atuam no tráfego HTTP. No entanto, isto também aumenta os requisitos: a aquisição de registos, o analisador, a API local, as autorizações e a aplicação concreta devem ser planeadas como uma cadeia interligada.

O SSHGuard destina-se a casos mais específicos. Esta ferramenta agrega registos do sistema e pode bloquear fontes que se revelem repetidamente suspeitas através de backends de firewall; o seu objetivo inclui ataques de força bruta ao SSH e a outros serviços. Por isso, é mais adequada para erros de autenticação identificáveis do que para uma análise abrangente de pedidos Web.

Nativos Limitação de taxa no nftables adota uma abordagem diferente. Os conjuntos dinâmicos e os medidores podem limitar novas ligações TCP por endereço de origem e gerir entradas com tempo de espera excedido. Isto impede sequências rápidas de ligações antes da autenticação, não requer um analisador de registos e, ao mesmo tempo, não avalia se um início de sessão falhou ou se um pedido HTTP era malicioso.

A direção da regra é importante neste contexto: o nftables distingue entre regras que aceitam tráfego até uma determinada taxa e expressões com over, que rejeitam o tráfego acima de uma determinada taxa. Por isso, um limite tem de ser adequado ao serviço, ao comportamento esperado dos utilizadores e aos endereços de origem partilhados. Não se trata de uma classificação fiável de todas as identidades suspeitas.

Para um único servidor com poucos serviços bem definidos, pode ser suficiente uma proteção de registos simplificada ou um limite moderado de ligações. A existência de vários anfitriões, fontes de registo centralizadas ou a necessidade de diferentes pontos de aplicação de políticas sugerem, antes, uma arquitetura modular. Nenhuma destas opções substitui as correções de segurança, a autenticação forte ou um acesso restrito à rede.

A alternativa adequada ao Fail2Ban depende, portanto, dos sinais disponíveis e do local onde deve ocorrer uma reação. Os padrões de registo são úteis para erros de início de sessão repetidos; as regras de pacotes limitam a frequência das ligações. Ambos os métodos detetam apenas aquilo para que a sua fonte de dados e as suas regras foram concebidas.

Separar claramente o firewall da proteção HTTP

Um servidor Nginx ou proxy inverso liga dois níveis de proteção que não devem ser confundidos. Um bloqueio de firewall rejeita ou permite ligações provenientes de um endereço de origem, podendo, assim, afetar simultaneamente o SSH, o SMTP ou o acesso à Web. No entanto, não avalia nenhum caminho HTTP específico, cabeçalho ou conteúdo de pedido; estas informações situam-se ao nível da aplicação.

Na CrowdSec, há Detecção e aplicação funções distintas. O Log Processor analisa dados de registo e pedidos HTTP de servidores Web compatíveis. O AppSec faz parte deste Log Processor e filtra esses pedidos HTTP. Por seu lado, os Remediation Components são responsáveis por aplicar as decisões no nível selecionado, por exemplo, num firewall, num servidor Web ou num proxy reverso.

Para a proteção contra injeção de SQL, cross-site scripting ou outros conteúdos maliciosos nas solicitações, um simples componente de firewall não é, portanto, suficiente. É necessária uma ligação compatível com o servidor web, bem como uma configuração adequada de segurança de aplicações (AppSec) com regras apropriadas. A remediação deve ser mantida separada do ponto de vista técnico: esta implementa as decisões no ponto de aplicação selecionado.

Ambos os níveis podem ser úteis em simultâneo. Um bloqueio a nível da rede reduz o tráfego de ligação adicional proveniente de uma fonte, enquanto um Verificação HTTP avalia e filtra servidores Web compatíveis com pedidos AppSec. Isso não significa que o bloqueio de IP proteja automaticamente contra injeção de SQL ou cross-site scripting: sem a verificação dos pedidos, a firewall não reconhece nem os parâmetros nem os dados úteis.

Por outro lado, as medidas baseadas na segurança de aplicações (AppSec) e no IP também têm as suas limitações. Tentativas lentas abaixo dos limiares, muitas moradas de origem variáveis ou utilizadores legítimos por trás da mesma morada NAT dificultam as decisões com base no IP de origem. Por isso, as regras devem ter em conta os falsos alarmes e não tratar de forma generalizada o acesso a formulários normais, APIs e integrações automatizadas como um ataque.

Para facilitar o planeamento, convém fazer uma breve contextualização: A Nível do firewall controla o tráfego de rede com base em endereços, portas e características da ligação. O AppSec processa e filtra os pedidos HTTP de servidores Web compatíveis, no âmbito do Log Processor. Os Remediation Components aplicam as decisões de forma deliberada num nível selecionado.

Um sistema Web público requer, além disso, uma separação clara de competências. O proxy reverso só deve aceder aos back-ends necessários, e os pontos finais administrativos não devem permanecer publicamente disponíveis apenas por causa de um filtro a montante. Desta forma, a segmentação da rede, o início de sessão seguro e as regras específicas complementam-se, sem atribuir a uma única técnica de bloqueio mais efeito de proteção do que aquela pode proporcionar.

Comparação entre servidores Linux típicos

Não faz sentido escolher uma alternativa ao Fail2Ban apenas com base no número de bloqueios possíveis. O que é decisivo são os sinais que são analisados e o local onde a política é aplicada. CrowdSec separa o seu motor de segurança do componente responsável pela aplicação das decisões no firewall, no proxy ou no servidor web. Por outro lado, o SSHGuard analisa os registos do sistema para detetar tentativas de ataque repetidas; o nftables pode limitar novas ligações diretamente no percurso do pacote.

A tabela não representa uma classificação. No caso de um serviço individual com tentativas de início de sessão claramente falhadas, uma análise simples dos registos é diferente de um limite contra picos de ligações. No caso de um proxy inverso, é também importante determinar se as solicitações HTTP devem ser filtradas pelo AppSec numa ligação compatível. O Ponto de aplicação tem de corresponder ao objeto a proteger: uma regra de firewall não avalia o conteúdo das solicitações, enquanto os Componentes de Remediação aplicam decisões no nível selecionado em cada caso.

A gestão centralizada também não é um fim em si mesma. Pode uniformizar as decisões e a análise de registos em vários anfitriões, mas exige um plano robusto de acesso e de contingência em caso de falha. Para um servidor pequeno e isolado, esta arquitetura adicional pode, em determinadas circunstâncias, implicar mais esforço de manutenção do que ganhos em termos de segurança. Por outro lado, serviços idênticos em vários anfitriões podem beneficiar de uma instalação centralizada do CrowdSec cuidadosamente planeada.

Verificar e classificar a configuração de forma segura

Antes de ativar o serviço, é necessário determinar quais as mensagens que chegam efetivamente ao mesmo. No caso de uma solução baseada em registos, verifique a fonte dos registos, o analisador e o formato específico dos eventos SSH, de e-mail ou de proxy. No caso do CrowdSec, a deteção de atividade não é suficiente: um componente de remediação registado e acessível deve transmitir as decisões à ligação prevista ao firewall ou ao proxy.

Os comandos que se seguem são apenas verificações de leitura num sistema Linux, no qual as respetivas ferramentas já podem estar instaladas. Não alteram regras nem instalam pacotes. Ajudam a visualizar o conjunto atual de regras, os componentes CrowdSec registados e os pacotes candidatos disponíveis para o Debian ou o Ubuntu.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

A saída ainda não implica qualquer efeito de proteção. Verifica no nftables se a cadeia de entrada relevante possui o gancho esperado e a política padrão adequada, e se existem regras previstas para ligações existentes, loopback, IPv4 e IPv6, bem como para a porta de serviço efetiva. Além disso, um componente registado pode estar configurado para o ponto de aplicação errado. Mesmo um pacote candidato visível não indica se a sua versão, configuração e analisador são compatíveis com a distribuição e com o próprio serviço.

Os valores-limiar, os períodos de bloqueio e as exceções não devem ser implementados em produção sem serem previamente verificados com base em exemplos. Em particular, os endereços NAT partilhados, os acessos móveis e as tarefas automatizadas podem, de outra forma, dar origem a falsos alarmes. Para a análise de eventos de rede e do comportamento do sistema, pode ser utilizado adicionalmente Rastreio eBPF para monitorização do Linux ajuda; no entanto, não substitui nem a verificação da cadeia de registos nem a decisão técnica relativa a um bloqueio.

A escolha certa para quatro cenários operacionais

Um único VPS com acesso SSH a nível mundial tem necessidades de proteção bem definidas. O SSHGuard pode comunicar a um backend de firewall tentativas falhadas repetidas, identificáveis nos registos correspondentes. Um limite moderado no nftables pode, além disso, restringir novas ligações, mas não avalia erros de início de sessão. A prioridade recai sobre vias de administração restritas e autenticação forte; o bloqueio de IP continua a ser um complemento.

Num servidor de e-mail, os protocolos SMTP, IMAP e Submission seguem diferentes percursos de autenticação e registo. Uma resposta simplificada baseada em registos só faz sentido se as mensagens relevantes forem registadas na íntegra. O CrowdSec torna-se uma opção quando é necessário centralizar as decisões ou a análise de registos de vários sistemas. Sem essa necessidade, a arquitetura central seria desproporcionada em comparação com uma solução local claramente delimitada.

No caso do Nginx ou do Traefik, colocados à frente de uma aplicação web, uma ferramenta exclusivamente orientada para SSH não é suficiente. Aqui, uma proteção em várias camadas Acessos à rede a partir de verificações HTTP: o CrowdSec AppSec faz parte do Log Processor e pode filtrar pedidos de servidores Web compatíveis. Por outro lado, os Remediation Components aplicam as decisões no nível selecionado, por exemplo, no servidor Web ou no proxy reverso. Ambas as tarefas devem ser devidamente integradas e verificadas separadamente.

Uma pequena frota com registos centralizados ou Kubernetes pode beneficiar de uma API local centralizada ou de registos centralizados. Isso não simplifica automaticamente a operação: as autorizações, a acessibilidade das interfaces, a segmentação e a falha de um componente central têm de ser planeadas. Os aspetos relacionados com o processamento de pacotes e a distribuição de carga em redes Linux de maior dimensão também são abordados no artigo sobre Receive Side Scaling em redes de servidores Linux. No caso de um número reduzido de hosts sem um processo operacional comum, uma solução local continua a ser, muitas vezes, mais compreensível.

Monitorizar a lógica de bloqueio durante o funcionamento

Uma lógica de bloqueio só é compreensível se controlares separadamente três etapas: a entrada dos dados de registo, a decisão daí derivada e a sua aplicação técnica. No CrowdSec, o Security Engine lê as fontes de registo configuradas e gera decisões com base em analisadores e cenários; no entanto, o bloqueio propriamente dito é executado por um componente de remediação separado.

Verifica primeiro se as mensagens esperadas chegam de facto. No caso de um serviço SSH, as tentativas de início de sessão falhadas são relevantes; no caso de um servidor de e-mail, os respetivos protocolos de autenticação; e no caso de um proxy, os seus registos de acesso ou de segurança. Os eventos visíveis, por si só, não comprovam um efeito defensivo: só a cadeia que inclui a receção do registo, a sequência detetada, a decisão e a regra eficaz permite um diagnóstico fiável.

Em seguida, verifique separadamente as decisões e o componente registado. Se o CrowdSec detetar eventos suspeitos, mas não houver nenhum componente de correção ligado ou em funcionamento, as decisões não terão qualquer efeito. A documentação oficial sobre erros identifica precisamente este padrão como a causa de o Security Engine estar a funcionar, mas de não se verificar qualquer bloqueio. A deteção não é um bloqueio.

No Webschutz, é adicionada uma verificação adicional. O AppSec faz parte do Log Processor e filtra os pedidos HTTP de servidores Web compatíveis. Os Remediation Components aplicam as decisões ao nível selecionado, por exemplo, no servidor Web ou no proxy reverso. Durante o funcionamento, deve, portanto, ser possível distinguir se uma rejeição resulta da verificação HTTP ou de uma decisão já aplicada, para que os erros e os falsos alarmes possam ser investigados de forma específica.

Os falsos alarmes têm consequências particularmente graves quando muitas pessoas autorizadas utilizam a mesma morada pública. Os gateways NAT, as redes móveis e os sistemas de identificação de clientes (CI) podem agrupar inúmeras tentativas de início de sessão legítimas sob um único endereço IP de origem. Por isso, define os limiares, os períodos de bloqueio e as exceções com base nas vias de acesso reais e mantém as decisões compreensíveis, incluindo o motivo e o tempo de duração, em vez de considerar uma longa lista de bloqueios como um sucesso.

Teste as alterações, em primeiro lugar, com registos históricos anonimizados ou num ambiente de teste. Isto permite verificar se os analisadores detetam os padrões previstos e se a correção reage ao nível esperado, sem comprometer os acessos de administração. O SSHGuard processa registos do sistema e pode interagir com diferentes back-ends de firewall; por isso, a fonte dos registos e o back-end devem ser considerados em conjunto no ambiente instalado.

Um processo controlado não substitui um teste de ataque no sistema de produção. Documente os eventos esperados, as decisões observadas e o efeito das regras daí resultante; em seguida, elimine os dados de teste ou deixe que as entradas temporárias caduquem normalmente. Desta forma, o efeito de proteção e os possíveis danos colaterais permanecem verificáveis, sem que se provoquem intencionalmente bloqueios reais aos utilizadores do sistema produtivo.

Resolução de problemas em registos e regras

Começa sempre a investigação de erros pela fonte do registo e, em seguida, avança até à aplicação da regra. Se não existirem mensagens adequadas, nem um analisador de registos, nem uma lógica de cenário ou de bloqueio poderão reagir de forma fiável. Por isso, verifica o serviço, o leitor de registos e o formato efetivo antes de alterares os valores-limite ou de suspeitares das regras da firewall.

No CrowdSec, o padrão de erro é claro quando os eventos ou decisões são visíveis, mas os acessos continuam a ser possíveis: uma decisão não é automaticamente aplicada pelo motor. Verifique se existe um componente de correção adequado registado, acessível e efetivamente ligado ao firewall, ao servidor web ou ao proxy. Sem este componente, nenhuma regra de bloqueio será aplicada.

No caso do SSHGuard, a causa reside frequentemente a montante. A ferramenta agrega registos do sistema, mas um leitor de registos inadequado ou um formato de serviço que se desvie do padrão esperado não fornece resultados úteis. A configuração de exemplo no repositório mostra possíveis entradas e opções, mas provém do ramo de desenvolvimento; compare-a com a documentação do pacote e com a versão instalada, em vez de a adotar tal como está.

No nftables, verifica-se adicionalmente se a regra na cadeia relevante se encontra no gancho esperado, se abrange a porta de serviço efetiva e se se aplica às famílias de protocolos necessárias. O conjunto de regras de exemplo separa o IPv4 e o IPv6 em cadeias próprias, permitindo ligações estabelecidas e associadas, bem como tráfego de loopback, antes das autorizações de porta. Uma proteção formulada exclusivamente para IPv4 não abrange o IPv6; da mesma forma, uma taxa demasiado restritiva pode afetar ligações paralelas legítimas.

O «Ein Meter» limita novas ligações com base numa taxa definida por fonte e pode gerir entradas dinâmicas com tempo limite. No entanto, isto não avalia as tentativas de início de sessão falhadas. Se um ataque se mantiver abaixo dessa taxa, uma falha na deteção não é, por isso, necessariamente um defeito da regra, mas pode ser um limite da abordagem escolhida. Gancho, corrente e ponto de medição devem corresponder ao efeito esperado.

Efetue as alterações uma a uma e verifique novamente, após cada passo, a entrada de registo, a decisão e a aplicação. Antes de efetuar ajustes no firewall, garanta um acesso de emergência independente, por exemplo, através da consola, de um bastion host ou de uma rede de administração separada. Isto evita que uma regra mal configurada ou uma adição incorreta de IPv6 bloqueie o único acesso ao servidor.

Decisão com base no risco e no esforço envolvido

A alternativa adequada ao Fail2Ban depende da superfície de ataque exposta, e não de uma classificação geral. Determina quais os serviços que estão acessíveis ao público, se processam inícios de sessão, quais os registos de que se dispõe de forma fiável e quem é responsável pela gestão contínua da configuração. Um serviço de base de dados sem acessibilidade pública não necessita de uma lista de bloqueio da Internet; a sua configuração de acesso à rede continua a ser a decisão de segurança mais importante.

Para um servidor individual de dimensões reduzidas, com erros repetidos de início de sessão via SSH ou de e-mail, o SSHGuard pode ser uma abordagem simples e baseada em registos. O projeto visa a proteção contra ataques de força bruta contra o SSH e outros serviços, recorrendo para tal aos registos do sistema e a backends de firewall. No entanto, a cobertura concreta dos registos e os parâmetros de bloqueio têm de ser compatíveis com a distribuição instalada e com o formato do serviço.

Se o objetivo for, sobretudo, limitar as novas ligações rápidas, um limite de taxa moderado no nftables constitui um complemento direto. Os medidores podem limitar as ligações por endereço de origem; regras com over rejeitar o tráfego que exceda a taxa definida. Isto ocorre antes de um início de sessão, mas não fornece qualquer informação semântica sobre se um início de sessão falhou ou se um pedido HTTP era malicioso.

O CrowdSec é adequado quando é necessário coordenar a análise de registos e a aplicação de políticas em vários níveis ou em vários anfitriões. A sua arquitetura separa o motor dos componentes de correção; são possíveis variantes distribuídas com uma API local centralizada ou registos centralizados. Esta vantagem implica requisitos adicionais em termos de autorizações, acessibilidade, segmentação e um plano para situações de falha. Operacionalidade é, por isso, um critério de seleção, a par do conjunto de funcionalidades.

No caso das aplicações web públicas, um bloqueio por firewall não é suficiente para avaliar cada pedido HTTP. Para tal, é necessária uma integração AppSec compatível com regras adequadas. O AppSec faz parte do Log Processor e filtra as solicitações HTTP de servidores Web compatíveis; os Remediation Components aplicam as decisões no ponto de aplicação selecionado. O fator decisivo é se a necessidade de proteção diz respeito a ligações, eventos de autenticação ou conteúdos HTTP.

As medidas baseadas em IP continuam a ser limitadas: as redes de bots distribuem as tentativas por várias fontes, os ataques lentos podem manter-se abaixo de um determinado limite e, em caso de bloqueio, os endereços partilhados afetam pessoas inocentes. Estas medidas reduzem o ruído automatizado, mas não substituem a aplicação atempada de patches, o acesso restrito à administração e a autenticação forte. Especialmente no caso do SSH, o início de sessão baseado em chaves e a acessibilidade limitada têm prioridade sobre limiares de bloqueio cada vez mais agressivos.