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 the events targeted web services, and roughly 40 percent targeted mail ports. That fits the site’s profile. Public web and mail services are easy to find, continuously reachable, and attractive to automation. The detailed window included requests to 27 internal destination systems.

Service names are inferred from destination ports, not established by successful protocol analysis. The rolling detail window also differs from the first 24 hours after activation, so the totals are not directly comparable.

The 232 outbound hits were small in number but important from a security perspective. Ten internal systems attempted connections to 17 listed destination addresses. Such a hit does not prove infection, but it deserves investigation. Possible explanations include malware communication, embedded third-party content, a stale entry, or a legitimate service now using a reassigned IP address.

The more responsive firewall GUI and the shorter loading times reported by the customer are specific observations following the change. They do not isolate the previous bottleneck, which could have been the firewall, web servers, applications, or the connection between them. The block events document filtering activity, but measure neither loading times nor processing savings. They cannot establish a percentage performance improvement.

In this case, the automated requests had actually been reaching the web and application servers. Those systems had to process them and, for example, generate error responses for nonexistent paths. Early IP blocking eliminated that downstream work for the affected requests. The firewall could also discard those connections earlier instead of forwarding and further processing them. The list lookup itself still consumes resources; the benefit comes from avoiding subsequent processing.

Order and scope depend on the platform and configuration, particularly for WAF traffic and services hosted on the firewall itself. The first packet still reaches the WAN interface. A local drop can prevent responses and further session traffic, but does not replace upstream protection against volumetric DDoS attacks.

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

I do not want to manufacture suspense and make readers wait until the end for the answer: the threat feed many of my colleagues and I use today comes from the provider Cybora. I also use it personally to protect publicly accessible services on my own cloud servers. That decision is based on a comparison in live environments, not on a product demonstration.

Over twelve months, our team tested more than 30 commercial providers and public sources across 15 customer firewalls. We bought the relevant subscriptions, spent several thousand US dollars, and assessed everything from free community feeds to packages approaching USD 1,000 per month. Some of the most expensive products supplied much smaller lists and justified their price mainly through claims of exceptional freshness and precision.

For this comparison, we installed the feeds being assessed on all 15 firewalls and set them to Monitor. They were intended to log matches without blocking the connections themselves. This allowed us to investigate the reported matches in the context of real traffic and the affected services. This longer-term monitoring comparison is separate from the blocking deployment in the data center described above.

We compared which sources the feeds identified and investigated suspicious requests and potential false positives using the available firewall and application logs. Our priorities were confirmed malicious activity, coverage beyond other lists, freshness, and the operational effort required for exceptions. List size or price alone did not establish quality.

Log analysis formed part of our team’s daily work. Recurring events need to be considered together so that one highly active scanner does not dominate the results. Legitimate connections a list would prevent are equally important. Even an IP correctly classified as problematic can produce operational false positives in this way.

This was a comparison in everyday production use, not a standardized laboratory test. Monitor hits do not automatically provide a complete comparison of every list: evaluation order, overlap, and other active security functions can affect what a firewall logs. A missing log entry alone therefore does not establish a detection gap. An independently reproducible benchmark would also require disclosure of timestamped list snapshots, evaluation settings, and confirmed positive and negative cases. I am not publishing that complete comparative dataset here.

These eleven offerings are an editorial selection for firewall operations, not a popularity ranking supported by market-share data. They combine our field experience with additional sources assessed through current documentation. AbuseIPDB and IPsum are additional options; no hands-on results are claimed for them here. Cybora comes first because of our experience. The remaining order is not a measured ranking. Other product information was checked on September 8, 2026; the Q-Feeds details were checked on September 28, 2026.

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.

There are limits here too: a 15-minute publication interval says nothing about the preceding detection and assessment time. Firewall retrieval and import add further delay. The supplied measurement package also records two HTTP 429 responses; the existing list remained active locally and the next retrieval caught up. This was not a complete outage, but illustrates why list age and failed updates require monitoring.

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 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 says it curates indicators from more than 2,500 commercial, open, and governmental sources and provides IP, domain, and URL feeds. The provider describes its own quality checks and false-positive filtering. Our operational experience was less favorable: several legitimate connections were blocked within the first hour of a blocking deployment. We investigated the affected traffic and classified the cases we checked as false positives. Support removed the reported entries relatively quickly. The investigation and reporting workload remained high enough that we eventually stopped reporting later cases systematically.

The source count alone does not explain those false positives. Without insight into each IP entry’s origin, rationale, and reassessment, we could not establish their cause reliably. For a blocking feed deployed broadly across customer firewalls, the exception and support workload we observed was too high for us. Q-Feeds may still be useful for monitoring or investigation; our assessment concerns blocking in our environments.

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

For transparency: this is my personal blog, and I receive no personal commission. My employer is, however, a Cybora reseller and obtains discounted licenses to resell at a margin. That commercial relationship is relevant context for my recommendation. Our selection was driven by the experience from the comparison described here, not by the reseller terms.

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.

Production networks complement artificial sensors with different services and traffic profiles. That does not establish automatic superiority: other providers also use production telemetry. The additional sources identified and their observed behavior were more informative for our assessment.

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 between different websites at the same address. We therefore include these cases in operational false positives or exception workload. Where technically possible, an exception should be restricted to the required service and affected users and reviewed again. Allowing the entire IP would also restore access to other content on the same infrastructure. The single support interaction helped clarify this case but does not establish general response times.

The output of this processing is technically simple: an HTTPS address and a list. Retrieval can be configured in minutes on supported platforms. Responsible enforcement additionally requires validation against your own traffic.

STIX and TAXII Are Not the Same as a Blocklist

STIX and TAXII are often mentioned together in threat intelligence, but they serve different purposes.

STIX, Structured Threat Information Expression, is a structured data model. It can describe not only an IP address but also malware, campaigns, threat actors, attack techniques, observations, time periods, confidence levels, and relationships between those objects. It lets an analyst express why an indicator matters and the context in which it was observed.

TAXII, Trusted Automated Exchange of Intelligence Information, is a protocol for exchanging cyber-threat-intelligence data over HTTPS. Put simply, STIX describes the content, while TAXII describes the transport or API.

That context is valuable to a threat intelligence platform, SIEM, or SOC. For a fast IP lookup, a firewall often needs only an address set derived from that information. It periodically retrieves the indicators and checks traffic against the locally held set; the exchange format is not processed again for every packet. STIX/TAXII and a TXT list therefore differ mainly in information richness and integration. Structured threat intelligence can supply focused, simple lists for perimeter enforcement.

What a Threat Feed Cannot Do

The measurement example and the IP coverage assessed here concern IPv4. That reflects the environments I primarily manage, but says nothing about IPv6 coverage. Anyone also publishing services over IPv6 needs to verify their filtering separately; an IPv4 list does not cover 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