Wer mehrere Dienste über Docker betreibt und diese aus dem Internet erreichbar machen möchte, kommt früher oder später an einem Reverse Proxy kaum vorbei. In meinem Setup übernimmt diese Aufgabe Traefik.
Ein Reverse Proxy alleine schützt die dahinterliegenden Anwendungen allerdings noch nicht vor automatisierten Angriffen, Scannern oder bekannten Web-Exploits. Deshalb kombiniere ich Traefik in diesem Stack mit CrowdSec und dessen AppSec/WAF-Funktion.
Das komplette Projekt befindet sich auf GitHub:
GitHub:
https://github.com/happylippo/traefik-crowdsec-stack
Der Stack ist für Docker Compose ausgelegt und enthält neben Traefik und CrowdSec auch einen Docker Socket Proxy sowie ein Installationsskript, das einen großen Teil der Erstkonfiguration übernimmt.
Was macht Traefik?
Traefik ist ein moderner Reverse Proxy und Load Balancer, der sich besonders gut für Docker eignet.
Statt für jede Anwendung einen eigenen Port direkt im Internet freizugeben, laufen die Anfragen zentral über Traefik.
Vereinfacht sieht das so aus:
Internet
│
▼
Traefik
│
├── blog.example.com
│ └── WordPress
│
├── grafana.example.com
│ └── Grafana
│
└── cloud.example.com
└── Nextcloud
Traefik entscheidet anhand des Hostnamens, welcher Container eine Anfrage erhalten soll.
Damit lassen sich zahlreiche Dienste über die gleichen Ports 80 und 443 betreiben.
Ein weiterer großer Vorteil ist die automatische Verwaltung von TLS-Zertifikaten über Let’s Encrypt.
Warum CrowdSec?
Ein öffentlich erreichbarer Server wird praktisch ständig von Bots durchsucht.
Typische Beispiele sind:
- automatisierte Port- und Webscanner
- Brute-Force-Angriffe
- Credential-Stuffing
- Exploit-Versuche
- WordPress-Scanner
- Bots auf der Suche nach bekannten Sicherheitslücken
- aggressive Webcrawler
Genau hier kommt CrowdSec ins Spiel.
CrowdSec analysiert unter anderem die Logs von Traefik und erkennt verdächtiges Verhalten anhand sogenannter Scenarios.
Eine IP-Adresse kann daraufhin beispielsweise blockiert werden.
CrowdSec verfolgt dabei einen interessanten Ansatz: Erkennt eine CrowdSec-Instanz einen Angreifer, können entsprechende Informationen über die CrowdSec-Community geteilt werden.
Dadurch profitieren andere CrowdSec-Systeme ebenfalls von bereits erkannten Angreifern.
CrowdSec AppSec als zusätzliche Schutzschicht
Der Stack verwendet nicht nur die klassische CrowdSec-Erkennung anhand von Logs, sondern zusätzlich CrowdSec AppSec.
AppSec arbeitet ähnlich wie eine klassische Web Application Firewall (WAF).
Dadurch können HTTP-Anfragen untersucht werden, bevor sie die eigentliche Anwendung erreichen.
Der Datenfluss sieht damit vereinfacht so aus:
Internet
│
▼
Traefik
│
▼
CrowdSec / AppSec
│
├── Anfrage erlaubt
│ │
│ ▼
│ Anwendung
│
└── Anfrage blockiert
│
▼
HTTP 403
Damit können beispielsweise bekannte Exploit-Muster abgefangen werden.
Gerade bei öffentlich erreichbaren Anwendungen wie WordPress ist diese zusätzliche Schutzschicht interessant.
Kein separater CrowdSec-Bouncer-Container mehr
Eine Besonderheit meines aktuellen Stacks ist die Integration von CrowdSec direkt in Traefik.
Frühere Versionen verwendeten dafür einen separaten traefik-crowdsec-bouncer-Container.
Dieser wurde inzwischen komplett entfernt.
Stattdessen verwendet Traefik direkt das:
crowdsec-bouncer-traefik-plugin
Aktuell ist im Stack Version:
v1.7.1
vorgesehen.
Damit wird eine zusätzliche Sidecar-Anwendung eingespart und die Kommunikation mit CrowdSec direkt über Traefik abgewickelt.
Die Architektur wird dadurch etwas übersichtlicher:
┌──────────────┐
Internet ──────►│ Traefik │
└──────┬───────┘
│
CrowdSec Plugin
│
▼
┌──────────────┐
│ CrowdSec │
│ + AppSec │
└──────────────┘
AppSec selbst ist innerhalb des Docker-Netzwerks über Port 7422 erreichbar.
Der Port wird dabei nicht auf dem Docker-Host veröffentlicht.
Dadurch ist die AppSec-Schnittstelle ausschließlich intern zwischen den beteiligten Containern erreichbar.
Docker Socket Proxy
Traefik benötigt Informationen über laufende Docker-Container, damit Container automatisch über Labels erkannt werden können.
Die einfachste Variante wäre, den Docker Socket direkt in Traefik einzubinden:
/var/run/docker.sock
Das ist allerdings sicherheitstechnisch nicht optimal.
Wer Zugriff auf den Docker Socket erhält, besitzt praktisch sehr weitreichende Kontrolle über den Docker-Host.
Deshalb enthält mein Stack einen separaten Docker Socket Proxy.
Die Architektur sieht damit so aus:
Traefik
│
▼
Docker Socket Proxy
│
▼
Docker API
Traefik erhält dadurch nur die API-Funktionen, die tatsächlich benötigt werden.
Das reduziert die Angriffsfläche erheblich gegenüber einem uneingeschränkt eingebundenen Docker Socket.
Aufbau des Stacks
Das Repository ist modular aufgebaut.
Die eigentlichen Dienste befinden sich unter anderem in:
compose/
├── traefik.yml
├── crowdsec.yml
├── socket-proxy.yml
└── networks.yml
Die zentrale Datei:
docker-compose.yml
bindet diese Bestandteile zusammen.
Zusätzlich befinden sich die jeweiligen Konfigurationen unter:
data/
Dadurch bleiben Docker-Compose-Konfiguration und Anwendungsdaten sauber voneinander getrennt.
Traefik 3.7
Als Reverse Proxy verwendet der Stack standardmäßig:
Traefik 3.7
Traefik besitzt einen eigenen Healthcheck:
traefik healthcheck --ping
Dadurch kann Docker erkennen, ob Traefik tatsächlich betriebsbereit ist.
Außerdem startet Traefik erst, nachdem sowohl CrowdSec als auch der Socket Proxy ihren Healthcheck erfolgreich bestanden haben.
HTTP/3 Unterstützung
Neben klassischem HTTPS über TCP-Port 443 veröffentlicht der Stack Port 443 zusätzlich über UDP.
Damit steht die Grundlage für HTTP/3 beziehungsweise QUIC zur Verfügung.
Die Portbelegung sieht entsprechend so aus:
TCP 80 → HTTP
TCP 443 → HTTPS
UDP 443 → HTTP/3 / QUIC
Gerade bei modernen Browsern kann HTTP/3 Vorteile bei Verbindungsaufbau und Latenz bringen.
Automatische TLS-Zertifikate
Ein wichtiger Bestandteil von Traefik ist die automatische Ausstellung und Verlängerung von TLS-Zertifikaten.
Mein Stack unterstützt mehrere Verfahren.
Zur Auswahl stehen:
tls_resolver
cloudflare_resolver
desec_resolver
TLS-Challenge
Die TLS-Challenge benötigt keinen DNS-Provider und keinen API-Key.
Sie eignet sich für normale Zertifikate wie:
traefik.example.com
Wildcard-Zertifikate sind damit allerdings nicht möglich.
Cloudflare DNS-Challenge
Wer seine DNS-Zone bei Cloudflare betreibt, kann die DNS-01-Challenge verwenden.
Damit lassen sich beispielsweise Zertifikate für
example.com
und
*.example.com
erzeugen.
Benötigt wird dafür ein eingeschränktes Cloudflare API-Token.
Das Token sollte lediglich die notwendigen Rechte besitzen:
Zone / DNS / Edit
Zone / Zone / Read
Im Stack wird das Token nicht in der normalen Compose-Datei hinterlegt, sondern in:
data/traefik/.env
deSEC DNS-Challenge
Alternativ unterstützt der Stack auch deSEC.
Dafür wird ein entsprechender deSEC Domain-Token benötigt.
Die Auswahl erfolgt ebenfalls über die .env-Datei.
Damit lassen sich auch über deSEC Wildcard-Zertifikate automatisch über Let’s Encrypt beziehen.
Cloudflare Reverse Proxy
Cloudflare kann unabhängig vom verwendeten Zertifikatsresolver vor Traefik betrieben werden.
Damit ist zum Beispiel folgendes Setup möglich:
Internet
│
▼
Cloudflare
│
▼
Traefik
│
▼
Docker-Anwendung
Verwendet man Cloudflare als Proxy, muss Traefik allerdings die tatsächliche Client-IP korrekt erkennen können.
Dafür können die offiziellen Cloudflare-Netze als:
forwardedHeaders.trustedIPs
eingetragen werden.
Das Installationsskript fragt automatisch, ob diese Konfiguration übernommen werden soll.
Wichtig ist dabei:
Trusted Forwarded Headers schützen die Origin-IP nicht.
Soll der Server ausschließlich über Cloudflare erreichbar sein, müssen die Ports 80 und 443 zusätzlich beispielsweise über die Provider-Firewall oder die lokale Firewall ausschließlich für die offiziellen Cloudflare-Netze freigegeben werden.
Das Installationsskript
Um die Erstinstallation zu vereinfachen, enthält das Repository:
first_install.sh
Das Skript übernimmt einen großen Teil der notwendigen Konfiguration.
Unter anderem werden interaktiv Werte wie folgende abgefragt:
- Domain für das Traefik-Dashboard
- Zertifikatsresolver
- Zertifikatsdomain
- Wildcard-Domain
- Benutzername für das Traefik-Dashboard
- Passwort für das Dashboard
- API-Token für Cloudflare oder deSEC
- optionale Cloudflare Trusted IPs
Zusätzlich werden die notwendigen Konfigurationsdateien aus den .sample-Dateien erzeugt.
Dadurch muss nicht jede einzelne Konfigurationsdatei von Hand erstellt werden.
Installation
Zunächst wird das Repository geklont:
mkdir -p /opt/containers/
git clone \
https://github.com/happylippo/traefik-crowdsec-stack \
/opt/containers/traefik-crowdsec-stack
Danach wechseln wir in das Verzeichnis:
cd /opt/containers/traefik-crowdsec-stack
Das Installationsskript ausführbar machen:
chmod +x first_install.sh
und anschließend starten:
./first_install.sh
Das Skript führt anschließend durch die wichtigsten Einstellungen.
Stack starten
Nach erfolgreicher Konfiguration kann der komplette Stack gestartet werden:
docker compose up -d
Bei einem Upgrade von einer älteren Version empfiehlt sich:
docker compose up -d --remove-orphans
Damit wird beispielsweise ein eventuell noch vorhandener alter CrowdSec-Bouncer-Sidecar entfernt.
Container überprüfen
Anschließend kann man kontrollieren, ob alle Container laufen:
docker compose ps
Die Logs von Traefik:
docker compose logs -f traefik
und CrowdSec:
docker compose logs -f crowdsec
anzeigen.
CrowdSec überprüfen
Ob CrowdSec funktioniert, lässt sich beispielsweise mit folgendem Befehl prüfen:
docker exec -it crowdsec cscli metrics
Aktuelle Entscheidungen beziehungsweise blockierte IP-Adressen:
docker exec -it crowdsec cscli decisions list
Installierte Collections:
docker exec -it crowdsec cscli collections list
und die registrierten Bouncer:
docker exec -it crowdsec cscli bouncers list
Neue Anwendungen hinter Traefik betreiben
Ist der Stack einmal eingerichtet, können weitere Docker-Anwendungen relativ einfach an das gemeinsame Proxy-Netzwerk angebunden werden.
Ein Dienst kann beispielsweise über entsprechende Traefik-Labels veröffentlicht werden.
Prinzipiell sieht das so aus:
labels:
traefik.enable: "true"
traefik.http.routers.meinservice.entrypoints: websecure
traefik.http.routers.meinservice.rule: >
Host(`service.example.com`)
traefik.http.routers.meinservice.tls: "true"
traefik.http.services.meinservice.loadbalancer.server.port: "8080"
Damit muss der Port 8080 nicht direkt am Host veröffentlicht werden.
Der Zugriff erfolgt ausschließlich über Traefik:
https://service.example.com
Zusätzliche Middlewares
Traefik bietet über sogenannte Middlewares zahlreiche Möglichkeiten, Anfragen weiter abzusichern oder zu verändern.
Im Repository befinden sich dafür bereits verschiedene dynamische Konfigurationen.
Beispiele sind:
Security Headers
Komprimierung
Dashboard-Authentifizierung
Standard-Middlewares
TLS-Konfiguration
Da diese Konfigurationen über den File Provider geladen werden können, müssen sie nicht zwangsläufig über lange Docker-Label-Blöcke definiert werden.
Das macht komplexere Konfigurationen deutlich übersichtlicher.
Schutz in mehreren Ebenen
Besonders interessant wird der Stack durch die Kombination mehrerer Schutzmechanismen.
Die komplette Kette kann beispielsweise so aussehen:
Internet
│
▼
Cloudflare
│
├── DDoS-Schutz
├── WAF
└── Bot-Schutz
│
▼
Server-Firewall
│
▼
Traefik
│
▼
CrowdSec Plugin
│
▼
CrowdSec AppSec
│
▼
Security Middleware
│
▼
Anwendung
Keine einzelne dieser Komponenten sollte als vollständiger Schutz betrachtet werden.
Zusammen ergeben sie jedoch eine deutlich robustere Sicherheitsarchitektur.
Vorteile des Stacks
Für mich hat die Kombination einige klare Vorteile.
Zentrale Verwaltung
Alle öffentlich erreichbaren Docker-Dienste laufen über einen Reverse Proxy.
Automatische TLS-Zertifikate
Let’s Encrypt übernimmt Ausstellung und Verlängerung der Zertifikate.
Wildcard-Zertifikate
Über Cloudflare oder deSEC können auch Wildcard-Zertifikate verwendet werden.
CrowdSec-Integration
Bekannte Angreifer und verdächtige Clients können bereits auf Reverse-Proxy-Ebene blockiert werden.
AppSec/WAF
HTTP-Anfragen können zusätzlich auf bekannte Angriffsmuster untersucht werden.
Docker Socket Proxy
Traefik benötigt keinen direkten uneingeschränkten Zugriff auf /var/run/docker.sock.
HTTP/3
Der Stack ist bereits für HTTP/3 über UDP 443 vorbereitet.
Automatisierte Installation
Das first_install.sh-Skript nimmt einen großen Teil der manuellen Konfiguration ab.
Was der Stack nicht ersetzt
Trotz CrowdSec und AppSec bleiben klassische Sicherheitsmaßnahmen weiterhin notwendig.
Dazu gehören insbesondere:
- regelmäßige Updates
- starke Passwörter
- MFA beziehungsweise Passkeys
- restriktive Firewall-Regeln
- sichere SSH-Konfiguration
- regelmäßige Backups
- Monitoring
- möglichst wenig öffentlich erreichbare Dienste
- sichere Konfiguration der Anwendungen selbst
CrowdSec ist eine zusätzliche Verteidigungsschicht und kein Ersatz für grundlegendes Server-Hardening.
Fazit
Die Kombination aus Traefik, CrowdSec und CrowdSec AppSec ist für mich eine sehr interessante Grundlage für öffentlich erreichbare Docker-Dienste.
Traefik übernimmt Routing, TLS und die zentrale Veröffentlichung der Anwendungen. CrowdSec analysiert verdächtiges Verhalten und kann bekannte Angreifer blockieren. AppSec ergänzt das Ganze um eine WAF-ähnliche Prüfung eingehender Webanfragen.
Durch den zusätzlichen Docker Socket Proxy erhält Traefik außerdem keinen direkten uneingeschränkten Zugriff auf den Docker Socket.
Besonders praktisch ist das mitgelieferte Installationsskript. Es automatisiert einen großen Teil der Erstkonfiguration und unterstützt verschiedene Setups – vom einfachen TLS-Zertifikat bis zur DNS-Challenge über Cloudflare oder deSEC.
Wer mehrere selbstgehostete Anwendungen über Docker betreibt und einen zentralen Reverse Proxy mit zusätzlicher Sicherheitsschicht sucht, findet damit eine solide Ausgangsbasis.
Repository:
https://github.com/happylippo/traefik-crowdsec-stack
