Itnetic TechnologiesWhy a hidden origin matters
DDoS mitigation works by standing in front of your server. Traffic arrives at a filtering edge first, attack traffic is dropped there, and only clean requests are forwarded to you. That design carries one hard requirement: the internet must not be able to reach your server any other way.
If your origin's real IP address is discoverable and still accepts connections from anywhere, an attacker simply aims at it directly. The mitigation network never sees a single packet of that attack. Your protection dashboard stays quiet, every graph looks normal, and your site goes down anyway.
This is the most common reason people conclude that protection "does not work." It is almost never a filtering failure. It is an unlocked back door.
How attackers find your origin IP
Assume the address is findable unless you have actively closed each of these paths.
- DNS history — passive DNS archives store the A records your domain published before you enabled protection. Turning on a proxy today does not erase yesterday's answer, and those archives are searchable for years.
- Unproxied subdomains — mail, ftp, cpanel, webmail, direct, dev, staging, vpn. A single record pointing straight at the machine gives away the host, and usually the whole address range it lives in.
- Certificate Transparency logs — every publicly trusted TLS certificate is written to a public, permanently searchable log. Hostnames you assumed were private, like a staging subdomain, become a list an attacker can resolve one by one. Certificate Transparency is searchable by design; that is the point of it.
- Email headers — a password reset or order confirmation sent by the application server carries that server's IP address in the Received headers. Anyone who can trigger a signup email gets your origin.
- Outbound connections — webhooks, link preview fetchers, avatar and image importers, PDF renderers, callback URLs. If an attacker can make your app fetch a URL they control, your origin connects out and identifies itself.
- Default virtual host — if your server answers requests carrying an unknown Host header with your real site, internet-wide scanners can match that response to your domain by page content or favicon hash and publish the mapping.
- Leaky application output — stack traces, health and status endpoints, verbose response headers, and hardcoded absolute URLs in HTML or JavaScript that point at the origin hostname instead of the public one.
The lockdown checklist
| Step | What to do | Why it matters |
|---|---|---|
| 1 | Rotate the origin IP after enabling protection | Retires every address already recorded in DNS history and scanner databases |
| 2 | Firewall the origin to your mitigation network only | The only measure that survives your address being discovered |
| 3 | Proxy every public DNS record | Removes the direct pointers attackers look for first |
| 4 | Send mail through a separate provider | Stops transactional email from broadcasting the server's address |
| 5 | Reject unknown Host headers | Blinds internet-wide scanners that fingerprint by response content |
| 6 | Authenticate traffic from the edge | Ensures a leaked address still cannot serve your site to anyone else |
| 7 | Clean up application output | Closes the slow leaks: traces, health pages, absolute URLs |
Step 2 is the one that matters most. Secrecy is a delay tactic — addresses get discovered eventually, and you will not know when it happens. A firewall rule that accepts traffic only from your mitigation network's ranges turns discovery into a non-event: the attacker finds the address, connects to it, and gets nothing. Ask your provider for the ranges to allowlist and treat that list as part of your deploy configuration, not a one-off manual change. Ours are available on request through contact.
Step 6 closes the remaining gap. Even with an allowlist, requests from inside a large shared mitigation network can reach you unless the origin verifies which tenant they belong to. Client certificates or a secret header the origin requires on every request are the two usual answers, both cheap to add at the web server level.
How to verify the door is actually shut
Do not assume. Check, and re-check after every infrastructure change:
- Request your site directly by IP address and confirm you get a timeout, a connection refusal, or a default response — not your homepage.
- Enumerate every record in your DNS zone, subdomains included, and look for anything resolving into your server's range. Mail records are the usual survivor.
- Search Certificate Transparency for your domain, then resolve each hostname it returns.
- Trigger a transactional email to yourself and read the raw headers for your server's address.
- Compare your origin's access log against your edge's request logs. Requests present at the origin but absent at the edge are direct hits — proof of a bypass, and the fastest way to find one before an attacker does.
- After rotating an IP, re-check passive DNS a few weeks later to confirm the old address is no longer associated with your domain.
Where Itnetic fits
Itnetic filters Layer 7 attacks at edge points of presence close to your visitors, and the pieces this checklist depends on are part of the product rather than an upgrade: per-request logs you can diff against your origin's own log to catch bypass traffic, alerts when a domain enters attack mode, and attack traffic that is never metered against your bandwidth quota.
Getting behind the edge takes two DNS records and about five minutes — see DDoS protection. Lock the origin down in the same session, while you are already in the firewall console; it is the half of the job that never gets scheduled later. If you are reading this mid-incident, start with how to stop a DDoS attack instead.