Carpathian Threat Intelligence Feeds

Threat intelligence feeds are lists of things that recently attacked someone, mostly IP addresses, domains, and URLs, published at a fixed address so your firewall can fetch them on a schedule and block what's on them. A provider watches attacks, decides which sources are hostile, cleans the list so it won't block anything legitimate, and rebuilds it every hour or so. Your firewall, WAF, or SIEM pulls the new copy and turns each entry into a deny rule or an alert.

Carpathian's whole process is: observe, decide, clean, publish, pull. This guide walks through each step, what separates a feed you can trust in production from one that locks out your own customers, and how to load a free feed into Palo Alto, FortiGate, pfSense, OPNsense, Cloudflare, AWS WAF, and nginx.

A blocklist sits on top of a server that's already locked down, not in place of one. If you run your own machine, initial server setup and hardening on Ubuntu closes the doors a feed can't, and it comes first.

What is a threat intelligence feed?

A threat intelligence feed is a machine-readable list of indicators of compromise (the addresses, domains, URLs, or file hashes tied to recent attacks) that a security tool downloads and acts on automatically. The list isn't the valuable part. What you're getting is that someone else saw the attack first, so your firewall can drop the source before it reaches you.

Feeds differ in what they carry:

• IP blocklists are the simplest, one address or range per line. Almost every firewall can read one directly.
• Domain and URL feeds target phishing and malware hosting, and DNS filters and web proxies are what usually consume them.
• File hash feeds identify known malware files, and endpoint tools read them rather than firewalls.
• Probed path lists record the URLs scanners request, such as admin panels and backup files. A web server can match them no matter which address the request comes from.

People use "IP blocklist" and "threat intelligence feed" interchangeably, but there's a difference. A blocklist is a flat list of addresses. A feed carries context with each entry: when it was first and last seen, what it did, how often, and which system flagged it. The flat list is what your firewall loads. The context is what you read when an entry looks wrong.

Where does threat intelligence feed data come from?

Every feed starts with someone watching attacks. The three common sources are honeypots, decoy systems that only attackers ever touch; production infrastructure, where a provider records the scanning and abuse aimed at its own servers; and community reporting, where many users submit the addresses that attacked them. Each one trades volume against accuracy differently.

• Honeypots produce clean signal, since nothing legitimate should connect to them, but they only see attackers who happen to find them.
• Production infrastructure sees the scanning that hits ordinary web servers every day, which is the traffic you're most likely to face. The provider has to keep its own customers' requests out of the list.
• Community reports cover the most ground and carry the most noise, because each report is only as careful as the person who sent it.

Detection itself comes from systems you probably already run: an intrusion detection system that bans an address after repeated malicious requests, a burst of error responses from one source probing for pages that don't exist, or a run of failed logins against SSH. A feed built from several of these is harder to fool than one built from a single sensor, because an address has to look hostile to more than one detector.

How is an IP blocklist built from raw detections?

Raw detections aren't a blocklist yet. A provider merges repeat sightings into one entry per address, strips out anything known to be legitimate, sorts the result so the worst offenders come first, and renders it into formats firewalls read. Each step exists because skipping it causes a specific failure for whoever loads the list.

1. Deduplicate. One address can trip three detectors in an hour. A careful feed merges those into a single row and keeps the strongest verdict, so a temporary ban and a permanent ban for the same source don't become two contradictory entries.
2. Remove known-good sources. Search engine crawlers, uptime monitors, payment processors, and the provider's own monitoring all generate odd-looking traffic, and an allowlist removes them before publishing. A check for private and reserved ranges, such as 10.0.0.0/8, belongs here too. Those addresses show up when a proxy reports a client address wrong, and if one slips into a list it blocks the consumer's own network.
3. Order by severity. Firewalls and cloud services cap list sizes. Sorting by event count means a consumer who has to truncate keeps the heaviest attackers and drops the one-time visitors.
4. Render safely. A list that ends up in a live firewall config has to be strict. Entries that don't parse as valid addresses get dropped rather than escaped, and config files meant to reload on a schedule are written so a second load replaces the list instead of doubling it.
5. Publish on a schedule. The list is rebuilt at a fixed interval and served at the same URL, so consumers pull it without anyone uploading anything.

Expiry matters just as much. An address that scanned someone six months ago may be a different customer's cloud server today. A feed that never drops old entries grows forever and blocks a little more legitimate traffic every month.

How do firewalls use a threat intelligence feed?

Most firewalls fetch a feed by URL on a schedule and turn every entry into a match condition you reference from a deny rule. You set the URL and refresh interval once. From then on the firewall keeps the list current on its own, and your policy refers to the list by name rather than to individual addresses.

Here's how that looks on common platforms:

• Palo Alto Networks calls it an External Dynamic List. Create one of type IP List, point it at a plain text URL with one address per line, set it to repeat hourly, and use it as the source in a deny policy.
• FortiGate calls it an external threat feed, under Security Fabric, External Connectors. An IP Address feed takes the same plain text list and a refresh rate in minutes, and you use it as a source address in a deny policy.
• pfSense with pfBlockerNG takes the URL as an IPv4 or IPv6 feed and builds the aliases and rules from it.
• OPNsense uses a URL Table (IPs) alias, which you reference from a firewall rule like any other alias.
• Cloudflare doesn't fetch lists itself. You create an IP List, replace its contents through the API from a scheduled job, and match ip.src against it in a WAF custom rule.
• AWS WAF doesn't fetch either. You create one IP set per address family and update it from a scheduled job with the CLI.
• Linux hosts load the list into an nftables set, so the kernel drops matching packets before any service sees them.
• SIEM platforms ingest the CSV or JSON version as a lookup and raise an alert when a listed address appears in your logs, which is useful even when you don't want to block.

Size limits matter more than most people expect. A Cloudflare account on the Free, Pro, or Business plan can hold 10,000 list items across all of its custom lists, and AWS WAF allows 10,000 addresses in CIDR notation per IP set. When a feed holds more than that, you're cutting it, and the order the provider sorted it in decides what you keep.

Can you block scanners without knowing their IP address?

Yes, by matching what they ask for instead of where they come from. Automated scanners request the same paths over and over: admin login pages, exposed .git directories, backup archives, and endpoints with known vulnerabilities. A list of those paths lets your web server refuse a scanner on its first request, from an address no blocklist has seen yet.

On nginx, a path list usually ships as a map block that sets a variable when the request URI matches. One line in your server block then closes the connection:

if ($threat_path) { return 444; }

Status 444 tells nginx to close the connection without sending a response, so the scanner gets nothing back to fingerprint. Two cautions apply. Never block a path your own application serves, and test the map on a staging server first, because a path that looks hostile on one site can be a working route on another. If you're setting up nginx for the first time, deploying a web app with Nginx and Docker covers the server block this line goes in.

Are free threat intelligence feeds good enough?

For blocking opportunistic scanning and brute-force attempts, usually yes. Free feeds from honeypot networks, open source projects, and infrastructure providers catch most of the automated traffic that hits small and mid-sized servers. Where they fall short is targeted attacks, context, and support: nobody is on call when an entry blocks your biggest customer.

Before you trust any feed, free or paid, check these:

• Source. Does the provider say where the data comes from? A feed that won't say can't be evaluated.
• Update interval. Hourly or faster is typical for IP lists. A list rebuilt weekly is mostly history.
• Expiry. Entries should age out. Ask how long an address stays listed after its last sighting.
• False positives. Is there a way to request a removal, and does a person read it?
• Allowlisting. Does the provider strip known-good infrastructure and private ranges before publishing?
• Formats. Is there a plain list your firewall reads directly, or are you writing a converter?
• License. Some free feeds forbid commercial use or redistribution. Read the terms before you build a product or a managed service on one.
• Ordering. If your platform caps list size, is the feed sorted so truncation keeps the worst offenders?

A feed that passes all eight is one you can put in front of production. One that fails on source or false positives belongs in alert mode, if it belongs anywhere.

What can go wrong when you block a threat feed?

The common failure is blocking someone you need. Cloud and residential addresses get reassigned, so an address that scanned a provider last week can belong to a new tenant today, and shared addresses, like a mobile carrier's gateway, can put thousands of people behind one listed address. The fix is process, not a better list.

• Start in alert mode. Load the feed into your SIEM or a log-only rule for a week and see what it would have blocked.
• Put an allow rule first. Partners, payment providers, monitoring services, and your own offices should match an allow rule that sits above the blocklist.
• Log every block. When someone tells you they can't reach your site, you want the answer in one search.
• Know how to back out. Keep the provider's removal process bookmarked, and make sure you can pull the feed out of your policy in one change.

A blocklist isn't a defense on its own, either. It cuts noise and stops the laziest attacks, and it does nothing about a vulnerable plugin, a leaked key, or an attacker on a fresh address. Pair it with patching, strong authentication, and a hardened server, and a CDN in front of anything public, which what a CDN is and when you need one explains. Then treat the feed as the layer that keeps your logs readable.

Where Carpathian fits

Carpathian publishes a free threat intelligence feed built from the attacks aimed at its own infrastructure. It contains an IP blocklist merged from web edge error bursts, intrusion detection bans, and SSH gateway bans, plus a list of the paths those scanners probe. Both are rebuilt hourly, sorted worst offenders first, cleaned of allowlisted and non-routable addresses, and published under CC BY 4.0 in formats for Palo Alto, FortiGate, pfBlockerNG, Cloudflare, AWS WAF, MikroTik, nftables, and nginx, with a form for requesting removals.

It reflects what attacks one provider's network, so it won't see a campaign aimed only at your industry, and it doesn't carry domains, URLs, or file hashes. Run it alongside a feed that covers those, and test it against your own traffic before you block on it.