# Found and closed three SSH brute‑force protections that had never worked: a ban jail watching port 22 while the daemon listened on 1986, a rate limit shadowed by a broader rule above it, and a ban action whose binary never resolved, so no ban had ever applied.

2025

**Situation.** A hardening review of the production host in August 2026 asked a question that usually gets a confident answer: are the SSH brute‑force protections working. All three were configured, all three appeared in every report anyone looked at, and all three had been inert since the day the host was built.

**Task.** The controls had to be checked against what the kernel actually does with a packet, rather than against the configuration files that describe what should happen to one.

**Action.** Reading the configuration would have confirmed the wrong answer three times, so the review read the running system instead. The intrusion‑banning jail was watching port 22 while the daemon had been moved to 1986 during the initial hardening — every ban it wrote named a port nothing listened on. The firewall's rate limit was worse in a subtler way: the rule existed, and it sat below a broader rule that matched first. Firewall user rules are evaluated top down and the first match wins, so a broad allow above a rate limit makes the limit dead code that still prints in every status listing. The third was the quietest of them: the ban action shells out to a packet‑filter binary that the package system only recommends rather than requires, so on a host without it the jail starts, counts and decides, and then fails at the one moment it tries to ban. All three fixes were small. What came out of it was not the fix but two rules that now govern the repository: a security control gets an assertion rather than a comment, and a firewall is verified by rule position rather than by rule presence.

**Result.** Three protections that had never once fired now do, and the class of defect they belong to — a control whose failure mode is that it keeps reporting healthy — is the class the platform's checks are now built to catch. All three had been inert from bootstrap. All three printed healthy in every place anyone looked, which is the whole reason they lasted.

---

- Role: Security Engineer
- Categories: [Infrastructure](https://engineer.company/categories/infrastructure/), [Monitoring & Observability](https://engineer.company/categories/observability/), [Networking & VPN](https://engineer.company/categories/networking/), [Linux & Servers](https://engineer.company/categories/linux/), [Security](https://engineer.company/categories/security/), [System Administration](https://engineer.company/categories/system-administration/)
- Services: [Site Reliability & Monitoring](https://engineer.company/services/site-reliability/), [Networking & VPN Setup](https://engineer.company/services/networking-vpn/), [Security & Access Management](https://engineer.company/services/security-access/)

<https://engineer.company/portfolio/found-three-ssh-brute-force-protections-that-never-worked-110/>
