Cloudflare is by far one of the best web services out there for securing websites. They offer DDOS protection, CDN, and a load of other performance-enhancing features that can make your website load faster, but there are some pitfalls you should be aware of before leaving your infrastructure's uptime in Cloudflare's hands.

Image source: Cloudflare.

Firewalling Cloudflare

When you sign up for Cloudflare, all you need to do is change your nameservers over to them and your visitors will soon be accessing Cloudflare's servers instead of your own. The only issue with this is that your origin's old IP address is still known to anyone that has visited your website before, so if a malicious actor is able to use a tool like SecurityTrails' DNS history tool, it can be trivial to obtain the origin IP address.

The best way to protect against this is by setting up a firewall at the provider level. By offloading the IP filter to your provider, instead of relying on iptables (which is fine if your cloud service doesn't offer a firewall) you won't have to deal with potential transport layer DDOS attacks overwhelming your server itself.

Doing this depends on your provider, but i've created guides for some popular providers:

You can find all of Cloudflare's IP addresses at cloudflare.com/ips if you use a different provider.

Host header protection

Firewalling your server to only allow Cloudflare is only half the battle. If your service has a dedicated IP address, you need to make sure you are only responding via your service's correct HOST header.

If you allow any HOST header to access your main application or server configuration, an attacker can set up their own Cloudflare-controlled domain to point to your service's IP address. When they access that domain name, Cloudflare will not know to load protection that you have set up on your Cloudflare account. Any Firewall rules, page rules, WAF, or Cloudflare Access configurations will not take effect.

If you use an AWS Application Load Balancer (ALB), This can be done by setting up a rule on your listeners:

When using nginx, you need to make sure that your current server block has the correct server_name block with your hostname in it. Then, you simply make another server block, but this time you set server_name to something like an underscore _ and have it return nothing or a 400 (bad request) error.

When dealing with SSL and nginx, use a snakeoil certificate or self-signed certificate.

server {
	listen 80 443 ssl;
	ssl_certificate /snakeoil.crt;
	ssl_certificate_key /snakeoil.key;
	server_name _;
	return 400;
}
server {
	listen 443 ssl;
	ssl_certificate /examplecom.crt;
	ssl_certificate_key /examplecom.key;
	server_name example.com;
	location / {
		...
	}
}

Since Cloudflare itself protects against HOST header spoofing, there is no way for an attacker to get around your site's Cloudflare configuration and protections. The Host header can't even be changed with workers.