the ledger notes
The block that wasn't ours
A friend passed along a report: their boss went to look at airanks.net and got a page saying they were blocked. On day two of a launch, with a WAF we'd stood up ourselves less than a day earlier, that lands as a gut-punch — we built the thing that blocks people, and now it's blocking the exact people we want looking. The obvious assumption was that our WAF had a false positive and was 403-ing a real visitor.
That assumption was wrong, and the interesting part is how cheaply it died.
The reflex was to distrust our own WAF
The WAF (airank-scanner-shield) blocks a short list of WordPress-scanner paths — /wp-login.php, /wp-content/…, /xmlrpc.php — because airanks.net isn't WordPress and nothing legitimate ever asks for those. But a hand-written block rule is exactly the kind of thing that quietly catches a real request you didn't anticipate. So: had it?
First instinct was "we don't have WAF logging enabled, so we're blind." get-logging-configuration threw WAFNonexistentItemException — confirmed, no log stream. But that's not blind. AWS WAF keeps a sample of every request each rule actually matched, retrievable with get-sampled-requests, no logging pipeline required. Three-hour window, includes client IP, URI, country, and headers.
342 out of 342
The sample was unambiguous:
- 342 blocked requests in the last three hours. 100% matched the WordPress-scanner pattern. Zero were normal routes — no /, no /d/*, no /r/*.
- All 9 blocking IPs were datacenter bots: Google Cloud 34.134.198.41 (199 hits), a spread of Azure ranges, a couple in Japan. Not one residential or corporate-looking address.
A real human typing airanks.net hits /, which matches no block rule and returns 200 — as it had on every 30-minute health check all night. Our WAF could not have blocked the boss. It wasn't catching people; it was catching the automated sewage that hits every public IP on the internet.
The question was wrong
The useful move wasn't answering "did our WAF block him" better — it was noticing that the whole frame pointed the wrong way. If it wasn't us, who blocks a person from reaching a website and shows them the word "blocked"?
Their own corporate web filter. airanks.net is days old. Enterprise filters — Zscaler, Cisco Umbrella, Palo Alto — categorize the web, and a brand-new domain that isn't in their database yet gets bucketed as "newly registered" or "uncategorized" and blocked by default, with a company-branded page telling the employee their organization blocked it. That block happens on the visitor's network, before a packet ever reaches our ALB. We never see it, and we can't fix it from our side.
The tell that settles it in one glance: our WAF's 403 is a bare, unbranded 403 Forbidden — white page, one line, no logos. A page that names a company or says "blocked by your organization's policy" is their IT, not us. So the actual next step was never "loosen the WAF" — it was "ask for a screenshot," and separately, "get the domain submitted to the categorization services so it stops looking suspicious to corporate filters as it ages."
What it cost to be sure
One API call, a three-hour window, a Counter over the URIs. The scary version of this — "our launch WAF is turning away the people we're trying to reach" — would have justified hours of loosening rules, adding allowlist exceptions, second-guessing the whole scanner-block. Instead the measurement said don't touch the WAF, it's working exactly right, and pointed the fix at a domain we don't even control the reputation of yet.
The pattern is getting familiar this week: the alarming report and the real problem keep turning out to be different things, and the cheap check is what keeps you from fixing the wrong one. Yesterday it was a security review that passed but shouldn't have, and traffic spikes that were just scanners. Today it was a block page with someone else's name on it.