Your own server behind Cloudflare — closing the back door

Putting Cloudflare in front of your own server has a sensible goal: the machine’s address stops being visible in DNS, and traffic passes through a layer that filters and rate-limits.

The problem is that Cloudflare hides the address but does not protect it. If the server’s firewall accepts connections on ports 80 and 443 from anyone, then whoever learns the address connects directly — bypassing the filtering, the rate limiting and everything else that layer is responsible for.

All the protection then comes down to the address being hard to find. And it is not.

Four routes by which the address leaks

1. DNS history

The domain existed before it moved behind Cloudflare. Entries from that period are archived in public services that track DNS changes. If the server still sits at the same address as two years ago, the address is public — just not in the current record.

This is the most common route and the only one that cannot be undone. The only remedy is changing the server’s address.

2. Certificate Transparency

Every publicly issued certificate lands in open logs. If you ever issued a certificate directly for the origin — for origin.yourcompany.com, say, or for the address itself — the name is findable in seconds. The logs are searchable by anyone.

3. Mail leaving the same server

The Received header in a sent message carries the address of the machine that sent it. Someone receiving a single email from you is enough.

This route is surprisingly often overlooked, because mail and the website are treated as separate topics — while sitting on the same machine.

4. Subdomains pointing straight at the server

ftp., mail., cpanel., test., old. — subdomains that do not pass through Cloudflare because somebody skipped them or added them later. A tool walking through common names finds them in a minute.

How to close it

One change settles the matter: allow ports 80 and 443 only from Cloudflare’s address ranges and reject the rest.

Cloudflare publishes the current ranges at cloudflare.com/ips. They change rarely, but they do change — worth rechecking during reviews, because an outdated list means cutting off part of your traffic.

Three things worth doing at the same time:

• SSL mode set to Full (strict). In Flexible mode the connection between Cloudflare and the server runs over HTTP. A rule forcing HTTPS on the server then sees the traffic as unencrypted and redirects in a loop — the symptom is a too-many-redirects error.
• An origin certificate instead of a public one. Cloudflare issues certificates valid only for connections from itself. They never reach public logs, which closes route two.
• Mail from a different address than the website. Where possible, move sending to a separate service — it closes route three and usually improves deliverability as well.

How to check whether it is closed

Simulating a direct connection, bypassing DNS:

curl -sI --resolve yourcompany.com:443:SERVER_ADDRESS https://yourcompany.com/

If you get a response from the site, the layer can be bypassed. Once the firewall is properly closed, the connection should time out with no answer.

Worth remembering something deceptively obvious as well: a plain curl -sI against the domain shows the headers coming out of Cloudflare, not the ones set on the server. When checking the server’s configuration, you have to query it directly.

When this matters at all

If nothing but a static site sits behind Cloudflare, bypassing the layer gains little — there is nothing to attack. It becomes serious once anything dynamic runs on the same machine: a panel, an application, an API, mail.

And that is the right way to judge it: the level of risk is set not by the website but by whatever else is running at the same address.