IPs republishes eight honeypot-fed blocklists hourly, and rewrites the history to do it

Eight named lists, and two of them are not threat lists at all

The repository is data with no code in it: a licence file, a readme, and a `Lists/` directory. The readme indexes eight lists, each linked by name, and the descriptions are where the useful detail sits. `Threats` is the main one, covering active threats such as exploit attempts, compromised systems and droppers. `Threats_Unclassified` is what has been seen but not yet classified. `Trackers` is addresses used to track user activity, and `Tunnels` is proxies and VPNs, which is a category choice worth pausing on, since a VPN exit node is not automatically hostile. Then there are two lists that describe infrastructure rather than abuse: `DNS` is common DNS resolvers, and `Ads` is addresses that serve advertisements. A rule set that loads every list in the directory without reading the descriptions will block name resolution. That alone is the reason to read the table before you script anything.

Probes need five attempts, and Scanners names companies rather than addresses

The two remaining lists are the most ambiguous and the easiest to misuse. `Probes` is defined by a negative: an address that was probed but never completed a full connect, with the threshold given as five or more times. So a single failed connection never earns a place in the list, and the rule is a repetition threshold rather than a judgement about intent. A scanner with a short timeout and a slow honeypot can trip it, which is the failure mode to expect. `Scanners` is described not as a behaviour but as internet scanning companies, so the criterion there is who operates the address rather than what it did to the honeypot. That makes it useful for attribution and dangerous for blocking: a research group scanning the internet is doing exactly what research groups do, and the list will not make that distinction for you.

Hourly updates with the diffs cleared, so you cannot diff two versions

The update policy is stated in two sentences and both of them matter. The feed is updated hourly, and it is compressed periodically to keep the size small. Then comes the part that changes how you should integrate it: diffs, pull requests and similar history are cleared. That means the repository is rewritten rather than appended to, so a fetch an hour from now is not comparable to the copy you hold now, and you cannot ask the history what changed or when. The compression is a second, separate rewrite: a file that is periodically recompressed will produce a large textual diff even when the address set is identical, so any change-detection you build on a textual comparison will produce noise. If you consume this feed, keep your own timestamped copy and do your own set comparison against a parsed list, not against a diff of the raw file.

No releases, and the default branch is master rather than main

There is no release history to pin, and the project publishes none. The repository has no GitHub releases, no version tags, and no changelog, so the only stable identifier available is a commit on the default branch, which is called `master` here rather than the `main` that most tooling now assumes. That matters for the obvious integration, because a raw file URL has to name the branch, and a template that hardcodes `main` will return nothing. The last push was 2026-09-30 and the repository is not archived, so the feed is live, but live and versioned are different properties and only the first one holds. The recorded primary language is unknown, which is what GitHub reports for a repository with no source files to analyse, and there is no homepage set on the repository either.

The Unlicense asks nothing of you, and the history keeps nothing to point at

The repository is released under the Unlicense, which is a public domain dedication rather than a permissive licence with conditions attached. Two things follow, and they line up uncomfortably with the cleared history. The first is that nothing in the licence requires you to credit the source when you redistribute a list or build a ruleset on top of one, so attribution is a decision you make rather than an obligation the licence imposes. The second is that the credit would be hard to earn anyway, since the history is cleared on each run and there is no release to cite. For a threat feed that feeds a firewall, that combination is worth a decision rather than a shrug: keep your own record of which commit you loaded and when, because after the next rewrite there will be no way to reconstruct it from upstream. The only external pointer the readme offers is an AbuseIPDB user profile, which is a reporting destination rather than a mirror.

Nothing states a line format, a count, or a time window

The documentation is the table and two sentences, and the table describes categories rather than files. No format is given: whether an entry is a single address, a range, or a masked value is not stated, and the links are written without a visible file extension, so the on-disk naming is not something the readme pins down either. No count is published, for any of the eight lists, which means you cannot tell from the page whether a list holds hundreds of entries or hundreds of thousands, or whether one has stopped growing entirely. No time window is given either, so there is no way to ask whether an address that was hostile an hour ago is still doing it. The one temporal claim that does exist is the hourly refresh itself. A consumer therefore has to do its own sampling, its own ageing, and its own parsing before it can put any of these lists in front of a firewall, and the page gives no basis for choosing a subset other than the category descriptions.

Editorial conclusion

Use IPs as one input to a blocklist pipeline rather than as the pipeline itself, and read the list descriptions before you load anything, because DNS and Ads are not threat lists and loading them wholesale will break name resolution. Do not expect traceability: hourly updates combined with cleared diffs mean you cannot tell what changed, when, or why, and there is no release to pin. Before you wire it in, look at what sits in Threats_Unclassified and decide whether unclassified addresses belong in your ruleset, sample one list to confirm the format your parser expects, keep your own copy with a timestamp so you can roll back, and if attribution matters to you, arrange it yourself, since the Unlicense asks nothing of you and the repository keeps no history to point at.

Frequently asked questions

Official sources

1. Official README
2. Project repository