Bans that never blocked: data and analysis code for measuring silent enforcement failure

Version 6. The open question of whether the chain layout is the panel vendor's default was tested on a clean installation of its current release. The precedence is the default: once the firewall module initialises, the panel places its chain above every chain the firewall front end owns. The accepts that complete the failure are not: with ufw active the current version writes ports into ufw instead, and no code in it writes into the panel's port chain. On the observed host those accepts date to January 2026 and were carried forward across upgrades, so the finding reaches hosts upgraded from earlier versions rather than every installation. The article was narrowed accordingly. Version 5. The reproduction now reads the packet counters on the ban rule, which supplies the third source the measurement lacked: in the leaking cell the counter does not move, while in the cells that hold it records 14 to 17 packets discarded during the same ten probes. The environment is recorded with it. Added too are the creation dates of the panel's port rules, taken from the panel's own database, which date the inert period rather than assuming it, and the attack-class composition table that the article no longer prints. Version 4. The controlled reproduction now crosses three placements of the panel's rule with four enforcement paths, including nftables. The ban leaks in one cell of twelve: the panel-like rule inserted at the head of INPUT combined with fail2ban's ufw action. The identical rule appended after the firewall's chains leaks nothing, which identifies precedence rather than the rule as the cause. Added with it is a note recording what was inspected on the production panel, including the file's SHA-256 and three read-only commands with which any operator can check the same thing on their own host; the vendor's code is not redistributed. Version 3 (peer-review round). Three additions answer what review asked for. First, the cause is now demonstrated rather than described: experiments/reproduce_chain_precedence.sh builds the failure from nothing on a disposable host and runs six combinations of chain arrangement and enforcement path; the ban leaks in exactly one of them, the one matching the production configuration. Sanitised INPUT-chain listings from both production servers are included beside it. Second, registration exposure is counted correctly: submissions (POST) are separated from form loads (GET), and the daily series records how many submissions came from an address then inside an active ban interval. Counting submissions only, they rose 32% while the accounts they produced fell 73% and conversion fell from 41.4% to 8.4%; but only 1.2% of them came from a banned address, so the article no longer claims that endpoint isolates the mechanism. Third, DATA-DEFECTS.md lists all eleven data defects with how each surfaced. Version 2 corrects version 1 and adds the measurement the study now rests on. Read CHANGELOG.md first if you have used version 1. Replication material for a study of compensating controls on production end-of-life scholarly publishing infrastructure, covering 14,524,327 HTTP requests over 52 analyzable days across three production servers. What version 2 adds. Enforcement is now measured directly rather than inferred from configuration or from attack volume. For every ban issued by the reactive layer, the interval from ban to unban was reconstructed from that layer's own event log, and requests from the banned address were counted inside that interval in the web server's access log, which a different process writes. If a ban reaches the packets, the count is zero. On the primary server 60.0% of bans leaked. Added: one row per ban interval with those counts at three grace periods and in the hour before the ban (2,386 intervals); the distribution of leaked requests by time since the last reload; hourly traffic and attack series for the five study sites; and five analysis scripts covering the ban-leak rate, its day-level variant for a second server, interval reconstruction from the published event log, an AIC break-point search at daily and hourly resolution, and the phase contrast reported in the article. What version 2 withdraws. Version 1 recorded a single change of enforcement path on 14 August and attributed the improvement to it. Dated configuration backups show two changes, and the earlier one, on 12 August, is what made bans effective; the jail carrying most of the study's identification never used ipset at all. The claim that replacing iptables with ipset improved security outcomes is withdrawn, as is the reading of the attack-volume series as locating the effect: a break-point search over every candidate date selects dates before either change, when a bot campaign subsided. Phase annotations in the account series and the phase windows in the analysis code were corrected accordingly, and two scripts that could not run at all in version 1 were fixed. No measurement was rewritten; every count, timestamp and pseudonym is unchanged. Anonymization. Network addresses are pseudonymized with a salted, truncated HMAC-SHA256, using the same salt as version 1 so an address carries the same identifier across every file; the salt is withheld and reversal is infeasible. Reverse-DNS names keep only their registrable suffix, because cloud provider hostnames frequently embed the address itself. Site names are replaced by labels: the five sites analyzed in the article keep the names used there, every other site receives a pseudonym, which matters because the observed servers also carry sites belonging to unrelated organizations that are not participants in this study. Decoy paths, and the location of the registry that lists them, are withheld for the same reason detection thresholds are. Ethics. The study is observational over data arising from normal operation. No attack was staged, no penetration test was performed, and no production change was made for the purpose of collection. Network addresses are treated as personal data under the Indonesian Personal Data Protection Law. Users of this dataset must not attempt re-identification, and must not combine it with other sources for that purpose.