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% visaram portas web e 40% portas de correio, coerente com os serviços do local. Foram contactados 27 destinos internos nessa janela. Os nomes dos serviços são inferidos pelas portas, não confirmados por análise do protocolo. A janela móvel também não coincide com as primeiras 24 horas após a ativação; não devemos comparar diretamente os totais.

As 232 correspondências de saída merecem investigação: dez sistemas internos tentaram contactar 17 destinos listados. Isso não prova infeção. Pode resultar de malware, conteúdo de terceiros, entradas antigas ou IPs reassociados a serviços legítimos.

A interface mais rápida e os tempos de carregamento relatados pelo cliente são observações posteriores à mudança. Não isolámos a causa do anterior estrangulamento: firewall, servidores, aplicações ou ligação. Os eventos mostram filtragem, mas não medem tempos nem recursos poupados. Não permitem calcular uma percentagem de melhoria.

Neste caso, os pedidos automatizados chegavam antes aos servidores web e de aplicações. Estes tinham de os processar e, por exemplo, responder com erro a caminhos inexistentes. O bloqueio inicial evitou esse trabalho para os pedidos afetados. A firewall também pôde rejeitá-los antes de os encaminhar e processar mais. A consulta da lista consome recursos; a poupança vem das etapas posteriores evitadas.

A ordem e o âmbito da filtragem dependem da plataforma e configuração, sobretudo para WAF e serviços da própria firewall. O primeiro pacote continua a chegar à interface WAN. Um bloqueio local pode evitar respostas e tráfego subsequente, mas não substitui proteção anterior contra DDoS volumétrico.

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

Vou revelar já o fornecedor que muitos colegas e eu usamos: Cybora. Também o utilizo para proteger serviços públicos nos meus servidores cloud. A decisão baseia-se numa comparação em produção, não numa demonstração comercial.

Durante doze meses testámos mais de 30 fornecedores e fontes públicas em 15 firewalls de clientes. Contratámos subscrições, gastámos vários milhares de dólares e comparámos opções gratuitas com pacotes próximos de 1 000 dólares mensais. Alguns dos mais caros entregavam listas pequenas, alegando grande atualidade e precisão.

Instalámos os feeds em análise nas 15 firewalls em modo Monitor. Registavam correspondências sem bloquear ligações. Investigámos os resultados no tráfego real e nos serviços afetados. Esta comparação prolongada é separada do bloqueio aplicado no centro de dados.

Comparámos origens identificadas e analisámos pedidos suspeitos e possíveis falsos positivos com os logs disponíveis. Contavam atividade maliciosa confirmada, cobertura adicional, atualidade e custo das exceções. Tamanho e preço isolados não demonstram qualidade. Agrupámos eventos repetidos para um scanner muito ativo não dominar os resultados e incluímos ligações legítimas que teriam sido bloqueadas.

Foi uma comparação operacional, não um ensaio de laboratório padronizado. A ordem de avaliação, sobreposições e outras defesas podem afetar os registos. A ausência de um evento não prova falta de deteção. Um benchmark reproduzível exigiria instantâneos datados dos feeds, parâmetros de avaliação e casos positivos e negativos confirmados; não publicamos o conjunto completo.

Estas onze opções são uma seleção editorial, não um ranking de popularidade ou desempenho. AbuseIPDB e IPsum são alternativas documentadas sem resultados próprios de testes. Cybora surge primeiro pela nossa experiência; a restante ordem não é medida. Os dados Q-Feeds foram verificados em 28 de setembro de 2026 e os restantes em 8 de setembro.

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, útil em infraestruturas muito expostas; esse intervalo não diz quanto demoraram antes a deteção e avaliação, nem inclui a descarga e importação. Nos dados houve duas respostas HTTP 429: a lista local continuou ativa e a descarga seguinte recuperou. Convém vigiar a idade do feed e falhas de atualização.

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 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 diz selecionar indicadores de mais de 2 500 fontes comerciais, abertas e governamentais para feeds de IPs, domínios e URLs, com controlo de qualidade e remoção de falsos positivos. Tivemos outra experiência: na primeira hora de uma aplicação em modo de bloqueio, várias ligações legítimas foram impedidas. Investigámos os casos e classificámos os verificados como falsos positivos. O suporte removeu as entradas comunicadas relativamente depressa. Ainda assim, o esforço de análise e comunicação levou-nos a deixar de reportar sistematicamente casos posteriores.

O número de fontes, por si só, não explica estes erros. Sem conhecer origem, motivo e reavaliação de cada IP, não conseguimos determinar a causa. Para aplicar bloqueios em larga escala nas firewalls dos clientes, a carga de exceções e suporte observada foi demasiado alta. O feed pode ser útil para monitorização ou investigação; esta avaliação diz respeito ao bloqueio nos nossos ambientes.

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 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 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 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 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 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 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

Por transparência: este é o meu blog pessoal e não recebo comissão. O meu empregador revende Cybora e compra licenças com desconto para as vender com margem. Essa relação comercial importa para interpretar a recomendação. Escolhemos o feed pelos resultados do teste descrito, não pelos termos de revenda.

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.

Redes produtivas complementam sensores artificiais com serviços e padrões de tráfego distintos. Não garantem superioridade e outros fornecedores também as usam. Para nós importaram os endereços adicionais e o seu comportamento. Encontrámos repetidamente IPs presentes então só na Cybora; logs de firewall e aplicação mostravam sequências suspeitas, caminhos URL invulgares e tentativas automatizadas de login ou formulários. Um drop IP precoce não revela caminhos HTTP; a prova tem de vir de fases de observação ou logs correlacionáveis. Uma taxa alta isolada também não demonstra ataque.

Um caso de suporte mostrou o limite do bloqueio IP: um website necessário partilhava IP de alojamento com infraestrutura comprometida. A reputação da IP era justificável, mas o site legítimo também ficou inacessível. Uma regra IP não distingue sites no mesmo endereço. Tratamos isso como falso positivo operacional ou custo de exceção. Quando possível, a exceção deve limitar serviço e utilizadores e ser revista; libertar toda a IP expõe novamente os restantes conteúdos. Uma única interação com suporte não permite avaliar os prazos habituais.

O resultado técnico é simples: um endereço HTTPS e uma lista, configuráveis em minutos nas plataformas suportadas. Bloquear de forma responsável requer antes validar no tráfego próprio.

STIX e TAXII não são uma lista de bloqueio

STIX (Structured Threat Information Expression) é um modelo estruturado que pode descrever IPs, malware, campanhas, atores, técnicas, observações, períodos, confiança e relações. Explica o contexto de um indicador. TAXII (Trusted Automated Exchange of Intelligence Information) é o protocolo HTTPS para trocar esses dados: STIX descreve o conteúdo e TAXII o transporte ou API.

Esse contexto ajuda plataformas de inteligência, SIEM e SOC. Para comparar IPs rapidamente, a firewall pode usar apenas um conjunto derivado de endereços, descarregado periodicamente e mantido localmente. Não processa STIX/TAXII para cada pacote. Uma lista TXT tem menos contexto, mas pode resultar de inteligência estruturada e servir a aplicação de regras no perímetro.

O que um Threat Feed não consegue fazer

O exemplo e a cobertura IP avaliados referem-se a IPv4, dominante nos ambientes que acompanho. Não dizem nada sobre IPv6. Serviços publicados também em IPv6 exigem verificação separada: uma lista IPv4 não os abrange.

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