Data-Shield IPv4 Blocklists: two complete feeds for inbound filtering

Two files, and the choice between them is a policy decision

Data-Shield provides maintained IPv4 blocklists for inbound filtering on firewalls, gateways and web application firewalls, and it ships exactly two of them. The standard profile is described as the starting point for Internet-facing services, with reviewed exceptions to reduce avoidable blocking, and it lives in prod_data-shield_ipv4_blocklist.txt. The critical profile is a broader blocking policy for environments that accept stricter ingress filtering, and the README asks you to review the impact before deployment; its file is prod_critical_data-shield_ipv4_blocklist.txt. Each file is complete on its own. The one warning that matters is about combining them, since applying both lists combines their blocking decisions and may override the exceptions of the profile you intended to use. That is a real operational trap, because an operator who wires both into one rule set expecting a superset of exceptions gets a stricter set than either profile describes. Decide which profile you want, import that one, and treat the other as a separate experiment rather than an additional feed.

The format is deliberately minimal so any parser can read it

The format section is short, and every rule in it removes a parsing failure mode. The output is plain text with one public IPv4 address per line. There are no headers, no comments, no ports, no CIDR ranges and no IPv6 entries. Duplicate addresses are removed and addresses are sorted numerically, which means two runs that produce the same set produce the same file, and a diff between two versions is meaningful rather than noisy. The absence of IPv6 entries is the biggest functional limitation and it is not an oversight in the format list, since the whole project is scoped to IPv4. If your estate is dual stack, these feeds cover only half of your ingress, and you will need a separate source for the other half. The absence of CIDR ranges is a second constraint, because it means the list addresses individual hosts only, so a provider with a large allocation cannot be blocked at the prefix level from this feed alone.

Where to fetch it, and why a repository URL will not work

The project distributes the same two files from five hosting locations, and the README is explicit about using a raw file URL rather than a page URL. A repository or preview-page URL returns a web page, not the blocklist, which is the classic mistake when you paste a GitHub link into a firewall feed configuration. The GitHub raw file is the primary source, and the README notes that GitLab manages repository mirroring to Codeberg and Bitbucket, so those two follow GitLab. jsDelivr serves a cached copy from GitHub, so CDN refreshes can lag behind publication, which means a jsDelivr based feed is not always current even though it looks identical. There is also a separate false positive reporting form linked from the README, hosted on GitHub issues with a template chooser, so a false positive has somewhere to go other than an ignored mail. The README also points out that these are the existing download URLs used by SysWarden, the author's related Linux defence project, and that the two filenames and their paths remain unchanged, which is a compatibility promise worth noting if you have already wired one in.

Generation runs every two hours and commits only on change

The update mechanism is designed around the fact that a firewall pulls on a schedule. Generation is scheduled every two hours, and a new commit appears only when the published file content changes, so an unchanged feed produces no commit noise in your subscription. Both files are validated before publication and are committed together on GitHub and GitLab, which keeps the two profiles in sync at the source. Downstream mirrors and CDN caches can differ until they refresh, which is the honest caveat in that same paragraph. Failures are handled with two separate rules: failed generation checks preserve the last validated files, so a broken generator run cannot blank out your feed, and failed publication is retried independently of the generation check. The last push to the repository was on 2026-10-22 and the repository is not archived, and there is an integrity workflow badge in the README for the cia-integrity workflow. The repository also carries a SECURITY.md and a CODE_OF_CONDUCT.md, so the operational scaffolding around a feed project is more complete than the feed itself is complex.

Import capacity is the failure mode nobody plans for

The README calls out a specific operational trap, and it is more useful than any generic advice. The entry count changes over time, so you should check your product's capacity against the actual file, including whether it silently truncates oversized imports. There is no fixed 100,000 entry cap, which means you cannot size your firewall from a number quoted in a post; you have to look at the file. A silent truncation is the worst kind of failure here, because the import reports success, the firewall loads the first N addresses in sorted order, and the tail of the malicious set is simply absent with nothing in the logs to say so. Since the addresses are sorted numerically, a truncation drops the numerically last entries, not the oldest or the most recently added ones, which makes it even harder to notice by reasoning about what is missing. The related change is worth knowing too, since split files are no longer published and existing integrations must use one of the two complete files. If your firewall was set up to pull several shards, that integration is now pointed at nothing.

Deployment order matters more than the list contents

The deployment section gives a sequence that reflects the failure modes rather than a generic order. Start with the standard profile and check the number of entries against your device's import limits. Apply the list to inbound Internet traffic, matching the remote source address on traffic reaching the gateway or your published services, and the README draws an explicit line here: do not apply the feed as a blanket outbound destination blocklist. That is a meaningful restriction, because a list of malicious source addresses used as an outbound deny list would block your users rather than your attackers, and some firewall platforms default to exactly that interpretation when you add a feed. Review rule ordering and local exceptions, preserving required administration and business access, since a whitelist has to take precedence over the block list or you will lock yourself out of the device that protects you. The README also notes that neither a successful download nor an unchanged commit proves that your firewall has applied the latest available data, and advises reviewing a file's commit history to see when its content last changed. Publication and application are separate events, and only one of them is under the feed author's control.

A commercial threat feed or a locally built list instead

The alternative to a public feed like this is either a paid threat intelligence subscription or a list you build yourself from your own logs. The commercial route buys breadth, provenance and a support commitment, and it usually buys an update frequency and a data format your platform understands natively, including CIDR aggregation, IPv6 and often attribution of why an address is listed. Against that, a public feed like this has the advantage of being plain text with a stable URL and a GPL-3.0 licence, so you can inspect exactly what you are loading, diff it against the previous version, and keep it in your own configuration management. The self-built route, deriving a block list from your own firewall logs, is the most accurate list available for your estate and the least useful elsewhere, since an address attacking you is not necessarily attacking anyone else, and it inherits every mistake in your log parsing. Between those, a curated public feed is the middle option, and its weakness is precisely the one this project is candid about, that the profile choice and the exceptions are opinionated and the README asks you to review the effect on legitimate traffic yourself.

Editorial conclusion

Adopt the Data-Shield standard profile if you operate internet-facing services and want a maintained IPv4 deny list with reviewed exceptions, and treat the critical profile as a deliberate choice for stricter ingress filtering after measuring the effect. Skip it if you need IPv6 coverage, CIDR ranges or per-service attribution, none of which the format provides. Verify first that your device can import the whole file without truncating, that rule ordering keeps your administration and business access reachable, and which of the mirror URLs you use, since a CDN copy can lag the source by a refresh cycle.

Frequently asked questions

Official sources

1. duggytuxy/Data-Shield_IPv4_Blocklist on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README