AbuseIPDB alternatives: how its free blocklist compares with live honeypot data

AbuseIPDB is where most administrators look when an unknown IP address hits their server. Thousands of users report attacking addresses, AbuseIPDB scores each one, and a free account gets an API key and a downloadable blocklist.

We run Whatoblock, a network of 224 honeypot sensors in 39 countries that records the addresses attacking it, and we publish blocklists built from that traffic. To compare the two, we downloaded AbuseIPDB's free blocklist twice on 27 October 2026, three hours apart, and again on 29 October, ran 1.996 lookups through its API on 27 and 29 October, and matched everything against what our sensors recorded in the 31 days before each download, with our first sighting of each address going back to 1 August.

The two sources agree on the big, persistent attackers and differ almost everywhere else. AbuseIPDB's free list is a fast moving slice of the most reported addresses. Our data is broader and catches more short lived attackers.

The short version

• 7.947 of the 9.971 IPv4 addresses on AbuseIPDB's free list (80%) had attacked our sensors in the previous 31 days, and 7.942 of those had done so before AbuseIPDB's list window began.
• Only 1.787 addresses were on both free lists: 18% of AbuseIPDB's list and less than 2% of our free sample of 112.495.
• Of the 21.024 addresses that attacked our sensors during the reporting window AbuseIPDB's list covered, 3.603 (17%) were on it.
• 313 of 500 randomly chosen attackers from our last 7 days (63%) had at least one AbuseIPDB report in the past 30 days. The other 187 had none, and 126 of those attacked us on a single day.
• When both sides caught a new attacker, they usually did so within hours of each other, and AbuseIPDB was first more often. 116 of 383 recent attackers (30%) had no AbuseIPDB report in a whole year.
• The results held two days later: on a fresh list from 29 October, 81% of the addresses had attacked our sensors, and 23% of our attackers in the same reporting window were on it.
• Three hours after our first download, 5.397 of the list's 10.000 entries had been replaced. Two days later, about half of a fresh list had also been on the 27 October lists.
• AbuseIPDB works well for lookups and its free list for the most reported attackers. A list built from live attack traffic adds broader coverage.

What the free AbuseIPDB plan gives you

AbuseIPDB's pricing page and API documentation list these limits:

The free blocklist uses a fixed minimum confidence score of 100. Choosing a lower minimum, or filtering by country, needs a subscription. The list is sorted by confidence score, then by the most recent report, and far more than 10.000 addresses score 100, so the free list ends up being the 10.000 most recently reported ones.

Our three downloads show what that means in practice:

Each list covered under one hour of reports, a reporting window of 55, 52 and 56 minutes, and its newest report was 34, 49 and 4 minutes old when we downloaded it. 4.603 addresses (46%) were on both 27 October lists, and every one of them had been reported again between the two downloads. The other 5.397 had been replaced. The 29 October list shared 4.930 of its 10.000 entries (49%) with the two lists from 27 October, so about half of the addresses on the list on a given day were still being reported two days later. A download taken 14 minutes after the first one, at 15:05 UTC, was identical to it entry for entry, so the list is rebuilt periodically rather than on every request.

That keeps the list current, and it also means a list downloaded once a day reflects under an hour of reports.

Whatoblock and AbuseIPDB side by side

We compared the two in both directions, free list against free list and full data against full data. Our side uses the same 31 day window as our blocklists.

And from AbuseIPDB's full database, using its lookup API:

Coverage in both directions, first AbuseIPDB download. Each bar names its base.

All three downloads, on two different days, give almost the same picture, so the results are not a fluke of one hour or one day. Four out of five addresses on AbuseIPDB's list had already attacked our sensors, usually for weeks. In the other direction, about four out of five addresses attacking our sensors in a given reporting window were not on the list, and more than a third of a random sample had no report in AbuseIPDB's database at all. The free lists barely overlap, because ours is built from Telnet and RSYNC scanners and AbuseIPDB's from the most recently reported addresses.

Finding 1: most of AbuseIPDB's list had been attacking us for weeks

The free list held 9.971 IPv4 and 29 IPv6 addresses, and we compared the IPv4 part. The 7.947 listed addresses our sensors saw in the 31 days before the first download attacked our sensors on a median of 19 of the 31 days, and 3.742 of them on 20 days or more. 5.311 (67%) had first reached our sensors before that 31 day window began, 3.936 of them in August.

They were also widespread. They reached a median of 102 of our 224 sensors, mostly with SSH logins (3.679 addresses) and web requests (2.313), and 3.603 of them also attacked our sensors during the reporting window AbuseIPDB's list covered. 446 belong to scanning projects our system recognises as research. Whether to block those is a policy decision, and many administrators do.

2.024 listed addresses had not reached our sensors in those 31 days, and 1.704 had not reached them at any time since 1 August. AbuseIPDB users also report abuse our sensors are not built to see, such as comment spam and mail abuse, which explains part of that gap.

Finding 2: in the same reporting window, 17% of our attackers were on the free list

A fair test compares the same reporting window on both sides. From 13:22 to 14:17 UTC, the 55 minutes the first list covered, 21.024 addresses attacked our sensors, and 3.603 of them (17%) were on the list. The second download, three hours later, gave 21%, and a fresh download two days later gave 23%.

The overlap depends strongly on what the attacker was doing:

Addresses attacking our sensors in the reporting window the first list covered, by what each mainly did.

SSH attackers made up the largest share of the overlap, and their share moved the most between days: 42% were on the first list and 2.037 of 2.896 (70%) on the 29 October list. Probes against remote access tools and cryptocurrency nodes were almost never on the list.

A 10.000 entry list cannot hold every attacker of a reporting window, so an address missing from the list may still be known. We looked up 296 of the attackers from that window that were not on the list: 219 of them (74%) had reports in AbuseIPDB's database, and 68 had the maximum score of 100 but had not made it into the free list.

Finding 3: AbuseIPDB knows most of our attackers, but not the short lived ones

To test the database rather than the list, we looked up 500 addresses chosen at random from the 304.647 that attacked our sensors between 20 and 26 October, using the API's 30 day report window.

The 63% has a margin of error of about 4 percentage points either way.

The more often an address attacks, the more likely someone reports it and the higher its score climbs. Our 200 most widespread scanners had a median of 707 reports each. Most addresses we saw on a single day had no report at all, and very few reached a score high enough for a strict blocklist. Those addresses are common: 554.508 of the 856.893 addresses that attacked our sensors from 27 September to 26 October (65%) did so on a single day.

AbuseIPDB also marks some addresses as whitelisted. 48 of the 996 addresses we looked up carried that flag, many of them known scanning services.

Finding 4: who saw them first

For addresses known to both sides, we compared AbuseIPDB's first report in the past year with our first sighting. To compare like with like, we only count cases where both dates fall on or after 1 September.

In our lookups, AbuseIPDB returned at most 100 reports per address, mostly from the few days before the lookup, although its documentation allows up to 10.000. Every address with more than 100 reports in the year came back with exactly 100, so for those we could not see when reporting began. That rules out the addresses on its free list: 553 of the 617 we checked came back cut off.

It works for ordinary attackers. Of the 500 random attackers from Finding 3, we first saw 383 on or after 1 September, and we looked them up again with a one year report window. For the 17 of them whose history came back cut off, we fetched their oldest report from AbuseIPDB's report history, so every one of the 383 could be timed:

Percentages are of the 383 and are rounded.

383 attackers we first saw on or after 1 September, looked up with a one year report window.

Where both sides caught an address after 1 September, they usually did so within hours of each other, with a median gap of about 12 minutes. AbuseIPDB was first more often, 61 times against our 39, and the gaps of a day or more also favoured it, 40 against 20. The larger difference is in the first row: 116 addresses that attacked our sensors had no AbuseIPDB report in a whole year.

What only our sensors see

The 187 sampled attackers with no AbuseIPDB report in 30 days show where a sensor network adds the most:

126 of the 187 attacked our sensors on a single day. Proxy hunters, remote access probes and short lived scanners rarely hit the kind of servers whose owners report to AbuseIPDB, but they do reach a honeypot that answers on those services.

What this means for your firewall

AbuseIPDB is strong on persistent, widely reported attackers. If an address has been attacking for days, it is very likely reported and highly scored, and a lookup is a good way to judge a single address in a log.

The free list is a live slice of under an hour of reports. Using all 5 daily downloads and keeping the union for a few days gives a more stable list.

Single day attackers, proxy hunters, remote access probes and cryptocurrency node scans were rarely on the free list or in the database, so those need another source. Bulletproof hosts make this worse by spreading attacks over whole ranges: in the Virtualine takedown, 253 addresses of one range scanned our sensors with only about 44 events each. A crowd reported database and a sensor network see different parts of the same traffic, and the small overlap between the two free lists shows how much each one adds.

AbuseIPDB alternatives

No single list is complete, so most teams combine two or three. These are the common options:

• CrowdSec: an open source agent that blocks attackers locally and shares signals, with a community blocklist built from those signals.
• Spamhaus DROP: a small list of hijacked and criminal netblocks, designed to be blocked with very few false positives.
• FireHOL IP lists: aggregates many public lists into levels, from conservative to aggressive.
• blocklist.de: addresses reported by servers running fail2ban and similar tools.
• IPsum: a daily aggregate that ranks addresses by how many public lists include them.
• Whatoblock: lists built from our honeypot sensors. The free sample covers scanners seen on Telnet and RSYNC over the last 31 days and held 112.495 addresses at the time of our comparison, in 11 formats including MikroTik, Check Point, Wazuh and Zeek. Paid plans add more protocols, industries and threat categories, updated hourly.

These lists cover attacking addresses. For malware command and control servers, our comparison of URLhaus and ThreatFox covers the main free feeds.

How to download the AbuseIPDB blocklist

With a free API key from your AbuseIPDB account, this returns the plain text list:

curl -G https://api.abuseipdb.com/api/v2/blacklist \
  -d limit=10000 -d ipVersion=4 \
  -H "Key: YOUR_API_KEY" -H "Accept: text/plain"

The free plan allows 5 downloads a day, so schedule them a few hours apart rather than all at once.

Frequently asked questions

Is AbuseIPDB free?

Yes. The free Individual plan includes 1.000 IP lookups a day and 5 blocklist downloads a day, each with up to 10.000 addresses at a confidence score of 100. Paid plans start at 25 USD a month.

How often does the AbuseIPDB blocklist change?

Within hours. Each of our downloads covered under one hour of reports, and three hours after the first one, 54% of its entries had been replaced. Two downloads 14 minutes apart were identical, so the list is rebuilt periodically. A list downloaded two days later still shared 49% of its entries with the earlier lists.

What does the AbuseIPDB confidence score mean?

It is AbuseIPDB's rating, from 0 to 100, of how confident it is that an address is abusive, based on the reports it has received.

Does AbuseIPDB catch attackers faster than a honeypot network?

For attackers both sides caught after 1 September, the first sightings were usually within hours of each other, and AbuseIPDB was first more often, 61 times against 39. 30% of the recent attackers we checked had no AbuseIPDB report in a year.

Is there a free alternative to AbuseIPDB with a bigger list?

Several free lists are larger, including FireHOL's aggregated levels and Whatoblock's free sample with 112.495 addresses. Only 1.787 addresses were on both the AbuseIPDB and Whatoblock free lists, so combining a crowd reported source with one built from live attack traffic covers more than either alone.

Should I block every address on an AbuseIPDB list?

For inbound traffic to servers that do not serve the public, usually yes. For public websites and mail servers, check the list against your own traffic first, because some listed addresses are shared hosting, VPN exits or research scanners.

About this data

• Our data: 224 honeypot sensors in 39 countries. For each AbuseIPDB download, every address that attacked our sensors in the 31 days before it, the same window our blocklists use. Our first sighting of each address goes back to 1 August 2026. The random lookup sample and the single day figures use the 30 full days from 27 September to 26 October 2026.
• Whatoblock free sample: addresses seen on Telnet or RSYNC in the 31 days up to each download, counted the same way as the live feed.
• AbuseIPDB blocklist: downloads from /api/v2/blacklist with the free plan defaults (limit 10.000, confidence minimum 100), downloaded at 14:51:45, 15:05:59 and 18:06:39 UTC on 27 October 2026 and at 16:21:39 UTC on 29 October 2026.
• AbuseIPDB lookups: 996 addresses checked with /api/v2/check and a 30 day report window on 27 October 2026. 500 were a random sample of the 304.647 addresses that attacked our sensors from 20 to 26 October, 200 were our most widespread scanners and 296 were attackers from the first list's reporting window that were not on the free list.
• Timing lookups: 1.000 addresses checked with /api/v2/check, the verbose option and a 365 day window on 29 October 2026: 617 addresses from the first free list download that we first saw on or after 1 September, and the 383 addresses of the random sample that we first saw on or after 1 September. In our responses the lookup returned at most 100 reports per address, although the documentation allows up to 10.000. For the 17 sampled addresses that came back cut off, the oldest report came from /api/v2/reports on 30 October 2026, which pages through the whole report history.
• What counts as seen: an address counts as seen by our sensors if it sent traffic to at least one sensor in the window. Research scanners are included and reported separately.
• Limits: each blocklist download is a snapshot. Our sensors see attacks on the services they emulate, so abuse such as comment spam or mail abuse, which AbuseIPDB users also report, is outside our view.