# Proved the intrusion‑banning path end to end on every hardening run by banning a reserved test address, reading the resulting kernel rule and unbanning in a guaranteed cleanup block, so a jail that stops working fails a run instead of reporting healthy. 2025 **Situation.** The intrusion‑banning service had already been caught banning a port the SSH daemon did not listen on. Fixing the port closed that instance. It did nothing about the reason the fault survived so long, which is that a ban path has no visible failure: the service runs, the jail is listed as active, and nothing anywhere says whether a ban ever reaches the kernel. **Task.** The ban path had to be exercised on every converge, against the live rule set, rather than inferred from the service being up. **Action.** The converge now bans an address from the block the standards reserve for documentation, reads back the resulting rule in the kernel's packet filter, and unbans it in a cleanup block that runs whether the check passed or failed. The reserved range is the load‑bearing choice — the test address belongs to nobody, so a stray ban that outlives a failed run cannot lock out a real network. The kernel read‑back is the other half: the service's own status output would report success for a ban that produced no rule, which is the exact failure being tested for. Alongside it, the ban backend is pinned rather than left to the service's detection, and the log backend is set to detect because the operating system ships no traditional authentication log and the wrong choice fails silently by watching a file that never appears. **Result.** A banning path that stops working now fails a converge instead of continuing to report healthy, which is the only property that mattered. It costs a few seconds on every run and it writes and withdraws a firewall rule against production every time, which is a real intrusion into a live system and was accepted on the grounds that the alternative had already been demonstrated to be worse. --- - Role: Security Engineer - Categories: [Infrastructure](https://engineer.company/categories/infrastructure/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Reliability & Backups](https://engineer.company/categories/reliability/), [Linux & Servers](https://engineer.company/categories/linux/), [Security](https://engineer.company/categories/security/), [Testing & QA](https://engineer.company/categories/testing/) - Services: [Site Reliability & Monitoring](https://engineer.company/services/site-reliability/), [System Administration](https://engineer.company/services/system-administration/), [Security & Access Management](https://engineer.company/services/security-access/)