How we prove the door is shut before go-live.
Before go-live, we prove the door is shut: attack your true origin from an off-network box the firewall never trusted, and see what a stranger sees. A shut door answers connection refused, not a login page.
In this article 7 sections
- Before any go-live, and after any change to the edge, we ask one question: what does a stranger on the internet actually see? We answer it from a box in another of our datacenters, on an egress our own firewall was never told to trust.
- We find the true origin the way an attacker would (it usually leaks in the domain's own mail DNS), pin every tool to the naked origin instead of the CDN, and re-run the full battery.
- We scan all 65,535 ports from that off-network vantage, so we can say affirmatively what's closed. The durable fix locks the origin to the CDN's published ranges, backed by a real Layer-7 WAF and shared block-lists.
- Then we don't take the fix on faith. We re-attack the naked origin from the outside, and a shut door answers connection refused, not a login page. That's proof, not a promise.
The most common way a hardening job ends is that someone changes a setting, refreshes the page, sees what they expected, and moves on. That is patch-and-hope. It proves the symptom you looked at; it proves nothing about the door. What follows is the method our engineers run instead, before any go-live and after any change to the edge. It has one governing rule: every check is run from the outside, from a vantage that gets no special trust, because the only question that matters is what a stranger on the internet can actually reach. You could run the first half of this against your own site tonight. The reason to hand it to us is who runs the whole battery, from where.
The only question that matters: what does a stranger actually see?
We run the scan from a dedicated box in another of our datacenters, on an egress IP our own firewall was never told to trust. It gets no allow-list entry, no exception, no courtesy. It sees exactly what the internet sees.
This only works if the vantage is real and outside your trust boundary, which is why it's a box in another of our own datacenters, on our own AS, not a rented scanner. It's the same reason owning the network matters at all. More on that in you don't own your network.
From that vantage, three things stop being assertions and become measurements. Whether your CDN is really in front of your origin. Whether the ports you think are closed are closed. And, after a fix, whether the door you just shut is actually shut. The rest of this is how we read each one.
Find the true origin the way an attacker would
The origin usually leaks in the domain's own mail DNS, because the SPF record that authorizes your mail names the very host that sends it. Once the real origin is known, you pin the hostname straight to it, so every tool hits the naked origin instead of the CDN, and you re-run the full battery against it.
# the origin usually leaks in the domain's own mail DNS
scanner$ dig +short TXT origin.example # the SPF record often names the sending host
scanner$ dig +short MX origin.example
# pin the hostname straight to the origin so nothing touches the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/
# now re-run the full battery against the naked origin, not the edge
scanner$ <scan battery> --target <origin-ip>The point this proves is simple. If the origin answers the pinned scan the same way the public hostname does, serving the same pages, the same login form, then the CDN and the WAF in front of it are being walked around. Every request an attacker wants to send can go around them.
Scan every port, then say what's closed
From the off-network vantage we scan all 65,535 ports.
# from the box on an egress the firewall doesn't trust: every port, not a shortlist
scanner$ <port-scanner> -p 1-65535 <origin-ip>A full-surface scan is not just a yes/no on each port. What answers, and how, fingerprints the machine. Three tells recur.
a mismatched TLS cert on a production subnet -> a forgotten host, fingerprinted
an absurdly low firewall hit-count -> traffic isn't flowing the way you think
a DNS server answering REFUSED -> good: you are not an open resolverA firewall is not a WAF
Login brute force is invisible at Layer 3/4, so the defence lives at the edge, at Layer 7.
Rate-limit at the edge, where the logins are
Count login failures per source at the HTTP layer, the one place they're visible, and ban a source that crosses the line. The firewall never saw the attack; the edge sees nothing else.
Escalate to the subnet after two strikes
A single banned address is trivially rotated. After a second strike from the same neighbourhood, the ban widens to the offending subnet, so the attacker can't just step one IP over.
We say the uncomfortable part out loud: a subnet ban can catch a legitimate user who mistyped their password twice from a shared address, a corporate NAT, a campus, a café. That's a real cost, not a rounding error. So the rule ships with a documented release valve for shared IPs, not as a permanent wall.
The durable fix: lock the origin to the CDN, then re-attack it
The fix is to firewall the origin to the CDN's published ranges. Then the same pinned probe, from the same untrusted box:
# BEFORE: pin the naked origin, it serves the login page around the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
HTTP/1.1 200 OK # the origin answered. the CDN was bypassed.
# AFTER: origin firewalled to accept only the CDN's published ranges
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
curl: (7) Failed to connect to <origin-ip> port 443: Connection refusedBehind the origin lock sits the actual Layer-7 WAF, the thing that inspects requests the CDN does forward, and a shared block-list: an attacker caught probing one customer is banned across all of them, so the reconnaissance that maps one site pays a toll on every other.
What we fix, and what we hand back to you
When the audit finds something, the work splits into two columns. One is ours, and we do it in the same session: harden at the infrastructure edge, immediately. The other is in your application, and we don't touch your code. We hand you the exact finding, and we shield it in the meantime so you're not exposed while you fix it.
| What we fix in the same session | What we hand you to fix (shielded meanwhile) |
|---|---|
| Lock the origin to the CDN's published ranges | Update or remove the vulnerable plugin, CMS, or app |
| Stand up edge Layer-7 brute-force defense | Rotate shared or default credentials |
| Firewall exposed data stores to the private network | Enable MFA on the accounts that matter |
| Kill the info leaks at the web server | Fix the app-level exposure in your own code |
Then we re-attack, and prove it's shut
Every fix above ends the same way: we go back to the box the firewall was never told to trust, re-run the battery that found the problem, and confirm the same measurement now comes back shut. Origin-pin returns connection refused. The port that answered is dark. The finding we handed you, once you close it, refuses us too.
The same posture, aimed at whether we even control the network your traffic rides, is in you don't own your network.
Straight answers
How do you prove a security fix actually worked?+
We don't trust the patch. We re-attack the true origin from a box on an egress our firewall was never told to trust, so it sees what the internet sees. If the door is shut, a pinned scan of the naked origin answers connection refused, not a login page. In that case, it's proof, not a promise.
How can an attacker bypass a CDN or WAF and hit the origin directly?+
The origin usually leaks in the domain's own mail DNS, because the SPF record that authorizes your mail names the host that sends it. With the real origin address, you pin the hostname straight to it so every tool hits the naked origin instead of the CDN. If the origin answers the same as the public hostname, the CDN and WAF are being walked around: they are only effective if the origin is locked to them. The durable fix is to firewall the origin to accept traffic only from the CDN's published ranges, after which the same probe gets connection refused.
How do you check that a port is really closed from the outside?+
You scan all 65,535 ports from an off-network vantage, not the common few, so you can state affirmatively that everything you didn't intend to expose is closed. A full scan also surfaces tells: a mismatched TLS cert fingerprints a forgotten host, an absurdly low firewall hit-count means traffic isn't flowing the way you think, and a DNS server answering REFUSED confirms you're not an open resolver.
What do you fix, and what do we have to fix ourselves?+
In the same session we harden at the infrastructure edge: lock the origin to the CDN's ranges, stand up edge brute-force defense, firewall exposed data stores to the private network, and kill info leaks at the web server. Then we hand you the exact finding and shield it meanwhile: update or remove the vulnerable plugin/CMS/app, rotate shared or default credentials, enable MFA, and fix app-level exposure in your own code.
We won't just close the ticket. We'll prove the door is shut.
Talk to an engineer who re-attacks your origin from a box we never allow-listed, and shows you the connection-refused that proves the door is closed.
Talk to an engineerIf you want the posture underneath all of it, it starts with owning the network you're defended from: you don't own your network.
You’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer