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.

Securing Your Website: Cloudflare Tunnels, WAF, and Bypassing ISP Restrictions

 

 

            *Poo-Tee-Weet?*

 

Following some really great advice from someone who was kind enough to give it, I decided to devote some time to Web Application Firewalls (WAF), IP masking, and network security, particularly using Cloudflare’s free tier.


Over a year ago, as part of my course's challenge at ATEC, I launched my own website: www.kernelcoredive.org (don’t rush to open this link—it's still under construction). It was a small space where I documented low-level programming concepts, mostly focusing on Assembly and computer architecture.

As time went on, I got caught up in my internship and stopped updating the site, shifting my focus to both LinkedIn and this blog.
But as this challenge came up, I went ahead and renewed my domain name on Namecheap.

This post (and the next one) will document my process, some issues I found and the subsequent solutions. If you’ve ever wanted to host your own website, this should help you get started. It’s surprisingly easy, costs about €15/year, and might introduce you to essential networking and security concepts.

---

📌 Step 1: Registering a Domain

First things first—you will need a domain name. This was done through a domain registrar. You can pick one from providers like GoDaddy, Namecheap, or the Cloudflare Registrar.

Once you choose a name and pay a small yearly fee, the domain is yours (and will be as long as you pay up). Now, we need a web server to actually host the website.

---

📌 Step 2: Setting Up an Apache Server

I set up an Apache web server on my machine to host the website. Since I don’t want to clutter this post with step-by-step Apache setup instructions, I'll just point you to an excellent guide: Server World.

Follow that documentation, and you’ll have Apache running locally in no time.
And do take a look at the site. I found it really helpful a year ago during my Linux classes.

---

📌 Step 3: Connecting My Domain to Cloudflare

Next, I signed up for a free Cloudflare account. This gives me access to DDoS protection, caching, and security tools.

Adding my domain was pretty simple—you just have to follow Cloudflare’s setup guide, and it will automatically scan your DNS records.

At this stage, I also updated my domain registrar’s DNS settings to use Cloudflare’s nameservers (again, follow the instructions set up by Cloudflare). This ensures all traffic is routed through Cloudflare before reaching my server.

---

🫢 Step 4: Issue: My ISP Blocks All Inbound Traffic

This is where I got to metaphorically bang my head against a wall and was failing at reaching my server.

I needed to link my public IP address to my domain—something I had done in the past without issues. But this time, no matter how hard I tried, I couldn’t access my public IP.

After testing with nmap and other tools, I confirmed that my ISP was blocking all inbound traffic. My router was not allowing requests to reach my server, no matter what ports I used.

 I also couldn’t simply port-forward my way out of this. After carefully checking my ISP router settings, I found that port forwarding wasn’t available at all.

A possible solution? Creating a Cloudflare Tunnel.

---

📌 Step 4: Setting Up a Cloudflare Tunnel

A Cloudflare Tunnel allows outbound connections from my server to Cloudflare, bypassing ISP restrictions entirely.

I installed it with:

curl -fsSL https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared
sudo mv cloudflared /usr/local/bin/
cloudflared tunnel login

However, I ran into a DNS conflict issue. While cloudflare had created a couple of A records for my server, I needed in fact a CNAME record instead. While A records point towards an IP, a CNAME record would allow for cloudflare to route traffic through the tunnel. So, I deleted the A records and created the necessary CNAME record.

This is all done under the DNS tab on cloudflare, btw.

---

📌 Step 5: Enabling HTTPS with Free SSL

With my tunnel working, my website was now accessible over HTTP. But I wanted encryption (HTTPS), so I added a free SSL certificate from Let’s Encrypt. I had done this a year ago, and it was as simple as it was before.

Again, I won’t bore you with the step-by-step setup—Let’s Encrypt is easy to install, free, and a game-changer for web security.

Then, I went to Cloudflare > SSL/TLS > Edge Certificates and enabled:
✅ Always Use HTTPS
✅ Full (Strict) SSL mode

 

---

📌 Step 6: Configuring Apache & Cloudflare

Cloudflare was now handling HTTPS redirection, so I had to disable Apache’s HTTPS redirect to prevent a redirect loop.

I edited /etc/apache2/sites-available/kernelcoredive.conf and commented out these lines:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

And restarted Apache.

Note that these lines might not be exactly like this in your setup. Look for any lines handling redirection in your configuration file and comment them out to avoid conflicts with Cloudflare’s HTTPS enforcement.

Now, my website was fully accessible, bypassing my ISP’s filtering.

---

🔒 Step 7: Adding Security – WAF & Bot Protection

With my site running through Cloudflare, I started testing Web Application Firewall (WAF) rules.

I created two rules:
1️⃣ Blocking a specific country (e.g., blocking all traffic from a particular region).
2️⃣ Configured a CAPTCHA challenge for any requests using the python-requests User-Agent.

I tested this out with:

curl -A "python-requests" https://kernelcoredive.org

You might be a bit more refined in your tastes, and have a test that actually addresses the Captcha part. Either way, and as you can see, the logs can show us these failed communication attempts.

I also enabled Cloudflare’s basic bot fight mode, which is included in the Free Tier: 

---

📌 Step 8: Next Steps

Right now, the Cloudflare Tunnel is running manually, meaning if my machine reboots, or if I close the service, the tunnel stops.

Tomorrow, I’ll create a systemd service to keep my tunnel online 24/7 on a Raspberry Pi.
I'm also going to subscribe to the pro tier, in order to practice with these and other concepts for the next month. This stuff is fun, and gives us a ton of flexibility on what and how many tiers of protection we want to implement.I also want to explore the Cloudflare API to see what kind of automation and security controls I can implement.


Fun! There's more tomorrow.

I Dislike Soft Skills Talk—So Hear Me Out on Soft Skills.

 

                    "Where be yer low level ramblings, ye heathen?"

技 (Waza) – technique, skill, or ability

Lacking the time to properly organize my thoughts on malware and cybersecurity (or whatever strikes my fancy), I might as well put forth something else that's been dangling in my mind, persistently nagging to come out and play: the importance of soft skills in IT in general (cybersecurity included).

Being a techie myself, loving all (yeah, right) most things technical, and truly an introvert at heart, I can say without hesitation that I don't really appreciate the constant call for newcomers in both IT and cyber to focus hard on the "soft" side of their skills.

We're led to believe that these skills are oh-so-fundamental, to the point where instead of drilling into the technical basics and particulars of each profession, we get video after video, article after article, and mouthpiece after mouthpiece telling us to prioritize social aspects. I've even seen cybersecurity folks claim that if they could redo their path to cyber mastery (or whatevs), they'd go back to college and focus much more on networking (the human kind) while paying less attention to the technical side.

I take a hard stance against this.

• Our fields are highly technical in nature.

• We DO have a significant technical knowledge gap.

• Most of this knowledge takes years to grasp, master, and apply.

• These so-called soft skills are actually quite easy to learn and deploy.

Sure! You won’t become a master speaker or the next Shakespeare in a couple of months, but you don’t need to be. You just have to be able to communicate clearly—enough that those less technically inclined can understand you.

 

Where am I coming from with all this certainty about these much-hyped social skills—the so-called golden key to a successful tech career? Well, before diving into IT, even before working in math, I worked as an actor, director, screenplay writer, and acting teacher for over 15 years. So I might know a thing or two about speaking before a live audience, presenting oneself, and communicating effectively.

 

I don’t claim to be the greatest expert—far from it. But I’ve walked the walk and talked the talk, and now that I’m in IT, I can tell you: the two are not even remotely comparable.

My long-term goals in 'IT' are harsh, to put it mildly. Heck, I must have been very drunk when my brain decided that low-level code, reverse engineering, and poking at weird malware was the greatest invention since sliced bread. But even just talking about mastering the basics needed to apply with any real confidence to cyber positions—the often-mentioned triad of programming, systems, and networking—takes serious effort. To actually understand these fields, to feel comfortable discussing them, to even recognize what’s being said in a conversation? Believe me, acting is easier. Speaking in public, presenting your thoughts in a structured manner—these things are much easier.

Now, granted, you might not want to do it. You might be shy, socially averse, or a bloody introvert like me. But that doesn’t make it difficult. It just makes it uncomfortable.

So, is this blog post just an excuse to ramble against soft skills?

No, not really. Just because I dislike something—or the exaggerated emphasis placed on it—doesn’t mean it’s wrong. Quite the contrary.

Soft skills are, in fact, useful. Knowing how to write, speak, present yourself—in one word, communicate—is undeniably important.

 

Just recently, I had to coordinate a troubleshooting session remotely, where instructions had to be relayed to a team that wasn’t entirely familiar with the technical process—and let’s just say that language barriers didn’t help. Communication isn’t just about simplifying tech for upper management. Sometimes, it’s about conveying precise, critical steps to people who need to act on them immediately, without confusion.

In the end, it worked. But it was quite the ride, and I found myself pivoting, adapting and adjusting, in order to get the troubleshooting steps through and carry on with what we were doing.

So, yeah. There’s that too. Communication takes many forms, and you’ll need it sooner rather than later. Don’t just ignore it. And, to re-iterate some good and bad news: it’s much easier to learn and quicker to grasp than you might think—but that doesn’t mean you’ll enjoy it.

 

Enjoy the ride, though. If at all possible.

 

A former acting colleague once said: life is just the backstage intermezzo you take between being on stage.

 

I don’t like that statement. But he might be right.