Check IP reputation: how often free blocklists agree

Free IP reputation lists rarely agree with each other. On 21 October 2026 we downloaded eight openly published blocklists in the same second and checked them against one another. Of the 42,830 addresses that the Tor exit list, Feodo Tracker, CINS Army and blocklist.de name one by one, 40,133 (93.7%) appeared on exactly one of the six primary lists in this study. None appeared on more than three.

That matters to anyone who runs a lookup to check IP reputation for a proxy exit, a server or a scraper address. A clean result from one list says little about the next one. A hit on one list is, more than nine times in ten, that list’s opinion alone. Below is how we measured it, what surprised us, and a short script that runs the same check on your own addresses.

01The eight lists and what a listing means

Each list answers a different question, and the overlap figures only make sense once that is clear. Six are primary sources that make their own listing decisions. Two are aggregators built from other lists, so they overlap with their inputs by construction and are kept out of the agreement counts.

The file dates matter. We fetched all eight at 19:49:09 UTC, but the FireHOL file on GitHub had been built at 06:22 and IPsum’s at 01:01. The two aggregators were roughly 13 and 19 hours older than the lists they include, and that gap shows up in several numbers below.

The Feodo Tracker date is not a typo. Its blocklist held five addresses under a header reading “Last updated: 2026-03-04 14:28:39 UTC”, while the server’s Last-Modified header said 30 June 2026. The project’s blocklist page says its datasets are currently empty. Five addresses cannot carry an agreement statistic, so Feodo appears in the tables for completeness and nowhere in the conclusions.

02Method

Each list was downloaded once with curl at 19:49:09 UTC on 21 October 2026, from the URLs given in the dataset. We kept the response headers and recorded a SHA-256 hash of every file. Spamhaus asks that automated DROP downloads be at least an hour apart and says once a day is enough for most users. We applied one download per list to every source.

Only IPv4 was compared. blocklist.de contained 513 IPv6 lines, which were skipped; no other list had any. Exact duplicates were dropped: the DROP file carried 1,688 records, one of them a repeat.

The sample used Python’s random.Random with the seed 20261021. For each list in a fixed order, up to 500 entries were drawn without replacement, and one address was then picked uniformly inside each drawn entry. For a list of single addresses that is simply the entry. Feodo Tracker (5 entries) and DShield (20) were used in full. A control group followed: random 32-bit values, rejecting IANA special-purpose and multicast space, until 1,000 public addresses were kept. 153 of 1,153 draws were rejected, or 13.3%, close to the 13.8% of the IPv4 space those ranges occupy.

That gives 4,025 draws and 4,016 distinct addresses. Every one was checked against all eight lists: an exact match for single addresses, containment for netblocks. “Agreement” on this page means that another primary list also names the address or covers it with a listed netblock.

# The sampling step, exactly as run (Python 3.15.0, standard library only)
rng = random.Random(20261021)
for name in ["spamhaus_drop", "firehol_level1", "tor_exits", "feodo",
             "dshield_block", "cins_army", "blocklist_de", "ipsum"]:
    entries = parsed[name]   # IPv4 (start, end) pairs in file order, duplicates removed
    for i in rng.sample(range(len(entries)), min(500, len(entries))):
        start, end = entries[i]
        draws.append((name, rng.randint(start, end)))
while len(control) < 1000:
    x = rng.getrandbits(32)
    if x not in special_purpose:   # IANA special-purpose registry plus 224.0.0.0/4
        control.append(x)

Two controls guard the result. The positive control: every sampled address must be found on the list it came from, and all 3,025 list draws were (500 of 500 for each list sampled at 500). The second is a full-list check. For the four primary lists that name single addresses we also compared the entire lists, with no sampling, and every full-list figure fell inside the sample’s 95% interval. The comparison is further down.

03Finding 1: most listed addresses are on one list only

Read the bottom row first. Six of 1,000 random public addresses were flagged by a primary list, all six by DROP. Spamhaus DROP on its own covers 14,810,880 of the 3,702,258,688 public IPv4 addresses, which is 0.40%, so a rate near half a percent is what chance alone produces. Any list’s hit rate on your own addresses should be judged against that floor.

Against it, the attack feeds agree with each other only a little. CINS Army had the highest rate, 13.2%, and most of that came from DShield’s networks rather than from a second attack feed. blocklist.de, the largest primary list here, had 3.4%. Spamhaus DROP agreed with nobody: one of its 500 sampled addresses was on another primary list.

The exact full-list picture is the same. Of 42,830 distinct addresses named individually by the Tor exit list, Feodo Tracker, CINS Army and blocklist.de, 40,133 were on one primary list, 2,624 (6.1%) were on two, and 73 (0.17%) were on three.

04Finding 2: the two attack feeds barely overlap

CINS Army and blocklist.de both list addresses seen attacking something. They are the closest pair in this study by purpose, and they shared 351 addresses out of 41,658 between them.

351 shared addresses is 2.3% of CINS Army and 1.3% of blocklist.de. The likeliest reason is that the two run different sensors: CINS scores traffic seen by Sentinel IPS devices, while blocklist.de collects reports from its users’ servers. Each sees the attackers that happen to touch its own sensors.

CINS overlapped far more with DShield. 1,522 CINS addresses, 10.1% of the list, sat inside DShield’s 20 networks, which hold 5,120 addresses between them. CINS therefore named 29.7% of all the addresses in DShield’s top 20. The file’s network-name column shows hosting and measurement operators among them rather than consumer ISPs: HURRICANE three times, GOOGLE-CLOUD-PLATFORM once and INTERNET-MEASUREMENT once.

The surprise ran the other way with DROP. Not one of CINS Army’s 15,000 addresses fell inside a DROP netblock, while 600 of blocklist.de’s did.

The IPsum rows look higher only because IPsum imports both feeds. IPsum’s count includes the source list itself. So when 13,002 of blocklist.de’s 27,009 addresses (48.1%) had a count of 1, blocklist.de was usually the only one of IPsum’s 30-plus sources to list them. A further 4,770 blocklist.de addresses (17.7%) were not in IPsum at all, which is what a 19-hour-old snapshot of a 48-hour list looks like.

05Finding 3: 97% of FireHOL level1 never routes on the public internet

FireHOL describes level1 as suitable for basic protection on all internet-facing servers, and its header gives the size: 611,044,545 addresses. Almost all of that is space no public host can use.

The first row is 224.0.0.0/4 multicast, 240.0.0.0/4 reserved space, the private ranges, loopback and the documentation blocks. The third row can only come from the fullbogons and feodo inputs, and Feodo lists single addresses, so it is effectively unallocated public space. Traffic should not arrive from any of it, and none of it says anything about reputation.

For a real public address, then, a level1 hit is mostly a DROP hit. DROP is 80.75% of level1’s 18,335,937 public addresses, and in the control group 6 of the 7 random addresses that level1 flagged were DROP addresses. The sample drawn from level1’s 4,627 entries told the same story from the other side. 159 of 500 landed in DROP space and 339 in public bogon blocks on no primary list. One landed on a Feodo address and one in a DShield network.

Because DROP and DShield are inputs to level1, they also work as a freshness check. DROP should sit inside level1 completely, and 14,806,784 of its 14,810,880 addresses did. The 4,096-address gap fits DROP’s update at 14:04 landing after FireHOL’s 06:22 build. DShield was further off: only 13 of the 20 networks in our 18:45 copy were in FireHOL’s copy, whose source file was dated 05:44. Seven of the top 20 were replaced in about 13 hours.

06Finding 4: Tor exits and proxies are listed for what they are

This is the result that matters most for proxy users. IPsum held 1,195 of the 1,222 Tor exits, 97.8%. Only 90 exits (7.4%) were on any of the five other primary lists: 55 on blocklist.de, 37 inside DROP netblocks, one inside a DShield network, none on CINS Army.

The reason is in IPsum’s upstream. IPsum is compiled from the feeds of the Maltrail project, and Maltrail’s feed modules, read at commit d88331d, include two for Tor. One labels every running relay bad reputation (tor node); the other labels exits tor exit node (suspicious). Two more import public open-proxy lists under the label proxy (suspicious). An address can therefore score on an aggregated reputation list purely for being a Tor relay or for once appearing on a public proxy list.

183 exits had a count of 3 or more, a level that IPsum’s own documentation uses as its example of a stricter threshold. A score built by counting lists rewards being listed for many reasons, and some of those reasons describe what an address is rather than what it did.

The 37 exits inside DROP were the other surprise. DROP is meant for networks that should not be routed at all, yet on 21 October 37 Tor exits were running from 17 distinct DROP netblocks.

Shared exits work the same way outside Tor. An address in a proxy pool carries what its other users did, plus any label attached to the kind of address it is. Rotating through more addresses spreads that history around rather than removing it; our guide to rotating and sticky sessions covers the trade-off. Reputation is also only one reason a target refuses a request, and the response code usually tells you which; see 403 vs 407 vs 429. A clean address with a library’s default TLS handshake can be blocked before reputation is ever consulted.

07The control group in full

None of the address-level lists flagged a random public address, which is expected: together they name well under 200,000 addresses out of 3.7 billion. Only the two large netblock lists cover enough space to be hit by chance, and they were hit at about the rate their size predicts.

08Sample against full list

Where a list names single addresses we could compare it in full as well as by sample. All of these full-list values fall inside the sample’s 95% interval, which is the evidence that 500 draws per list were enough.

09How to check an IP’s reputation against these lists

The quickest honest check is to look an address up in several lists of different kinds and read each hit for what that list measures. Download the files once, then query them locally as often as you like. That keeps you inside each project’s download guidance and gives every lookup the same snapshot.

# fetch.sh: one download per list into an empty directory
D=${1:?empty dir}; mkdir -p "$D"; cd "$D"
fetch() { curl -sS -L --max-time 60 -D "$1.headers" -o "$1.body" "$2"; }
fetch spamhaus_drop_v4 https://www.spamhaus.org/drop/drop_v4.json &
fetch firehol_level1  https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level1.netset &
fetch tor_exits       https://check.torproject.org/torbulkexitlist &
fetch feodo           https://feodotracker.abuse.ch/downloads/ipblocklist.txt &
fetch dshield_block   https://feeds.dshield.org/block.txt &
fetch cins_army       https://cinsscore.com/list/ci-badguys.txt &
fetch blocklist_de    https://lists.blocklist.de/lists/all.txt &
fetch ipsum           https://raw.githubusercontent.com/stamparm/ipsum/master/ipsum.txt &
wait

#!/usr/bin/env python3
"""check_ip.py: look IPv4 addresses up in the files fetch.sh downloaded.
Usage: python3 -I check_ip.py <raw_dir> <ip> [<ip> ...]   (tested on Python 3.15.0)"""
import bisect, ipaddress, json, os, sys

FILES = {
    "Spamhaus DROP": "spamhaus_drop_v4.body", "FireHOL level1": "firehol_level1.body",
    "Tor exits": "tor_exits.body", "Feodo Tracker": "feodo.body",
    "DShield top 20": "dshield_block.body", "CINS Army": "cins_army.body",
    "blocklist.de": "blocklist_de.body", "IPsum": "ipsum.body",
}

def ranges(path):
    out = []
    for line in open(path, encoding="utf-8", errors="replace"):
        line = line.strip()
        if not line or line.startswith("#"):
            continue
        if line.startswith("{"):                       # Spamhaus JSON lines
            line = json.loads(line).get("cidr", "")
        if not line:
            continue
        tok = line.split()
        try:
            if len(tok) > 2 and path.endswith("dshield_block.body"):
                lo, hi = (int(ipaddress.IPv4Address(t)) for t in tok[:2])
            else:
                n = ipaddress.ip_network(tok[0], strict=False)
                if n.version != 4:
                    continue
                lo, hi = int(n.network_address), int(n.broadcast_address)
        except ValueError:
            continue
        out.append((lo, hi))
    merged = []                       # merge overlaps: lists can nest a block inside another
    for lo, hi in sorted(out):
        if merged and lo <= merged[-1][1] + 1:
            merged[-1][1] = max(merged[-1][1], hi)
        else:
            merged.append([lo, hi])
    return merged, [lo for lo, _ in merged]

def listed(x, table):
    iv, starts = table
    i = bisect.bisect_right(starts, x) - 1
    return i >= 0 and iv[i][1] >= x

raw = sys.argv[1]
tables = {name: ranges(os.path.join(raw, f)) for name, f in FILES.items()}
for ip in sys.argv[2:]:
    x = int(ipaddress.IPv4Address(ip))
    hits = [name for name, t in tables.items() if listed(x, t)]
    print(f"{ip:<16} {len(hits)}/{len(FILES)}  {', '.join(hits) or 'on none of these lists'}")

Output against the 21 October files, for a Tor exit, an address from the RFC 5737 documentation block and a public DNS resolver:

$ python3 -I check_ip.py raw-20261021 171.25.193.25 192.0.2.1 8.8.8.8
171.25.193.25    2/8  Tor exits, IPsum
192.0.2.1        1/8  FireHOL level1
8.8.8.8          0/8  on none of these lists

The first line is the Tor result from Finding 4 in miniature: the IPsum hit is the Tor label, not a second opinion. The second shows FireHOL level1 flagging a block that exists only for documentation.

When you read a result, three questions do most of the work. What does this list measure: a network judged criminal, a host seen attacking, or simply a Tor relay? How old is the file? And is it an aggregator, whose count may include the same evidence twice? If you need the network an address belongs to before deciding, its ASN is usually the next lookup.

10Reproducing this

Run sh fetch.sh raw/, then python3 -I measure.py raw/ out/. The measurement script uses the standard library only and is included in full in the JSON download, as is fetch.sh. The lists change constantly, so a fresh download will give different numbers. With the same eight files (their SHA-256 hashes are in the JSON) the seed reproduces the same 4,025 draws exactly. We ran it twice and both runs wrote a CSV with the hash c74e5d1b97949c80 (first 16 hex digits).

11Download the data

One row per draw: 4,025 rows, 14 columns. Each row says which list the address was drawn from, whether each of the eight lists flags it, its IPsum count, and how many other primary lists flag it. The JSON adds the method, the seed, every source’s URL, hash, entry count, file date and terms, the full summary figures and both scripts. Licensed CC BY 4.0 for this compilation: reuse it with a link to this page.

• ip-reputation-agreement-measured.csv, 4,025 rows, 14 columns
• ip-reputation-agreement-measured.json, the same rows plus method, source metadata, summary and scripts