Threat Feeds para firewalls: eficácia, limites e fornecedores em comparação

A Internet está cheia de sistemas que analisam automaticamente endereços públicos. Procuram portas abertas, páginas de autenticação, portais VPN, aplicações web conhecidas e serviços vulneráveis. Alguns pertencem a investigadores de segurança e motores de pesquisa da infraestrutura da Internet; outros são bots e atacantes à procura de falhas exploráveis.

Quem publica um serviço através de uma WAF, uma regra DNAT, um gateway de correio ou um login público acaba por aparecer nestas pesquisas. Um IP público não significa, por si só, uma intrusão. Mas, quando existe um serviço que responde, o ruído transforma-se em trabalho para a firewall, o IPS, a WAF, o servidor, a aplicação e os registos.

Como engenheiro de segurança, conheço bem este padrão. Vemos frequentemente firewalls, WAFs e serviços públicos a consumir recursos com scans de portas, tentativas de login, crawlers e testes automatizados de exploits. Raramente se trata de um ataque único espetacular.

Recentemente participei numa análise cuja escala nos surpreendeu. A firewall de um centro de dados tinha uma ligação de 10 Gbit/s e, em princípio, uma boa reserva de capacidade. Ainda assim, parecia estar no limite: a ligação estava muito ocupada, a administração respondia lentamente e os serviços expostos geravam eventos continuamente.

Analisámos o tráfego por direção, destino, porta, período e endereço de origem recorrente. Muitas solicitações automatizadas atingiam repetidamente os mesmos serviços web, de correio e de login. O custo não depende apenas da quantidade: rejeitar um pacote, negociar TLS e processar um pedido complexo exigem recursos diferentes.

Explicámos ao cliente que grande parte da atividade vinha de bots e scans. Mostrámos o que um Threat Feed podia fazer ali, os seus limites e o preço da licença adequada, cerca de 350 dólares por ano. Depois de aprovar o custo, o cliente viu-nos instalar a lista na firewall em poucos cliques e minutos.

A interface de administração passou a responder muito mais depressa. O cliente também nos disse que os websites e as aplicações carregavam significativamente mais rápido. A melhoria foi visível na administração e na utilização diária.

O interesse do caso está nesse efeito. Os feeds não são novidade para mim, mas muitos administradores interpretam mal o seu alcance: uns veem apenas um ficheiro de IPs; outros esperam que substitua IPS, WAF ou EDR. Importa saber de onde vêm os indicadores, há quanto tempo foram observados, como são removidos falsos positivos e em que ponto a firewall bloqueia. Quero por isso explicar a técnica por detrás dos números.

O resultado em números

Os dados vêm de uma firewall em produção. O feed de IPs começou a atuar em 1 de setembro de 2026 às 10:01:05; o primeiro evento ocorreu segundos depois. Até 2 de setembro às 20:30 CEST foram registados 516 959 eventos de bloqueio.

A média foi de 249,9 eventos por minuto, ou 4,17 por segundo: um bloqueio a cada 0,24 segundos. O minuto mais intenso teve 775 eventos. O máximo de 107 eventos num segundo repetiu-se em dois segundos consecutivos.

Chamo-lhes eventos bloqueados, correspondências ou tentativas de ligação de propósito. Não são 516 959 ataques manuais independentes. Um scanner pode repetir pedidos, um bot testar várias portas e uma ligação falhada gerar pacotes adicionais.

Quem estava à porta?

Nas 34 horas e 29 minutos de medição, 516 727 eventos eram de entrada e 232 eram ligações de saída impedidas. Assim, 99,955% da atividade do feed neste ambiente incidiu em origens da Internet.

Surgiram 10 518 IPs listados distintos. O feed tinha então 220 000 indicadores IPv4, pelo que cerca de 4,8% da lista se revelou relevante nesta única firewall em aproximadamente 34 horas. O endereço mais ativo gerou 4 141 eventos, os dez primeiros cerca de 31 500 em conjunto, e 767 apareceram apenas uma vez. Os 4,8% são uma comparação de dimensões, não uma taxa de deteção: a lista muda e os atacantes não listados ficam fora do contador.

A distribuição por portas cobre uma janela móvel de 24 horas com cerca de 369 000 eventos detalhados:

Cerca de 56% dos eventos visou portas web e 40% portas de correio. A janela detalhada incluiu 27 destinos internos. Os nomes dos serviços são inferidos das portas, não confirmados por análise do protocolo. Essa janela móvel de 24 horas difere das primeiras 24 horas após a ativação, pelo que os totais não são diretamente comparáveis.

Os 232 acertos de saída envolveram dez sistemas internos e 17 destinos listados. Não provam infeção, mas justificam investigação: malware, conteúdo de terceiros, entradas antigas ou serviços legítimos em IPs reatribuídos são possibilidades.

Depois da mudança, a interface da firewall respondeu melhor e o cliente relatou carregamentos mais rápidos. Não sabemos se o estrangulamento anterior estava na firewall, nos servidores, nas aplicações ou na ligação. Os eventos demonstram filtragem, não quantificam recursos poupados nem uma melhoria percentual.

Antes, os pedidos automáticos chegavam efetivamente aos servidores web e aplicacionais, que tinham de responder até a caminhos inexistentes. O bloqueio precoce evitou esse trabalho posterior. Consultar a lista também consome recursos; a vantagem está no processamento que deixa de ocorrer. A ordem depende da plataforma e configuração. O primeiro pacote continua a chegar à WAN: DDoS volumétrico exige proteção a montante.

O que faz realmente um Threat Feed

Um feed simples costuma ser um ficheiro de texto descarregado por HTTPS. Muitos fornecedores oferecem IPs, domínios e URLs. Normalmente usamos IPs, pois dão o maior efeito aos nossos cenários de bloqueio precoce na firewall. Esta atualiza os indicadores a intervalos definidos e compara-os com o tráfego relevante; consoante a configuração, regista ou bloqueia.

A fiabilidade depende da avaliação anterior à publicação:

• O comportamento foi malicioso ou apenas invulgar?
• A observação é recente?
• Existem fontes independentes a confirmá-la?
• Quando é removido um indicador desatualizado?

Uma lista comprida não equivale a boa inteligência. Atualidade, precisão e limpeza são decisivas. IPs dinâmicos de cloud e alojamento podem voltar a ter uso legítimo. Uma lista muito pequena reduz falsos positivos, mas talvez cubra pouco ruído de scans.

Threat Feeds para firewalls em comparação

Vou direto ao nome: muitos colegas e eu usamos um feed da Cybora. Também protejo com ele serviços públicos nos meus servidores cloud. A decisão veio de uma comparação operacional, não de uma demonstração comercial.

Durante doze meses avaliámos mais de 30 fontes comerciais e públicas em 15 firewalls de clientes, gastando vários milhares de dólares. Havia opções gratuitas e planos perto de 1.000 dólares por mês. Preço elevado não significava lista maior: algumas das mais caras eram bastante menores.

Todos os feeds correram em Monitor nas 15 firewalls: registavam acertos sem bloquear ligações. Esta comparação é distinta do bloqueio no centro de dados acima. Com os logs da firewall e das aplicações analisámos atividade maliciosa, cobertura adicional, atualidade e potenciais falsos positivos. Agrupámos eventos repetidos e considerámos as ligações legítimas que o modo de bloqueio afetaria.

É um relato de experiência, não um benchmark reproduzível. Sobreposições, ordem de avaliação e outras defesas influenciam os logs de Monitor; a ausência de registo não prova uma lacuna. Não publico todos os estados datados das listas, definições e casos confirmados.

Estas onze ofertas não são um ranking de popularidade. A Cybora surge primeiro pela nossa experiência.

Cybora

Cybora deu-nos o melhor equilíbrio de cobertura, atualidade, correspondências úteis, trabalho com falsos positivos, integração, suporte e preço. Os planos de entrada são acessíveis. O Ultimate publica a cada 15 minutos, algo útil em infraestruturas muito expostas.

A Cybora especializa-se em feeds para firewalls. Segundo o fornecedor, a análise combina dados de honeypots com sinais de firewalls de produção de clientes que optam por fornecer esses sinais. Estes equipamentos observam ataques a serviços reais expostos à Internet. Na nossa comparação, encontrámos repetidamente IP suspeitos que, no momento da verificação, só constavam da Cybora. Em vários IP associados a tentativas de força bruta nos nossos logs, a Cybora antecipou-se em alguns dias aos outros feeds que os acrescentaram depois. Essa cobertura adicional e mais cedo disponível representou para nós uma diferença concreta de qualidade.

CrowdSec Blocklists

CrowdSec Blocklists associa motor open source, sinais comunitários e listas selecionadas para firewalls. A telemetria de produção e as listas específicas são pontos fortes, mas feeds de CMS, proxies ou um CVE não constituem automaticamente uma proteção universal de perímetro.

GreyNoise

GreyNoise fornece listas IP para firewalls baseadas em consultas GNQL, incluindo atividade recente ou relacionada com CVEs. É preciso definir e rever as consultas e ter os módulos adequados. Reduzi-lo a enriquecimento de logs seria subestimar a oferta.

Q-Feeds

Q-Feeds afirma reunir mais de 2.500 fontes comerciais, abertas e governamentais em feeds IP, domínio e URL, com controlos de qualidade. No nosso teste em Monitor, surgiram já na primeira hora várias ligações legítimas que teriam sido bloqueadas no modo ativo. Confirmámos os casos nos logs e comunicámos estes potenciais falsos positivos. O suporte removeu as entradas relatadas relativamente depressa, mas o esforço de análise levou-nos a deixar de comunicar sistematicamente os casos seguintes.

O número de fontes não explica, por si só, os acertos. Sem a origem e avaliação de cada IP não pudemos determinar a causa. Para bloqueio alargado nas firewalls dos clientes, a carga previsível de exceções e suporte era excessiva para nós. A Q-Feeds pode ainda ser útil para monitorização ou investigação.

Spamhaus DROP

Spamhaus DROP é uma lista conservadora de redes especialmente perigosas para filtragem de perímetro ou decisões de routing. O critério rigoroso dá confiança, mas não tenta identificar todos os scanners passageiros.

ThreatFox

ThreatFox da abuse.ch e Spamhaus concentra-se em indicadores de malware, incluindo comando e controlo. É forte em deteção e threat hunting, mas mais restrito que um feed geral contra scans, força bruta e exploração automatizada.

URLhaus

URLhaus da abuse.ch reúne URLs de distribuição de malware. É valioso para DNS, proxies, gateways web e análise, mas especializado para bloqueio IP de perímetro. A API exige Auth-Key; acesso comunitário não significa utilização comercial ilimitada.

DShield

DShield publica uma pequena lista recomendada derivada de logs de firewalls enviados. Outros conjuntos DShield destinam-se sobretudo à investigação e não devem ser importados sem filtragem como bloqueios.

FireHOL IP Lists

FireHOL IP Lists agrega e monitoriza listas públicas. Permite comparar dimensão, idade, atualizações e sobreposições, mas herda as fraquezas das fontes; entradas copiadas podem persistir demasiado tempo.

AbuseIPDB

AbuseIPDB oferece reputação baseada em denúncias e lista de texto com limiar de confiança configurável. Uma pontuação alta não prova que cada ligação atual seja maliciosa. Idade das denúncias, IPs partilhados e limites do plano importam.

IPsum

IPsum agrega diariamente mais de 30 listas e oferece limiares de concordância. Três listas não significam necessariamente três observações independentes se se copiarem. A atualização diária limita a velocidade; serve como complemento transparente, não como telemetria própria.

Gratuito não significa mau, nem comercial significa bom. Muitas fontes públicas são excelentes na sua especialidade. Para uma base ampla de bloqueio direto no perímetro, preferimos pela nossa experiência um feed continuamente selecionado, complementado por fontes específicas.

Porque ficou Cybora à frente

Este é o meu blog pessoal e não recebo comissões. O meu empregador revende licenças Cybora com margem; divulgo essa ligação. A escolha resultou da comparação prática descrita.

No caso apresentado começámos com Premium, a 349 dólares anuais e atualizações horárias. Segundo o fornecedor, Cybora combina OSINT, fontes comerciais, honeypots, sensores e telemetria real de firewalls. Avalia atualidade, confiança e concordância entre fontes, remove duplicados e aplica exclusões antes de publicar a lista HTTPS. O plano tinha então 220 000 IPv4, 45 000 domínios e 25 000 URLs. Na firewall medida, IPv4 estava em Block e domínios inicialmente em Monitor.

Uma semana depois o cliente passou a Ultimate: mais de 300 000 IPv4 e mais de 100 000 domínios e URLs de cada tipo, com atualizações a cada 15 minutos. O cliente relatou novas melhorias de desempenho, mas a janela medida terminou antes e não prova benefício adicional do Ultimate. Mesmo esse plano custava menos que uma firewall maior e a sua licença. Não é necessário em todos os locais; neste centro de dados, os muitos serviços web, de correio e de login expostos, a ligação rápida e os seis dígitos de eventos diários tornavam-no razoável.

Encontrámos repetidamente IPs que, no momento da verificação, só constavam da Cybora. Os logs disponíveis mostravam sequências invulgares de pedidos, caminhos URL e atividade automatizada em logins ou formulários. Um bloqueio IP precoce não revela caminhos HTTP: essa prova vem de períodos em Monitor ou de outros logs correlacionáveis. Muitas solicitações, por si só, também não provam um ataque; contam o comportamento e o momento da inclusão.

Um caso mostrou o limite do bloqueio IP: um site necessário a um cliente partilhava um endereço listado com infraestrutura de alojamento comprometida. A classificação era compreensível, mas o site legítimo também ficou inacessível. Uma regra IP não distingue sites no mesmo endereço. Contamos por isso estes casos no trabalho de exceções: sempre que possível, limitar o acesso ao serviço e aos utilizadores necessários e reavaliá-lo depois. Importa não só justificar a entrada, mas conseguir aplicar o feed com segurança e um esforço operacional aceitável.

O que um Threat Feed não consegue fazer

As nossas medições dizem respeito a IPv4. Serviços também acessíveis por IPv6 precisam de proteção separada: uma lista IPv4 não filtra essas ligações.

Um feed bloqueia indicadores conhecidos. Não reconhece automaticamente um novo atacante numa IP limpa, um cliente malicioso numa cloud legítima, ataques atrás de CDN ou falhas na própria aplicação. IPs mudam, novos domínios surgem e sistemas comprometidos são limpos ou reatribuídos. Não substitui patches, MFA, IPS, WAF, EDR, boas regras ou logs. Adiciona uma decisão precoce útil para DNAT, WAF, portais VPN e correio.

Começaria sempre por observar um feed novo, preparar exceções, verificar limites de atualização e capacidade e definir como resolver falsos positivos. É o tráfego local que deve provar a sua fiabilidade.

A minha conclusão

Os dados não demonstram que uma licença substitua uma ligação de 10 Gbit/s ou uma firewall maior. Mostram que mais de meio milhão de eventos de ligação indesejados conhecidos foram parados cedo nesta firewall em pouco mais de 34 horas. O cliente sentiu uma administração mais fluida e serviços mais rápidos, embora o gargalo anterior não tenha sido isolado. Os logs comprovam filtragem, não uma percentagem de melhoria.

Cybora foi o feed geral mais adequado ao nosso uso nos doze meses de comparação. CrowdSec, GreyNoise, Spamhaus, abuse.ch e outros continuam valiosos, por vezes superiores na respetiva especialidade. A pergunta certa é que indicadores são atuais, precisos e seguros de bloquear nos serviços expostos.

Até à próxima,
Joe

Perguntas frequentes