Drop the decommissioned prover's rate-limit exemption

[defenwycke]

Refs #218. Removes a rate-limit bypass belonging to a machine that no longer exists.

What it was

RATE_EXEMPT listed 94.237.17.228, added 2026-07-27 with the comment "exempt our own prover". It was an UpCloud box in the same range as the retired hazync-b200 (94.237.18.83) — a prover that talked straight to :8899 instead of through the web proxy, which is why it had 19 GB against that rule.

The box is gone. Measured 2026-09-08: 0 packets in 90 s against the web box's 1,690, no connection on any port, not among the GPU servers on the account, and the operator confirms there are no other servers for this project.

Why an exemption is worse than a firewall hole

A stale ACCEPT lets a stranger reach the port. A stale exemption lets them reach it without limits — the anonymous GET flood on /api/state that §7 calls the cheapest board-takedown. Provider addresses return to a pool when a box is deleted, so the exemption stops belonging to us the moment the machine does.

The file now says so, so the next person retiring a prover retires its entry with it.

⚠ I got this wrong first time

I originally called the rule stale on packet counts alone. That was bad reasoning: the address is referenced in two places and its own comment calls it "our own prover", so it was deliberate, not forgotten. A dormant counter is evidence of silence, not of decommissioning — what actually settled it was the operator's account inventory. Worth recording, because the same mistake would have removed something live.

Applied live alongside this

• iptables ACCEPT for :8899 removed — backup /root/iptables.bak.20260908
• this dropin installed, daemon-reload + restart — backup /root/ratelimit.conf.bak.20260908

Verified after both: public /api/meta still reachable through the web box (frontier advanced 3,644 → 3,646 across the restart), workers still crediting to G H O S T, three consecutive public GETs all 200.

For the record, since it was asked: the coordinator is not this address — it is 152.53.93.164, and is not on UpCloud at all.

#218 stays open for the rest of §7 (the nginx limit_req/limit_conn, micro-cache and TRUSTED_PROXIES items on the web box).

[defenwycke]

Second commit added — same issue, same surface. Verified §7's web-box half and fixed one thing it got wrong.

§7's web-box hardening is already deployed AND working

The issue implies this is outstanding. It is not — and I checked it fires rather than trusting that the directives are present, which is the distinction that matters here:

40 concurrent GETs on /api/state  ->  20x 200 + 20x 503
x-cache-status: HIT

Twenty through, twenty refused, matching burst=20 exactly; the 1 s micro-cache is live. nginx -t clean, and sites-enabled/ contains no backup files (the glob would load them).

But it answered 503, which is the wrong thing to say

nginx defaults limit_req_status/limit_conn_status to 503 — the same code the board returns during a real outage. So a contributor who merely burst too hard cannot distinguish "slow down" from "the board is down", and neither can anyone debugging from outside. Now 429, which clients back off on:

after:  20x 200 + 20x 429

⚠ Applied to the hazync locations only, not http. The same file serves ladder_api and pool_api, and a global setting would have changed those services too — outside this issue's scope.

RUNBOOK caught up

The warning that the stale ACCEPT "should be removed" is itself stale now it is removed. Replaced with what was done plus the two durable rules: retire the RATE_EXEMPT entry when you retire the box, and don't judge an allow-rule by its packet counter alone.

Live config backed up to /etc/nginx/backups/bitcoinghost.bak.hazync-429.20260908; board serving throughout (frontier 4,083).