To hide the IP of my server, I am using Cloudflare CDN. However, one can scan IPs to find out the real IP of my site (for example, he can use curl -H "Host: mydomain.com" [MY_REAL_IP] to detect if an IP is related to my site). To prevent such scanning, I plan to refuse anyone except Cloudflare to access the 80/443 port of my server. So this is my Caddyfile:
We could troubleshoot this, but first, I’d be remiss not to ask whether you’d considered using Authenticated Origin Pulls instead and requiring Cloudflare to present a certificate to validate itself on connection?
You can probably also consider swapping to a Cloudflare origin certificate to use for your HTTPS and just stop serving HTTP from your origin, because Cloudflare shouldn’t use it.
Thanks for the advice. I have read some about Authenticated Origin Pulls and feel that it may solve my problem. I enabled it in Cloudflare and added this to my Caddyfile:
tls {
clients /path/origin-pull-ca.pem
}
But curl -H "Host: mydomain.com" [MY_REAL_IP] -L could still get the content of my website with no error. Did I make any mistake?
That’s where the second part of my comment comes in. You can’t do client verification for non-SSL connections - no certificates are changing hands.
You’ll definitely want to go HTTPS-only. Start by prepending all your site labels with https:// - Caddy will know not to serve them over HTTP.
You can leave it there - Caddy will still be able to validate LetsEncrypt certificates over HTTP without necessarily serving the site on it. But again, my recommendation is to download the origin certificate from Cloudflare and use it for your HTTPS. It will break validation for regular clients - the certificate provided by Cloudflare is only trusted by Cloudflare - but you shouldn’t have any regular clients, so this is actually a plus. It’s also usable for up to 15 years, which is fine because you can tell Cloudflare to revoke it at any time.
With a HTTPS-only origin, requiring a client certificate only Cloudflare can provide, and presenting a server certificate only valid to Cloudflare, your origin server will be about as obscure and secure as it can get in the orange cloud.
You’ll definitely want to go HTTPS-only. Start by prepending all your site labels with https:// - Caddy will know not to serve them over HTTP.
I prepended https:// but Caddy still serves the HTTP connections: Caddy’s output shows that it serves both http://mydomain.com and https://mydomain.com. The document seems to indicate that setting the scheme to https will also enable HTTP connection:
So I don’t think this is an effective way to disable HTTP connections
By the way, I think using the origin certificate from Cloudflare makes little sense. Although it’s not trusted by anyone except Cloudflare, if an attacker really wants to scan IPs to find out my real IP, he can simply ignore the certificate errors. Therefore the Cloudflare origin certificate doesn’t seem to prevent clients from accessing my server directly. Is my understanding correct?
Huh, looks like I was wrong on that front. Automatic HTTPS puts up a HTTP listener even if you specify HTTPS.
Cloudflare origin certificate lets you break Automatic HTTPS, stopping this behaviour (so https://example.comwill only serve HTTPS and not HTTP). Alternately, you can just firewall port 80 entirely, ignore Caddy and allow no connections.
By itself, it doesn’t stop attackers - that’s what requiring Authenticated Origin Pulls will do.
Doing both is just an exercise in “breaking” the protocol in as many ways as possible for anyone other than Cloudflare - defense in depth.
Thanks a lot, that makes sense! Now I believe my website is safe enough
At last, I’d like to explain something – not very important, just don’t want to make others confused:
Before using the origin certificate and disabling HTTP, the client certificate verification was already working well. In my previous reply, I said curl -H "Host: mydomain.com" [MY_REAL_IP] -L will get the content successfully, that’s because curl followed the 301 redirect (HTTP to HTTPS) and finally reached Cloudflare server. The HTTP connection is served by my server and the HTTPS connection is served by Cloudflare, so there’s no client certificate verification happened indeed.
So I added my server’s real IP to hosts to make the HTTPS connection handled by my server, too. Then visit my site in browser will show a ERR_BAD_SSL_CLIENT_AUTH_CERT error, which means client certificate verification works.
Now, with HTTPS-only, client certificate verification and server certificate, I did some test:
Add the real IP to hosts. Run curl http://mydomain.com -L -i -v, it reports a 404 Not Found (because the HTTP site is not served). Run curl https://mydomain.com -L -i -v, it says the certificate cannot be trusted. Run curl https://mydomain.com -L -i -v -k to ignore the untrusted certificate, error still occured due to client certificate verification. Ahh, quite ideal
Short of completely firewalling your entire server and using Argo Tunnel, this is indeed about as far as you can go to stop people from using your origin server instead of going through Cloudflare
I am still curious about why IP whitelist doesn’t work
It looks like the ipfilter plugin will always use the real client IP, while in other directives/plugins I can choose from proxy IP or client IP with the realip plugin. Is it a bug of ipfilter?
Where does this assertion come from? From your initial post, it seems like it didn’t work with or without realip?
My first step would be to make a new Caddyfile to test this with just ipfilter and test against local IPs to see if the plugin actually functions as expected.
ipfilter works properly in the past. Actually, I have used it for a long time (before I started to use Cloudflare) to stop anyone from accessing critical pages (like WordPress login page), and it meets my needs.
I set up a new site with CDN enabled to test plugins just a moment ago. When I enabled realip and ipfilter with the config in my first post, visit the site will get a 403 Forbidden, and my real client IP was been written in the access log. Then I disabled realip, but still get a 403 Forbidden. This time, the IPs of CloudFlare servers were in the log. What puzzles me is these IPs are in the allow field of ipfilter.
This makes it seem like the directive is pretty broken.
Try on something you know shouldn’t fail, like allowing private IPs, then test locally. If it’s still failing, we know things are busted and it’s not something to do with Cloudflare or realip.
I can’t reproduce it locally. It seems the problem will only happen when the website is behind a proxy (like CDN). I will ask ipfilter author for further help.
Update:
I found a strict option in ipfilter document. It’s false by default, which will make the plugin always use the address in the X-Forwarded-For request header. Under this circumstance, realip will be ignored. When setting it to true, ipfilter will use the address realip provides, and that can solve the problem.
