How CrowdSec Changed My Approach to Homelab Security After Exposing Services With Pangolin

How CrowdSec Changed My Approach to Homelab Security After Exposing Services With Pangolin

Exposing my public-facing services through Pangolin completely changed how I think about securing a homelab. Previously, my primary concerns were container uptime and server reliability. Once those services became accessible from the internet, however, a new question emerged: who was actually trying to access them?

My Omada ER605 firewall was performing exactly as expected, blocking unsolicited traffic before it reached my network. But once legitimate requests passed through to my reverse proxy, the firewall’s role effectively ended. Out of curiosity, I decided to deploy CrowdSec, and within just a few hours, it had already begun identifying genuine exploit attempts.

The Firewall Was Only Part of the Security Picture

The Threats Had Already Reached the Reverse Proxy

My homelab setup is fairly straightforward:

• A repurposed business laptop running bare-metal Debian
• Tailscale for private remote access
• Pangolin for securely exposing public services

Pangolin itself is built around four primary components:

• Pangolin Server, which acts as the control plane
• Gerbil, responsible for managing the WireGuard interface
• Traefik, serving as the reverse proxy
• Newt, Pangolin’s WireGuard client that establishes outbound connections to the VPS

Once configured, the Pangolin dashboard allows me to expose any number of self-hosted services publicly.

My Network Was Already Well Protected

At home, network security is handled by a TP-Link Omada ER605, a dual-WAN router balancing two internet connections with a 7:1 load distribution.

Like other routers in the ER series, it includes a stateful firewall that is more than sufficient for typical home use. It permits outbound traffic while rejecting unsolicited inbound connections that don’t belong to an existing session.

Nothing enters my local network unless the router explicitly allows it.

Carrier-Grade NAT (CGNAT) adds another layer of protection. Since both ISPs place my connection behind shared IP addresses, I don’t have a publicly routable static IP. As a result, many large-scale internet port scans targeting random public IPs likely never reach my home gateway.

Hosting on a VPS Changes the Security Model

Although my home server remains protected behind Pangolin and Traefik, Pangolin requires a VPS with a public static IP.

That means ports 80 and 443 must remain intentionally open.

Everything else stays blocked by the firewall.

This setup offers both advantages and trade-offs.

The firewall still blocks unwanted ports, but every valid HTTP request arriving on ports 80 and 443 reaches Traefik.

That includes:

• Login attempts
• Credential stuffing
• Automated bots
• CVE fingerprinting
• Other HTTP-based probes

These requests aren’t blocked because they are legitimate HTTP traffic entering through approved ports. At this stage, the router has already completed its job and never inspects the request contents.

That’s when I realized I needed a security solution capable of understanding application-layer traffic rather than simply filtering ports.

My search eventually led me to CrowdSec.

CrowdSec Started Detecting Threats Immediately

One Placeholder API Key Almost Took Everything Offline

To be clear, I wasn’t trying to replace either my home firewall or the VPS firewall.

The objective was to add another layer capable of analyzing HTTP behavior.

CrowdSec fit perfectly because it is:

• Free
• Community-driven
• Fully compatible with my existing Traefik deployment

Initially, the installation appeared straightforward.

I deployed CrowdSec as another container within the existing Pangolin Docker Compose stack and enabled the following collections:

• crowdsecurity/traefik
• crowdsecurity/http-cve
• crowdsecurity/http-dos

Since Pangolin’s Traefik configuration isn’t Docker label-based, I also needed to:

• Add crowdsec-bouncer to the experimental.plugins section in traefik_config.yml
• Enable accessLog
• Attach the middleware to the websecure entry point inside dynamic_config.yml

A Small Configuration Mistake Caused a Major Outage

After completing the initial configuration, I restarted the stack.

Unfortunately, I had overlooked one detail.

A placeholder API key was still present in the configuration.

Because the plugin couldn’t authenticate correctly, every incoming request failed, taking all six of my publicly exposed services offline for roughly ten minutes.

Once I identified the issue, I generated a valid API key using:

cscli bouncers add

After updating dynamic_config.yml with the correct key and restarting the stack, everything returned to normal. I reviewed the logs to confirm the deployment before moving on to connecting the engine with the CrowdSec Console.

Connecting CrowdSec to the Console

Compared with the initial setup, enrollment was simple.

I created an account on app.crowdsec.net and enrolled my local engine by running the Docker command generated from the enrollment key provided in the CrowdSec Console.

Only a couple of hours later, CrowdSec reported its first real detection.

It identified an http-technology-probing event targeting:

/owa/auth/x.js

The request originated from an Azure-hosted IP address.

Using:

cscli decisions list

I confirmed that CrowdSec had successfully enforced the corresponding ban.

One Week Later, the Data Told a Bigger Story

After nearly a week of continuous operation, the statistics became much more interesting.

During that period:

• Traefik consulted CrowdSec more than 8,000 times.
• Approximately 38 requests were blocked.

The relatively low block rate demonstrated that CrowdSec wasn’t aggressively blocking everything. Instead, it was making selective, behavior-based decisions.

What surprised me wasn’t the number of blocked requests.

It was the steady stream of traffic continuously reaching every public-facing service.

Visibility Completely Changed My Perspective

Internet Background Noise Is Constant

Reviewing a week’s worth of activity fundamentally changed how I view publicly exposed services.

I already understood that automated attacks existed across the internet.

Seeing those events directed at my own infrastructure, however, made the reality much more tangible.

It never felt like someone was personally targeting me.

Instead, the dashboard highlighted the constant background noise that every publicly accessible service experiences.

CrowdSec Sees What the Firewall Never Will

This didn’t make my ER605 any less valuable.

Nor did it suggest the firewall had failed.

Its job simply isn’t to inspect HTTP traffic.

As I explored CrowdSec further, I discovered another significant source of protection: its community intelligence.

The CrowdSec Community Blocklist (CAPI-origin) had already identified more than 32,000 bans covering:

• Brute-force attacks
• HTTP scans
• Exploit attempts

These detections came from other CrowdSec users across the community.

By comparison, my own local instance had generated approximately 205 detections.

That means many malicious IP addresses were already known and blocked before they ever interacted with my infrastructure.

Pangolin and CrowdSec Serve Different Purposes

Over time, it became clear that Pangolin and CrowdSec solve two separate problems.

Pangolin focuses on securely exposing services to the internet.

CrowdSec continuously monitors every request after those services become publicly accessible.

Rather than replacing one another, they complement each other by adding an extra layer of protection.

I originally installed CrowdSec simply to validate a theory.

After seeing the constant flow of automated activity, relying solely on firewall protection no longer felt sufficient.

Understanding What “Exposed” Really Means

Before deploying CrowdSec, I assumed my default firewall configuration handled nearly all of the security work.

Now I have a much clearer understanding of where the firewall’s responsibilities end—and where application-layer protection begins.

After running CrowdSec for a full week, the biggest takeaway wasn’t the total number of blocked requests.

It was the visibility.

Understanding what “publicly exposed” actually looks like has been far more valuable than any individual detection statistic.

Today, CrowdSec has become one of those tools that quietly operates in the background, continuously monitoring traffic and handling the threats I no longer want to investigate manually.