blocklist-abuseipdb: confidence tiered IP lists for ipset and iptables

A repo of plain text lists, not a service

blocklist-abuseipdb is a repository of blocklists built from AbuseIPDB data with the provider's permission. The description is precise about scope: lists of the worst IPv4 and IPv6 offenders at roughly 99 percent confidence. What the repository offers is files, not an API and not a client library. The top level is a set of plain IPv4 files named after the window they cover, from `abuseipdb-s100-1d.ipv4` through `abuseipdb-s100-365d.ipv4`, plus `abuseipdb-s100-all.ipv4.gz` in compressed form. Alongside them sit `stats`, `db`, a `.cron` directory, a `package.json` and a `deno.json`. For a network engineer the appeal is direct: whatever consumes a list of addresses can consume this one. That could be `ipset`, `iptables`, a firewall appliance, or a logging pipeline, and the topic tags the repository carries name the usual suspects. The trade is that the repository pushes a data format and leaves interpretation, scheduling and enforcement to you.

Confidence tier and time window are the two axes

The naming convention encodes both dimensions, and the project spells it out: s100 means roughly 100 percent confidence lists. The time window is the number of days. The published statistics give the size of each file at the last check, which was 2026-10-20 at 13:40:10 UTC. The 1 day file held 52039 addresses, the 7 day file 76725, the 14 day file 94352, the 30 day file 129422, the 90 day file 262156, and the 365 day file 729977. The all file, which compresses to a single archive, covered 2413506 addresses. The progression is the whole point: a short window means only addresses that were reported very recently, a long window means addresses that anyone has reported at any point and nobody has cleared. The project says explicitly that the maximum 30 day file, or less, is the recommended usage, to avoid false positives. And it warns against the `abuseipdb-s100-all.ipv4` file, which is exposed only for statistical use.

The hall of shame and the heuristic that finds /24s

Beyond the flat lists, the repository carries two extras that are not just more addresses. The first is a Hall of Shame, published under `stats/hallofshame`, which contains lists of aggressive /24 subnets, with links that point at the corresponding AbuseIPDB check-block pages. The second is the method behind those entries: a smart heuristic based detection of aggressive /24 subnets. The distinction matters for how you read the numbers. A single address with a high confidence score is a report about one host. A /24 is 256 addresses, and a subnet that contains a scanner tends to contain infrastructure neighbours that were never reported at all. Blocking the wider block is cheaper to operate and risks blocking innocent hosts, which is the trade the project makes explicit with its caution about false positives. The hall of shame is a curated subset rather than a bulk export, so it should be treated as a separate decision from loading the main files.

Where the data comes from, and the free tier ceiling

The provenance is disclosed in detail, which is unusual and useful. The repository states that it uses the AbuseIPDB free forever plan, limited to five fetches per day and 1000 IP lookups, and that it also aggregates data from multiple publicly free and legal sources, each also on a free plan, to build a larger list. The package manifest shows how that fetching is carried out: the build pulls in a set of prebuilt binaries from the author's own repositories, including `curl`, `cidr-merger`, `sort-uniq`, `ip-public`, `grepip`, `daterange` and `pstats`, with the tooling declared as an ES module project requiring Node 18 or newer and pnpm 8.8.0.

  "type": "module",
  "private": true,
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=18"
  },

The sizes listed above are consistent with an aggregation step, since the free tier of a single source would not stretch that far. Credits go to AbuseIPDB, and the project asks readers to support that provider. The interesting operational detail is the five fetches per day ceiling, which is what forces the several-times-daily update to be efficient rather than exhaustive.

The repository squashes itself to stay small

The lists are updated multiple times per day, and the repository is continuously squashed to keep the size down. That single design decision explains the shape of the project. A git repository that accumulates every refresh as ordinary history would grow without limit, and a firewall operator cloning it would pay for that history every time. Squashing keeps the working tree at one copy of each list plus a compressed archive of the full set, which makes a plain fetch of the branch cheap. The cost is that history is not a log of what changed. If you need to know when a specific address entered a list, or diff yesterday against today, this repository does not give you that, and you have to keep your own copy of the previous state. The same applies to auditing: there is no release tag and no changelog to point at, only files whose contents move under the same name. The last push was on 2026-10-22.

Two warnings that decide whether this belongs in your firewall

The disclaimer block is the most consequential part of the documentation, and two of its points argue against using the data the way many people want to. The first is that IP blocking should be used with caution, and that firewalls should preferably apply rules on the incoming WAN side. The second is that IPv6 blocking is almost useless, because public IPv6 addresses may implement the SLAAC privacy extension, where the interface identifier is randomly generated and discarded after a configurable timeout. A v6 address on your blocklist is therefore rarely the address that will show up in a connection attempt. The project lists IPv6 among the offenders it tracks, but its own reasoning is that v6 filtering does not hold. Any plan that blocks v4 and v6 from the same file needs to be revised, because the v6 half is chasing addresses that rotate by design.

Licence, hosting and the parts the docs leave open

The licence for this repository is not stated, which is worth settling before you put the files into a product or a shared infrastructure. AbuseIPDB data is used with permission and the project asks for support of that provider, so the upstream terms apply to you as well. The repository itself is hosted on GitHub and the raw files are served from that host, which means your refresh job depends on that endpoint being reachable and reasonably fast from where your firewall runs. Documentation gaps are visible too. There is no documented command for loading a file into `ipset` or into a firewall rule, no documented refresh schedule beyond the statement that updates happen multiple times per day, and no documented procedure for testing a rule before enforcing it. The topics the repository tags include `ipset`, `iptables`, `netfilter` and `maltrail`, which points at the intended consumers, but the plumbing is left to the reader. The tree is data plus a build pipeline, and the operational layer you supply.

Editorial conclusion

Adopt blocklist-abuseipdb when you want a plain text file you can load into ipset or an iptables rule and refresh several times a day without building a pipeline. Do not adopt it for IPv6 blocking, since the project states that is nearly useless against SLAAC addresses, and do not treat the confidence tiers as verdicts. Before wiring it in, decide on the window length, the project advises 30 days or less, and check which of the listed source files your firewall tooling can actually consume.

Frequently asked questions

Official sources

1. borestad/blocklist-abuseipdb on GitHub
2. Issues
3. Project website
4. README