Hardening Traefik with CrowdSec forwardAuth in a Homelab Reverse-Proxy Stack

A reverse proxy sitting on the internet without behavioral threat detection is just a traffic forwarder with extra steps. You can lock down ports, pin TLS certificates, and layer on basic auth, but none of that tells you whether the requests hitting your services are legitimate or part of an automated attack. Wiring CrowdSec into Traefik’s forwardAuth gives you that missing detection layer, and in a homelab it is surprisingly practical to set up.

TL;DR

This stack hardens Traefik by routing traffic on the https entrypoint through a CrowdSec forwardAuth bouncer, backed by Traefik access-log ingestion. It works, but there are important tradeoffs: trustForwardHeader: true, insecureSkipVerify: true, debug logging, and :latest tags on CrowdSec components all need tightening before this is production-grade.

Everything below is grounded in these homelab files:

• docker/traefik/compose.yaml
• docker/traefik/data/traefik.yml
• docker/traefik/data/config.yml
• docker/crowdsec/compose.yaml
• docker/crowdsec/config/acquis.yaml
• docker/traefik/TRAEFIK_GUIDE.md

What is Traefik?

Traefik is a modern reverse proxy and load balancer designed for containerized environments. It auto-discovers services through Docker labels, handles TLS termination, and routes incoming HTTP/HTTPS traffic to the right backend. If you run Docker services behind a domain, Traefik is likely your front door. For a deeper introduction, see our post on what Traefik is and why it’s the go-to reverse proxy for homelabs.

What is CrowdSec?

CrowdSec is an open-source behavioral detection engine. It ingests logs (in this case, Traefik access logs), applies community-curated threat scenarios, and makes ban/allow decisions that bouncers enforce at the edge. Think of it as fail2ban with a crowd-sourced threat intelligence feed and a cleaner architecture. For the full breakdown, see our post on what CrowdSec is and how it adds threat intelligence to your homelab.

Why this pattern

In this homelab, Traefik is the front door (80/443) and CrowdSec handles detection and decisions. The key design choice is to enforce CrowdSec checks at the Traefik https entrypoint via forwardAuth, not router by router. That is less error-prone in day-to-day operations.

Concrete walkthrough

1) Define the CrowdSec forwardAuth middleware

From docker/traefik/data/config.yml:

http:
  middlewares:
    crowdsec-bouncer:
      forwardAuth:
        address: http://bouncer-traefik:8080/api/v1/forwardAuth
        trustForwardHeader: true

This points Traefik to the bouncer container over the shared Docker proxy network.

2) Apply that middleware on the HTTPS entrypoint

From docker/traefik/data/traefik.yml:

entryPoints:
  https:
    address: ':443'
    http:
      middlewares:
        - crowdsec-bouncer@file

This is the important part. With entrypoint-level middleware, every HTTP router on https gets the CrowdSec auth check by default.

3) Make sure CrowdSec can actually parse Traefik logs

From docker/crowdsec/compose.yaml:

services:
  crowdsec:
    environment:
      COLLECTIONS: 'crowdsecurity/linux crowdsecurity/traefik'
    volumes:
      - ../traefik/logs:/var/log/traefik/:ro

  bouncer-traefik:
    environment:
      CROWDSEC_AGENT_HOST: crowdsec:8080

From docker/crowdsec/config/acquis.yaml:

filenames:
  - /var/log/traefik/*
labels:
  type: traefik

If CrowdSec cannot ingest and classify Traefik logs, forwardAuth has far less decision context.

Have you hit issues getting CrowdSec to parse your Traefik logs correctly? Log format mismatches between Traefik versions and CrowdSec parsers are one of the most common stumbling blocks in this setup.

4) Keep dashboard exposure constrained

From docker/traefik/compose.yaml, the dashboard is already on HTTPS with basic auth middleware and Cloudflare cert resolver:

- 'traefik.http.routers.traefik-secure.entrypoints=https'
- 'traefik.http.routers.traefik-secure.middlewares=traefik-auth'
- 'traefik.http.routers.traefik-secure.tls=true'
- 'traefik.http.routers.traefik-secure.tls.certresolver=cloudflare'
- 'traefik.http.routers.traefik-secure.service=api@internal'

That is a good baseline, but basic auth alone is weak for a high-value admin surface.

5) Deploy and verify

# Bring up Traefik
cd /Users/tucker/projects/homelab/docker/traefik
docker compose up -d

# Bring up CrowdSec + bouncer
cd /Users/tucker/projects/homelab/docker/crowdsec
docker compose up -d

Operational checks for this setup:

# Traefik should show routers/middlewares/providers loading
docker logs traefik | tail -n 200

# CrowdSec should show acquis/collection activity
docker logs crowdsec | tail -n 200

# Bouncer health and connection to crowdsec agent
docker logs bouncer-traefik | tail -n 200

From TRAEFIK_GUIDE.md, keep label conventions consistent (https entrypoint, correct proxy network, correct service port). Entrypoint typos are one of the fastest ways to break both routing and protection.

Security notes

• trustForwardHeader: true is a real tradeoff. It can be required for upstream context, but it increases header-spoofing risk if requests can arrive from untrusted intermediaries.
• serversTransport.insecureSkipVerify: true exists in traefik.yml. If this is not strictly required, remove it. TLS verification bypass is not a harmless default.
• api.debug: true and log.level: "DEBUG" are useful while tuning, but too chatty for steady-state production. They increase sensitive telemetry exposure and operational noise.
• crowdsecurity/crowdsec:latest and fbonalair/traefik-crowdsec-bouncer:latest make upgrades nondeterministic. Traefik is pinned (v3.6.5), but these two are not.
• Docker socket is mounted read-only in Traefik (/var/run/docker.sock:ro), which is better than RW, but still a high-impact mount if Traefik is compromised.
• Dashboard auth is currently basic auth. Add network-level restriction (VPN or IP allowlist) in front of it.

Lessons learned

• Entrypoint enforcement is cleaner than per-router drift. One middleware binding on https is easier to reason about.
• Log pipeline quality determines ban quality. If Traefik logging or acquis.yaml breaks, detection quality drops fast.
• Security hardening is less about adding one tool and more about eliminating weak defaults around it.
• Operational consistency matters: this repo’s TRAEFIK_GUIDE.md guidance to use https (not websecure) avoids a lot of self-inflicted outages.

What I’d do differently

1. Pin all security-critical images to explicit versions and update on a controlled cadence.
2. Change trustForwardHeader to false unless there is a demonstrated need, and explicitly trust only known upstream hops when needed.
3. Remove insecureSkipVerify: true unless I can document exactly why it is required.
4. Drop Traefik from DEBUG to INFO after validation and keep debug windows time-boxed.
5. Put the Traefik dashboard behind an additional control layer (VPN and/or IP allowlist), not just basic auth.
6. Explicitly attach security headers middleware on routers that should enforce it, then verify with response inspection.

Summary

• Enforce CrowdSec checks at the Traefik entrypoint level, not per-router, to avoid middleware drift across services.
• The log pipeline between Traefik and CrowdSec is the foundation of detection quality. If logs break, bans stop.
• Defaults like trustForwardHeader: true, insecureSkipVerify: true, and :latest tags are acceptable for initial setup but need tightening before you rely on this stack.
• Security hardening is cumulative. CrowdSec adds behavioral detection, but it does not fix weak auth, debug logging, or unpatched images.
• Pin your CrowdSec images, drop debug logging after validation, and layer network-level controls on admin surfaces.

References

• Traefik forwardAuth middleware docs: https://doc.traefik.io/traefik/middlewares/http/forwardauth/
• Traefik entrypoint docs (default middlewares on entrypoints): https://doc.traefik.io/traefik/routing/entrypoints/

What’s Your Setup?

If you are running Traefik with CrowdSec or a similar detection layer, I would like to hear how your stack differs. Are you enforcing at the entrypoint or per-router? Have you found community scenarios that work well for homelab traffic patterns? Share your setup or lessons learned — comparing notes is one of the best ways to catch blind spots in your own configuration.