DEV Community: Grujowmi

SecureWipe: ANSSI and NIST-compliant secure disk erasure, because rm -rf isn't enough

Grujowmi — Mon, 30 Mar 2026 17:32:36 +0000

In a medical environment subject to HDS (French healthcare data hosting regulations) and NIS2, decommissioning a hard drive is not a trivial operation. A rm -rf or even a quick format doesn't destroy data — it just dereferences the files. The data remains physically present and recoverable. I built SecureWipe to have an auditable erasure tool, compliant with recognized standards, and usable without friction in a real operational context.

Why not just use `shred`, `wipe`, or DBAN?

These tools exist and work. But they come with real problems in a professional context:

No native traceability: no usable erasure report for an audit or a documented decommissioning procedure
Vague compliance: shred does random passes, but doesn't align with any specific standard (ANSSI, NIST)
DBAN has been end-of-life since 2015, replaced by Blancco which is commercial
No integration into existing Python workflows

SecureWipe addresses these gaps: written in Python, it documents every operation and implements referenced erasure methods.

Implemented standards

ANSSI Tier 1 and Tier 2

The French national cybersecurity agency (ANSSI) defines two levels in its data destruction guide:

Tier 1: logical erasure by overwrite (1 pass of zeros or random data). Sufficient for most internal decommissioning cases.
Tier 2: enhanced erasure with multiple passes and verification. Required for media that held sensitive or classified data.

NIST SP 800-88 Rev.2

The U.S. reference standard for media sanitization. It defines three levels: Clear, Purge, and Destroy. SecureWipe covers the Clear and Purge levels depending on the media type and data sensitivity.

What SecureWipe does

SecureWipe v1.1.0
├── Automatic detection of available disks
├── Erasure level selection (ANSSI T1 / ANSSI T2 / NIST Clear / NIST Purge)
├── Overwrite passes execution with verification
├── Generation of a timestamped erasure report
└── Operation logging (disk, method, duration, result)

The generated report can be used directly in a decommissioning file or handed to a destruction vendor to complete the audit trail.

Usage example

# ANSSI Tier 2 erasure on /dev/sdb
sudo python3 securewipe.py --device /dev/sdb --method anssi-t2

# NIST Purge erasure with report generation
sudo python3 securewipe.py --device /dev/sdb --method nist-purge --report

The script refuses to run without elevated privileges and requires explicit confirmation with the device name before doing anything — no accidental wipes.

Why Python?

Python ships natively on all common Linux distributions and maintenance live USB environments. No dependency to compile, no binary to distribute, code that's directly readable and auditable.

For a security tool designed to run in critical contexts (end-of-life medical server, hardware returned to a vendor), code transparency is a non-negotiable requirement.

Creation context: HDS and NIS2

In a healthcare facility, decommissioning a storage medium that held health data (EHR, PACS, RIS data) is a regulated operation:

HDS mandates traceability of the destruction of hosted data
NIS2 Article 21 covers asset lifecycle management, including secure decommissioning
Internal ISMS/PSSI procedures must document the erasure method used

SecureWipe generates exactly what you need to fill that box: a timestamped report, with the applied method, on which device, on which date, with what result.

Known limitations

SSDs and NVMe: overwrite-based erasure is less reliable on flash media due to wear leveling and spare cells. On these drives, the recommended approach is NVMe Secure Erase (via nvme format) or physical destruction. SecureWipe flags this explicitly.
Encrypted drives: if the drive is encrypted (LUKS, BitLocker), destroying the encryption key plus one overwrite pass is generally sufficient. SecureWipe can be used as a complement.

License and contributions

Project released under the GPL V3, code available on GitHub.

Contributions welcome: native NVMe Secure Erase support, TUI interface, integration into Ansible decommissioning playbooks.

→ github.com/Grujowmi/SecureWipe

Built from a real operational need, in a medical environment under HDS and NIS2 compliance or others. If you manage end-of-life assets in a regulated sector, feedback in the comments is very welcome.

ShadowFortress: how I aggregate hundreds of IP blocklists into a single ready-to-use file

Grujowmi — Mon, 30 Mar 2026 17:29:02 +0000

For a while I've been looking for a clean way to feed my FortiGate with IP threat intel without having to manually maintain an unmanageable list. Public blocklists are plentiful, inconsistent in quality, and heavily redundant. So I built ShadowFortress to solve this once and for all.

The actual problem

As a CISO, I need to block inbound and outbound traffic to and from known malicious IPs: C2 servers, scanners, spam relays, offensively used Tor exit nodes, etc.

The market offers paid solutions (FortiGuard Threat Intelligence feeds, CrowdSec, etc.), but nothing that's truly simple to consume as a raw IP file, free, and automatically maintained.

Public sources exist (blocklist.de, feodotracker, spamhaus, etc.) but aggregating them properly takes real work: deduplication, frequency-based selection, false positive exclusion.

What ShadowFortress does

ShadowFortress is an open source IP blocklist aggregator that:

Collects multiple public blocklist sources
Deduplicates all IP addresses
Selects the most redundant IPs (those appearing across the highest number of sources)
Applies a private whitelist to avoid false positives on legitimate IP ranges
Generates two separate files: one for inbound filtering, one for outbound
Auto-updates every 6 hours via GitHub Actions

The cap is set at 100,000 IP addresses maximum, which is roughly what most network appliances can absorb without performance degradation.

Generated files

File	Purpose
`blacklist_inbound.txt`	Block incoming connections from malicious IPs
`blacklist_outbound.txt`	Block outgoing connections to compromised destinations
`STATS.md`	Statistics: volumes, trends, active sources

Files are available directly via raw GitHub URLs, making them easy to consume from any script or network solution.

Integration examples

No installation required. You consume the files directly.

FortiGate (my primary use case)

# From FortiGate CLI
config firewall address
    edit "ShadowFortress-Inbound"
        set type iprange
        set comment "ShadowFortress blocklist - inbound"
    next
end

For a clean integration using External Block List (EBL), point directly to the raw URL of the file — FortiOS will refresh it periodically on its own.

iptables / ipset

# Fetch the list and load it into ipset
curl -s https://raw.githubusercontent.com/Grujowmi/ShadowFortress/main/blacklist_inbound.txt | \
  while read ip; do ipset add blocklist_inbound "$ip" 2>/dev/null; done

nftables

table inet filter {
    set blocklist_inbound {
        type ipv4_addr
        flags interval
        # populate via script from blacklist_inbound.txt
    }

    chain input {
        type filter hook input priority 0;
        ip saddr @blocklist_inbound drop
    }
}

Cisco (ACL)

The list can be parsed to generate ACLs via a Python script, or integrated into a configuration management solution like Ansible.

Why redundancy-based selection?

This is the core of the project. Rather than taking the union of all sources (which can produce millions of IPs with a lot of noise), ShadowFortress selects IPs that appear across the highest number of distinct sources.

The reasoning: an IP listed in 10 different sources is far more likely to be genuinely malicious than one listed in a single source that might be stale or poorly maintained.

The result: a shorter, more accurate list with fewer false positives.

The private whitelist

A whitelist mechanism is applied before the files are generated. It excludes IP ranges that would trigger false positives in my environment (CDNs, legitimate cloud services, business partners, etc.).

This whitelist is not public — each user should manage their own exclusions based on their context. If you want to implement the same logic, the principle is straightforward: before publishing the files, filter out any IPs that match your allowlist.

License and contributions

The project is licensed under GNU GPL v3 (the AGPL-3.0 badge on the repo is worth correcting — the actual license in the LICENSE file is GPLv3).

Contributions are welcome: new sources to aggregate, fixes, improvements to the deduplication pipeline.

→ github.com/Grujowmi/ShadowFortress

This project was born from a real operational need in a medical environment subject to NIS2 and HDS compliance requirements. If you have experience integrating this with other appliances, feel free to open an issue or drop a comment below.

DEV Community: Grujowmi

SecureWipe: ANSSI and NIST-compliant secure disk erasure, because rm -rf isn't enough

Why not just use shred, wipe, or DBAN?

Implemented standards

ANSSI Tier 1 and Tier 2

NIST SP 800-88 Rev.2

What SecureWipe does

Usage example

Why Python?

Creation context: HDS and NIS2

Known limitations

License and contributions

ShadowFortress: how I aggregate hundreds of IP blocklists into a single ready-to-use file

The actual problem

What ShadowFortress does

Generated files

Integration examples

FortiGate (my primary use case)

iptables / ipset

nftables

Cisco (ACL)

Why redundancy-based selection?

The private whitelist

License and contributions

Why not just use `shred`, `wipe`, or DBAN?