Securing Your Website (Part 2): Cloudflare Tunnels, WAF Traps, and More Hands-On Security

 

            So it goes...

 

 

After setting up my website with Cloudflare Tunnels to bypass ISP restrictions and adding some basic WAF rules, I kept hounding up Cloudflare's security features. It turns out there's a whole world out there, and there's much more you can do. So, be advised, this blogpost won't even touch upon 1% of what you can really pull given enough time and effort.

Let me be clear—I’m no expert. I’m just learning by doing, breaking stuff, re-making the configs, fixing what can be fixed, and documenting most things as I go along. You can too. This is not a deep technical dive, it’s a hands-on log of things I found fun and useful. YMMV.

📌 Step 1: Making Sure the Tunnel Survives Reboots

If you recall, in the last post, I set up a Cloudflare Tunnel to keep my server accessible and bypass my ISP blocking inbound traffic. But the tunnel was running manually. If the machine rebooted, the tunnel wouldn’t come back up unless I started it again.

That’s where systemd comes in.

With a systemd service, we can make sure the tunnel starts automatically when the machine boots, and even gets restarted if it crashes.

Here’s the basic idea:

• We create a service file that tells the system how to run cloudflared

• We point it to the tunnel config and credentials file

• We enable the service so it runs at startup

   

                Ain't much, but it's enough.

It’s fairly straightforward, really. If you haven’t used systemd before, it’s just a way for Linux to manage long-running background tasks. And a whole can of worms if you're, say, over 30 years old or so.

Now, every time my server restarts, the tunnel comes back automatically. No more downtime.

📌 Step 2: WAF Traps and Custom Blocks

I started testing different WAF rules to create little security tripwires—fake URLs and suspicious patterns that only bots or scanners would trigger.

✅ Honeypot Rule: I created a fake path (/admin-panel) that doesn’t actually exist on my site. Then I wrote a rule:

(http.request.uri.path eq "/admin-panel")

Action: Block

Any legit user would have little reason to visit that URL. If something does, it’s (likely) a scanner or a bot poking around for admin panels. This gets blocked, and the event is logged in Cloudflare for review. Nifty!

 ✅ Blocking curl POSTs to /submit. Because why not?

(http.request.method eq "POST" and http.request.uri.path eq "/submit")

Action: Block

This is another tripwire. I can still use GET on that path, but any POST—especially from a script—is blocked. I tested this with curl -X POST and saw the request get blocked. 

✅ Country WAF Rule vs. Tor: I also blocked a specific country and then tested the rule using Tor Browser. Guess what? Tor got through. This was a cool discovery because it shows how Tor exit nodes might evade country-based blocking unless you explicitly block Tor IPs using Cloudflare’s $tor variable (aaand, you totally can do just that). So, while regular Proxy sites were getting Captcha challenged (and failing), Tor got through squeeky clean.

 

                Nope. And Bot Protection will not let you verify. Go figure.

                   Yup.

📌 Step 3: Cloudflare Logs and Visibility

Cloudflare gives you a lot of visibility into what’s hitting your site:

• What paths are being accessed

• Whether the traffic was challenged, blocked, or allowed

• Which rule triggered

• What country, ASN, and IP the request came from

You can see all this under Security → Events. I reviewed the logs and noticed traffic from VPNs, proxies, and scrapers. I had seen this before, over one year ago, when my website actually existed. At that time, I hashed an impromptu firewall and logging system and was totally amazed at the amount of automatic attempts at entering my website, or specific pages of it.

As for Cloudflare, you have that and a lot other tools, like Cloudflare API or GraphQL queries to pull logs automatically, and which I totally need to get into as soon as I get the time.

📌 Step 4: You Don’t Have to Be an Expert

If there’s one thing I want you to take from this, is that we're all ignorant, or at least we start ignorant, and we just keep on learning and learning.

Back when I was an acting teacher, I was asked about being an actor, and how to become good. My answer then is the same I have for you today: "You fall in love with what you do. You do it every day, whenever you have the time, and little by little you become good."

📌 Step 5: Secure Remote Access with Tailscale (or WireGuard)

When you’re running your site from your own machine (or a Raspberry Pi), you probably want a way to connect to it remotely and securely.

As far as I know, you can do it with Cloudflare Enterprise (Zero Thrust), but I haven't explored that (yet). 

Another way is Tailscale, or tunneling from your router, with Admiral, for example. The one I picked is Wireguard.

This blogpost has been long enough. So here’s the basic idea:

• Install WireGuard on both your server and client devices to generate the necessary private and public key pairs.

Set up the client config to ensure secure connections through the VPN.

Access SSH through the WireGuard VPN by connecting to the server’s internal VPN IP address.

Like I said, you don't lack options on how to configure and access you server. You just need to pick one, understand why it works and use it.

📌 What’s Next?

Heck if I know. I'm just here for the ride.

Happy Father's Day.