How to Protect Your Domain with Cloudflare

If your website keeps getting hit with Layer 7 (HTTP flood) attacks, or your real server IP has leaked and Layer 4 (network) attacks are hitting the box directly, the fix is the same: never let anyone reach your origin server directly. Put Cloudflare in front of the domain, hide the origin IP, and only accept traffic that comes through Cloudflare. This guide walks through the full setup.

1. Add your domain to Cloudflare

1. Create a free account at dash.cloudflare.com and click Add a site.
2. Enter your domain and choose the Free plan.
3. Cloudflare gives you two nameservers. Log in to your domain registrar and replace the existing nameservers with those two.
4. Wait for the site status to become Active (usually minutes, sometimes a few hours).

2. Proxy every record through Cloudflare

Open DNS > Records and make sure the proxy status of your A / AAAA / CNAME records is Proxied (orange cloud), not DNS only (grey cloud). A grey-cloud record publishes your real IP in public DNS and defeats the entire setup.

Watch out for records that leak the origin even when the main site is proxied: a mail, ftp or cpanel subdomain, an old direct record, or an MX record pointing at the same server. Remove them, or move mail to a separate host. It only takes one grey-cloud record to expose the IP.

3. Set SSL to Flexible so your certificate cannot leak the IP

Even behind Cloudflare, if your origin serves an HTTPS certificate on port 443, scanning services such as Censys and Shodan can read the domain name off that certificate and tie it back to your IP. The simplest way to avoid this is to not serve HTTPS on the origin at all.

1. In Cloudflare open SSL/TLS > Overview and set the mode to Flexible. Visitors still get HTTPS from Cloudflare; Cloudflare talks to your origin over plain HTTP on port 80.
2. On the server, make your web server listen on port 80 only and stop serving 443. There is now no certificate on the origin for a scanner to fingerprint.

Flexible means the Cloudflare-to-origin hop is not encrypted. That is acceptable here because the next step blocks everyone except Cloudflare from reaching the server at all. If you want encryption end to end, use a Cloudflare Origin Certificate with Full (strict) instead, and keep port 443 firewalled to Cloudflare only.

4. Only allow Cloudflare to reach your server

This is what actually stops L4 attacks and direct hits even if your IP leaks: drop every connection to port 80 that does not come from a Cloudflare IP range. Cloudflare publishes its current ranges here:

• https://www.cloudflare.com/ips-v4
• https://www.cloudflare.com/ips-v6

Option A: UFW

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do ufw allow from $ip to any port 80 proto tcp; done
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do ufw allow from $ip to any port 80 proto tcp; done
ufw deny 80/tcp
ufw reload

Keep your SSH port open first (for example ufw allow 22/tcp) so you do not lock yourself out. UFW matches rules top to bottom, so the Cloudflare allows added above win over the deny.

Option B: iptables + ipset (easy to refresh)

ipset lets you refresh the Cloudflare list without rewriting your rules:

apt install -y ipset
ipset create cloudflare hash:net
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do ipset add cloudflare $ip; done
iptables -A INPUT -p tcp --dport 80 -m set --match-set cloudflare src -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

To refresh the ranges later (Cloudflare changes them from time to time), just flush and refill the set:

ipset flush cloudflare
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do ipset add cloudflare $ip; done

Put that refresh command in a weekly cron job so you never accidentally block a newly added Cloudflare range. Save your rules so they survive a reboot, for example with netfilter-persistent save (iptables) or by re-running the script on boot.

5. Stop an L7 flood with a challenge rule

Layer 7 attacks look like real HTTP requests, so blocking by IP is a losing game. Instead, make every visitor pass a check that a bot cannot: Cloudflare shows a lightweight challenge and only real browsers get through.

Fastest option during an attack: open Security > Settings and turn on Under Attack Mode. Every visitor gets a short interstitial check.

For a permanent, more targeted rule, go to Security > Security Rules > New Rule:

1. Name it, for example Challenge visitors.
2. Set the expression to match traffic to your site, e.g. http.host eq "yourdomain.com".
3. Set Action to Managed Challenge (or Interactive Challenge for a stricter CAPTCHA).
4. Deploy.

Tip: do not challenge your real visitors

If almost all your genuine users are in one country, challenge everyone except that country. Real users never see a CAPTCHA, while the flood, which usually comes from mixed or foreign IPs, still gets stopped. Set the rule expression to something like:

(http.host eq "yourdomain.com") and (ip.geoip.country ne "TR")

Replace TR with your main country code. This challenges all traffic that is not from Turkey. You can also add and cf.threat_score gt 10 to only challenge visitors Cloudflare already considers suspicious, cutting friction even further.

Quick checklist

• All DNS records Proxied (orange cloud); no grey-cloud leaks; mail moved off the origin.
• SSL set to Flexible; origin serving port 80 only; port 443 closed.
• Firewall drops port 80 from everything except Cloudflare ranges, refreshed on a schedule.
• A challenge rule ready to deploy (or Under Attack Mode) for L7 floods.

Done right, your origin IP stays invisible and unreachable, L4 attacks hit Cloudflare instead of your server, and L7 floods get filtered before they cost you anything.