Threat Feeds for Firewalls: Impact, Limitations, and Providers Compared

The internet is full of systems that automatically scan public addresses. They look for open ports, login pages, VPN portals, known web applications, and vulnerable services. These systems belong to security researchers and infrastructure search engines as well as bots and attackers looking for exploitable weaknesses.

Anyone operating a service published through a WAF, a DNAT exposure, a mail gateway, or a public login will eventually appear in those scans. A public IP address alone does not mean a compromise. Once a service behind it responds, however, background noise becomes real work for the firewall, IPS, WAF, server, application, and logging pipeline.

As a security engineer, this basic pattern is not new to me. At work, we repeatedly see firewalls, WAFs, and public services spend a significant part of their time processing automated noise. It is rarely one spectacular attack. It is a permanent mixture of port scans, login attempts, crawlers, and exploit checks.

Recently, I was part of a team analyzing a case whose scale was remarkable even to us. It concerned a firewall in a data center with a 10 Gbit/s uplink and what should have been ample performance headroom. The system still appeared to be near its limit. Link utilization was conspicuously high, administration felt sluggish, and the exposed services continuously produced new events.

We examined traffic by direction, destination, port, time window, and recurring source address. Numerous automated requests repeatedly targeted the same web, mail, and login services. Their processing cost depends on more than volume: a discarded packet, a TLS handshake, and an expensive application request consume different resources.

We then explained the findings to the customer. A significant share of the activity consisted of automated bot and scan traffic repeatedly hitting the same exposed services. We showed the customer what a threat feed could achieve at this point in the data path, where its limits were, and that the appropriate license cost about USD 350 per year. Once the customer approved the expense, we installed the list directly on the firewall with just a few clicks. The entire setup took only a few minutes.

After activation, the firewall’s management interface became substantially more responsive. The customer also gave clear feedback: websites and applications loaded much faster. The improvement was noticeable both when administering the firewall and when using the services day to day.

That effect is what makes the case interesting. Not because threat feeds are new to me, but because many administrators misunderstand both their value and their limits. Some see a feed as nothing more than a long text file containing IP addresses. Others treat it as a replacement for IPS, WAF, or EDR. What matters is where the indicators come from, how quickly they age, how rigorously false positives are removed, and where in the firewall data path they take effect. I therefore want to do more than present the measurements. I want to explain the subject from first principles.

The Result in Numbers

The measurements came from a production firewall. The IP threat feed became effective on September 1, 2026, at 10:01:05. The first hit followed a few seconds later. By September 2 at 20:30 CEST, the firewall had logged 516,959 block events.

Across the complete period, the feed acted an average of 249.9 times per minute. That is 4.17 events per second, or one block every 0.24 seconds. The busiest minute contained 775 events. The peak was 107 events within one second, and it occurred in two consecutive seconds.

I deliberately call these block events, hits, or connection attempts. A total of 516,959 events does not automatically mean 516,959 independent, manually directed attacks. One scanner may contact the same service repeatedly, a bot may test several ports in quick succession, and a failed connection can generate follow-up packets.

Who Was Knocking?

Across the complete measurement period of 34 hours and 29 minutes, 516,727 events were inbound. Only 232 events involved prevented outbound connections. In this environment, 99.955 percent of the feed’s activity therefore concerned sources on the internet.

A total of 10,518 different listed IP addresses appeared. With 220,000 IPv4 indicators in the feed at the time, roughly 4.8 percent of the entire list became relevant on this single firewall within about 34 hours. The most active address generated 4,141 events. The top ten addresses produced about 31,500 events between them, while 767 addresses appeared only once.

The roughly 4.8 percent is a size comparison with the list at that time, not a detection rate. Updates change the list, and unknown or unlisted attackers are absent from this counter.

The port analysis covers a rolling 24-hour window with approximately 369,000 detailed events:

About 56 percent of events targeted web ports and 40 percent mail ports. The detail window covered 27 internal destinations. Service names are inferred from ports, not confirmed by protocol analysis. This rolling 24-hour window differs from the first 24 hours after activation, so the totals are not directly comparable.

The 232 outbound hits involved ten internal systems and 17 listed destinations. That does not prove infection, but warrants investigation: malware, embedded third-party content, stale entries, or legitimate services on reassigned IPs are all possible.

After the change, the firewall GUI responded faster and the customer reported shorter loading times. The former bottleneck could have been the firewall, servers, applications, or connection; the observations do not isolate it. Block events prove filtering, not processing savings or a percentage performance gain.

Previously, automated requests had reached the web and application servers, which had to generate responses, including errors for nonexistent paths. Early IP blocking avoided that downstream work. List lookups also consume resources; the gain lies in the subsequent work avoided. Exact processing order depends on platform and configuration. The first packet still reaches the WAN interface, so volumetric DDoS requires upstream protection.

What a Threat Feed Actually Does

A simple firewall feed is remarkably unspectacular. The firewall downloads a text file over HTTPS containing the indicators to block. Many providers offer domain and URL feeds in addition to IP addresses. In most cases, however, we use only the IP addresses because they provide the most important information for our firewall use cases and achieve the greatest effect when blocked early. The firewall refreshes those indicators at a configured interval and checks matching traffic against the list. Depending on the configuration, a hit is logged or blocked.

How reliable a threat feed is in operation depends on how the provider validates its entries and keeps them current:

• Was the behavior malicious or merely unusual?
• How recent was the observation?
• Do independent sources confirm the signal?
• When should a stale indicator be removed?

A long blocklist is not good threat intelligence. Freshness, precision, and disciplined removal are what matter. The larger and older a list becomes, the greater the chance that dynamic cloud, hosting, or ISP addresses are now in legitimate use. A very small and conservative list has the opposite problem: few false positives, but possibly too little coverage against everyday scan noise.

Threat Feeds for Firewalls Compared

The name up front: many colleagues and I use a feed from Cybora. I also protect public services on my own cloud servers with it. That choice came from operational comparison, not a product demo.

Over twelve months, we assessed more than 30 commercial and public sources on 15 customer firewalls. We spent several thousand US dollars on offerings ranging from free feeds to packages near USD 1,000 per month. Price did not equal breadth: some costly lists were much smaller.

Every feed ran in Monitor mode on all 15 firewalls: matches were logged, not blocked. This comparison is separate from the data-center blocking deployment above. Using firewall and application logs, we assessed malicious behavior, additional coverage, freshness, and possible false positives. We grouped repeat hits so individual scanners did not skew the result and considered legitimate connections that blocking would have affected.

This is a field report, not a reproducible benchmark. Overlap, evaluation order, and other controls affect Monitor logs; an absent match alone does not prove a detection gap. I am not publishing the complete list snapshots, settings, and confirmed comparison cases.

These eleven offerings are not a popularity ranking. Cybora comes first because of our experience.

Cybora

Cybora delivered the best overall balance for our environments across coverage, freshness, active hits, low false-positive workload, straightforward integration, support, and price. Its entry plans are very fairly priced, while the Ultimate plan’s 15-minute updates make it relevant to larger and heavily exposed infrastructures such as those I often manage at work.

Cybora specializes in feeds for firewalls. According to the provider, its analysis combines honeypot data with signals from production firewalls of customers who choose to provide these signals. Those firewalls observe attacks on real, publicly reachable services. In our comparison, we repeatedly found suspicious IPs that only Cybora listed at the time of checking. For several IPs linked to brute-force attempts in our logs, Cybora’s entry also preceded their later addition to other feeds by a few days. That additional coverage and speed made a tangible quality difference for us.

CrowdSec Blocklists

CrowdSec Blocklists combine an open-source Security Engine with community signals and curated lists that can also be delivered directly to firewalls and gateways. Production telemetry from many environments and specialized lists are clear strengths. A list for CMS attackers, proxy infrastructure, or a particular CVE is not automatically a universal edge feed.

GreyNoise

GreyNoise also provides deployable query-based IP blocklists for firewalls. GNQL can select recently active malicious sources or activity associated with particular CVEs. It is a credible alternative for teams that want control over selection criteria. The work lies in query design, data-module entitlements, and reviewing the selection. Describing GreyNoise as only a log-enrichment service would understate its capabilities.

Q-Feeds

Q-Feeds says it curates indicators from more than 2,500 commercial, open, and governmental sources and provides IP, domain, and URL feeds. The provider describes quality checks and false-positive filtering. In our Monitor test, the feed matched several legitimate connections within the first hour; they would have been blocked in enforcement mode. We checked the logs and reported these as potential false positives. Support removed the reported entries relatively quickly, but the investigation workload led us to stop reporting later cases systematically.

The source count alone does not explain those matches. Without each IP’s origin and assessment, we could not establish the cause. For broad blocking across customer firewalls, the likely exception and support workload was too high for us. Q-Feeds may still be useful for monitoring or investigation.

Spamhaus DROP

Spamhaus DROP is a conservative list of particularly dangerous networks intended for edge filtering or routing decisions. Its high listing threshold makes it dependable, but it does not try to identify every short-lived scanner on the internet.

ThreatFox

ThreatFox from abuse.ch and Spamhaus focuses on malware-related indicators of compromise, including command-and-control infrastructure. It is a strong source for malware detection and threat hunting. Its purpose is narrower than that of a general firewall feed covering scanners, brute-force activity, and automated exploit infrastructure.

URLhaus

URLhaus from abuse.ch collects and distributes URLs used to deliver malware. This data is particularly useful for DNS filters, proxies, secure web gateways, and analysis platforms. For pure IP blocking at the perimeter, URLhaus is naturally a specialist building block.

The API requires an Auth-Key. Community access does not imply unrestricted free commercial use; the fair-use conditions must fit the deployment.

DShield

DShield publishes a compact recommended blocklist derived from submitted firewall logs. It can be a useful additional source. Other DShield datasets primarily serve research and context and should not be imported unfiltered as blocklists.

FireHOL IP Lists

FireHOL IP Lists aggregates and monitors numerous public lists. The repository is very useful for comparing size, update patterns, age, and overlap. An aggregator also inherits the weaknesses of its sources, however, and repeatedly redistributed entries can persist longer than desired.

AbuseIPDB

AbuseIPDB offers report-based IP reputation and a plaintext blacklist with configurable confidence thresholds. It helps with investigation and automated IP checks. A high score rates reported activity but does not prove that every current connection from that IP is malicious. Report age, shared addresses, and plan-dependent request limits matter.

IPsum

IPsum aggregates more than 30 public lists daily and provides ready-made thresholds based on source-list agreement. It is a transparent entry point into IP blocking. Three list matches are not necessarily three independent observations when sources reuse each other’s data. Daily updates limit responsiveness. It can serve as a conservative supplementary list, but does not provide an independent telemetry source.

Free therefore does not mean poor, and commercial does not automatically mean good. Many public feeds are excellent within their specialist areas. For a broad enforcement baseline at the firewall perimeter, however, our experience is that they are better treated as focused building blocks than as a complete replacement for a continuously curated all-round feed.

Why Cybora Ranked First in Our Comparison

This is my personal blog and I receive no commission. My employer does resell Cybora licenses at a margin, so I disclose that relationship. Our choice followed the field comparison described above.

In the practical case described above, Cybora was behind the measurements. We started with the Premium plan at USD 349 per year. Its hourly updates and broader coverage matched the exposed services without immediately selecting the largest available plan.

According to its public product description, Cybora combines OSINT, commercial sources, honeypots, sensors, and real firewall telemetry. Indicators are scored by recency, confidence, and cross-source agreement, deduplicated, checked against allow and exclusion rules, and published as a simple HTTPS list. At the time of the test, the Premium plan supplied 220,000 IPv4, 45,000 domain, and 25,000 URL indicators with hourly updates. On the measured firewall, IPv4 was set to Block, while domains initially remained on Monitor.

One week after activation, the customer moved from Premium to Ultimate. At the time, that plan contained more than 300,000 IPv4 addresses and more than 100,000 domains and URLs respectively, with updates every 15 minutes. The customer reported further performance improvements after this change. However, the measurement window analyzed above ends before that change and therefore does not demonstrate any additional performance gain from Ultimate.

Even the higher plan cost substantially less in this specific case than moving to a larger firewall appliance and the license tier it required. That does not make Ultimate the default recommendation for every environment. A small branch with few public services does not automatically need the largest list and shortest update interval. For this data-center customer, with many exposed web, mail, and login services, a high-capacity connection, and a six-figure daily hit count, the additional coverage made technical and economic sense.

We repeatedly found IP addresses that, at the time of checking, appeared in Cybora but none of the other lists we examined. Available firewall and application logs showed unusual request sequences, URL paths, and automated login or form activity. An early IP drop itself cannot reveal HTTP paths. Such evidence must come from observation periods or other correlatable logs. A high request rate alone does not prove an attack either. The behavior and timing of list entries matter, not merely the exclusivity of a hit.

One support case illustrated the limits of IP blocking particularly clearly. A customer could not reach a required website because its shared-hosting IP was listed. Investigation confirmed that the hosting infrastructure was compromised. The IP classification was therefore understandable, but the legitimate website was blocked as well. Both belong in the assessment: a justified reputation hit and an unwanted business impact.

An IP rule cannot distinguish websites sharing an address. We count such cases as exception workload: where possible, allow only the required service and users, then review the exception. What matters is not only whether a listing is justified, but whether the feed can be enforced safely with a manageable operational burden.

What a Threat Feed Cannot Do

Our measurements concern IPv4. Services also reachable over IPv6 need separate protection: an IPv4 list cannot filter those connections.

A threat feed blocks known indicators. It cannot automatically identify a new attacker using a clean IP address, a malicious customer on a legitimate cloud service, an attack hidden behind a CDN, or a vulnerability in your own application. IP addresses change, domains are newly registered, and compromised systems are cleaned or reassigned.

A feed therefore does not replace patch management, MFA, IPS, WAF, EDR, sound firewall policy, or useful logging. It is an additional early decision layer. On DNAT, WAF, VPN portal, and mail services in particular, that layer can absorb enormous volumes of known noise before more expensive controls begin.

I would always start a new feed in observation mode, prepare exclusions, check the firewall’s update and capacity limits, and define a clear process for false positives. Even a good list must earn trust in your own traffic.

My Conclusion

The measurements do not show that a feed license magically replaces a 10 Gbit/s link or a larger firewall. They show something more useful: on this single firewall, more than half a million known unwanted connection events were stopped early in just over 34 hours.

For the customer, the day-to-day improvement mattered: firewall administration became noticeably smoother, and the customer reported much faster websites and applications. That is a relevant operational outcome, even though the available data does not identify the original bottleneck. The recorded block events complement that experience by demonstrating that the feed regularly rejected unwanted sources.

Cybora was the best all-round feed for this use case in our twelve-month comparison. CrowdSec, GreyNoise, Spamhaus, abuse.ch, and other sources remain valuable, and are often better within their specialist areas. The right question is not “Which provider has the longest list?” It is “Which data is current, precise, and safe to enforce for my exposed services?”

Until next time,
Joe

FAQ