Data-Shield publishes two curated IPv4 blocklists regenerated every two hours, designed for authorized defenders importing threat intelligence feeds into firewalls, gateways and web application firewalls.
| Tool | duggytuxy/Data-Shield_IPv4_Blocklist — curated IPv4 blocklists for inbound firewall, gateway and WAF filtering |
| Category | Threat intelligence blocklist / network defense feed |
| Primary Use | Importing a maintained feed of malicious IPv4 addresses into FortiOS, PAN-OS, OPNsense, pfSense, UniFi and similar platforms as external dynamic lists or URL table aliases |
| Safe Use | Purely defensive: filtering inbound traffic on firewalls and gateways you own or administer during authorized security operations, lab hardening and perimeter defense |
| Telemetry Note | As a defensive feed it leaves no attacker telemetry; defenders observe its effect through firewall match logs, blocked-connection counters and false-positive reports |
Most blocklist projects on GitHub are dumps of questionable provenance with no lifecycle story. duggytuxy/Data-Shield_IPv4_Blocklist takes a different approach: it publishes exactly two complete, opinionated IPv4 lists, prod_data-shield_ipv4_blocklist.txt for a standard policy and prod_critical_data-shield_ipv4_blocklist.txt for stricter ingress filtering, and it regenerates them on a scheduled basis every two hours. The project, maintained by Laurent Minne under the GPL-3.0 license and sitting at 607 stars, is explicitly aimed at inbound filtering on firewalls, gateways and web application firewalls rather than outbound censorship or research datasets. That framing matters, because it shapes nearly every design decision documented in the README.
The two-profile model is the first thing an operator should understand. The standard list is positioned as the starting point for Internet-facing services, with reviewed exceptions intended to reduce avoidable blocking of legitimate sources. The critical list applies a broader blocking policy for environments that consciously accept stricter ingress filtering and are willing to review the traffic impact before deployment. The README is unusually candid about a subtle footgun: applying both files together combines their blocking decisions and can override the exceptions of the profile you actually intended to run. In other words, these are alternatives, not composable layers, and treating them as such will quietly defeat the curation work behind the standard list.
Format discipline is the second strength. Each file is plain text with one public IPv4 address per line, no headers, no comments, no ports, no CIDR ranges and no IPv6 entries. Duplicates are removed and addresses are sorted numerically, which makes the files predictable to parse and diff. There is no fixed 100,000-entry cap, and the README explicitly warns integrators to check their product's capacity against the actual file size, including whether the appliance silently truncates oversized imports. That warning reflects real-world operational pain: many mid-range firewalls will accept a feed, report success, and quietly load only a prefix of it, leaving the operator with a false sense of coverage. Split files are no longer published, so older integrations must be migrated to one of the two complete files.
The generation pipeline is automated and integrity-focused. A GitHub Actions workflow, cia-integrity.yml, runs the scheduled build, and a new commit appears only when the published content actually changes — so a stale last-commit timestamp means the data genuinely did not change, not that the pipeline died. Both files are validated before publication and committed together on GitHub and GitLab. Failed generation checks preserve the last validated files, and failed publication is retried independently. The README still cautions that neither a successful download nor an unchanged commit proves your firewall applied the latest data, which is the correct paranoid posture: feed freshness and appliance-side application are two different failure domains.
Distribution is deliberately redundant across five destinations: GitHub, GitLab, Codeberg, Bitbucket and the jsDelivr CDN, each exposing stable raw-file URLs for both profiles. GitLab handles mirroring to Codeberg and Bitbucket, while jsDelivr serves a cached copy of the GitHub content, meaning CDN refreshes can lag behind publication. These URLs are the same ones consumed by the maintainer's related Linux defense project, SysWarden, which suggests the blocklist is one component of a broader personal defense ecosystem rather than a standalone artifact. A practical detail worth internalizing: you must configure the raw file URL in your firewall's feed settings, because a repository or preview page URL returns HTML, not a blocklist.
The deployment guidance in the README is some of the most operationally mature writing you will find in a feed project. It recommends starting with the standard profile, applying the list only to inbound Internet traffic by matching the remote source address, and explicitly warns against using the feed as a blanket outbound destination blocklist. It then walks through rule ordering, local exception precedence, observing matches in logging mode before broad enforcement, and finally configuring automatic retrieval with monitoring for fetch failures, truncation warnings and entry counts actually loaded. The advice to keep the last working rules if a download or import fails is the difference between a resilient control and a self-inflicted outage.
Platform coverage is extensive and documented externally at the project's website, with ten integration guides covering FortiOS/FortiGate native HTTPS external feeds, UniFi dynamic IPv4 network lists, Palo Alto/PAN-OS IP External Dynamic Lists with certificate validation, OPNsense URL table aliases, pfSense CE and Plus URL tables, Sophos SFOS 22.0 third-party threat feeds, VyOS remote groups, MikroTik RouterOS v7 with a Linux controller for verified complete-feed updates, OpenWrt 25.12 with native banIP feeds, and Stormshield/SNS via validated CSV conversion and manual import. A UniFi guide also lives in-repo under docs/unifi.md. The README notes that product refresh intervals can exceed the two-hour generation interval, so your effective staleness is bounded by your appliance, not the feed.
False-positive handling is treated as a first-class workflow rather than an afterthought. A structured issue template collects the affected IPv4 address, the list in use, the legitimate service impacted and sanitized evidence, while explicitly instructing reporters not to post credentials, private logs or personal information publicly. For sensitive findings there is a SECURITY.md policy, and the pragmatic advice to apply a narrowly scoped local exception while a report is reviewed keeps business continuity and correction processes from fighting each other. This is exactly how a community-maintained defensive feed should handle the shared-and-reassigned-IP problem that plagues all long-lived blocklists.
Perhaps the most important paragraph in the README is the honest scope statement: IP-based blocking is one layer of protection that complements application security, patching, authentication, rate limiting and monitoring, and it cannot identify every attack. Shared or reassigned addresses can produce false positives, and a blocklist is a coarse instrument. Operators evaluating Data-Shield should read that as the project's threat model disclaimer — it reduces noise and known-bad source traffic at the perimeter, but it is not a substitute for any other control.
For defenders and authorized security teams, Data-Shield is a low-friction way to add curated IP reputation filtering to an existing perimeter without licensing an enterprise feed. The combination of scheduled regeneration, pre-publication validation, multi-forge distribution, capacity warnings and a disciplined deployment methodology makes it stand out in a crowded category of hobbyist blocklists. Treat it as one input among many, monitor what your firewall actually loads, and keep your exception workflow sharp — that is the operational posture the README itself recommends.
duggytuxy/Data-Shield_IPv4_Blocklist.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.