Gemessen: nur 11.597 von 25.564 aktiven Decisions standen tatsaechlich auf dem Router (45,4 %), darunter 30 von 58 eigenen Bans. Ursache ist der Cache des Bouncers: Eintraege laufen per Timeout auf dem Router ab, der Cache meldet weiterhin 'already present' und legt sie nie neu an. Kein Versionsproblem - :latest ist digest-identisch mit v0.7.3 (neuestes Release, Apr 2025). Workaround ist ein taeglicher Neustart per cron (30 4 * * *), der die Liste komplett neu synchronisiert: 11.597 -> 25.037 in ~60 s, danach keine Requests mehr von bereits gelisteten IPs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
102 lines
4.6 KiB
Markdown
102 lines
4.6 KiB
Markdown
# Traefik-Stack (pi5-1)
|
||
|
||
Compose-Stack fuer den Reverse Proxy und die davor haengende CrowdSec-Abwehr.
|
||
|
||
| Service | Image | Aufgabe |
|
||
|---|---|---|
|
||
| `traefik` | `traefik:v3.7` | Reverse Proxy, TLS-Terminierung, ACME |
|
||
| `crowdsec` | `crowdsecurity/crowdsec:v1.7.8` | Erkennung aus Traefik-Access-Log + Synology-Syslog |
|
||
| `crowdsec-mikrotik-bouncer` | `ghcr.io/funkolab/cs-mikrotik-bouncer` | spiegelt Decisions als Drop-Regel auf die AX3 (Edge) |
|
||
|
||
Zusaetzlich haengt der **Traefik-Bouncer-Plugin** (`crowdsec@file`-Middleware)
|
||
direkt im Request-Pfad; die MikroTik-Seite blockt zusaetzlich auf Firewall-Ebene,
|
||
also auch VPN und SSH.
|
||
|
||
## Zwei Repos
|
||
|
||
Die **statische und dynamische Traefik-Konfiguration liegt NICHT hier**, sondern
|
||
unter `/srv/TRAEFIK/etc/traefik` (root-owned, in den Container als `/etc/traefik`
|
||
gemountet) und wird von einem eigenen Repo versioniert:
|
||
|
||
> **[`~/Projects/TraefikConfig`](http://192.168.0.234:8765/lutz/TraefikConfig)**
|
||
> – `traefik.yml`, `traefik.d/*`, TLS-Inventar, Sync-/Deploy-Skripte, Disaster Recovery
|
||
|
||
Hier im Repo liegt alles, was den *Stack* beschreibt:
|
||
|
||
```
|
||
docker-compose.yml Services, Ports, Volumes
|
||
crowdsec/acquis.yaml Acquisition: Traefik-Access-Log
|
||
crowdsec/acquis-synology.yaml Acquisition: Syslog-Listener (fids/fids2)
|
||
crowdsec/parsers/famfihome-synology-connection.yaml lokaler Parser: DSM-7-Anmeldefehler
|
||
crowdsec/profiles.yaml eskalierende Ban-Dauer (count+1)*12h, max 168h
|
||
crowdsec/famfi-ca-bundle.pem OpenBAO-CA (fuer RouterOS api-ssl)
|
||
scripts/sync-synology-certs.sh holt die Synology-LE-Certs nach Traefik
|
||
```
|
||
|
||
Alles unter `crowdsec/` wird per Bind-Mount ins Image gelegt, damit es ein
|
||
Zuruecksetzen der Named Volumes ueberlebt – die Dateien lagen frueher nur im
|
||
`crowdsec-config`-Volume und waren damit nicht gesichert.
|
||
|
||
## Bedienung
|
||
|
||
```bash
|
||
docker compose up -d # Stack starten
|
||
docker compose up -d crowdsec # nur CrowdSec neu erzeugen (nach Config-Aenderung)
|
||
|
||
docker exec crowdsec cscli metrics show acquisition # kommen Logs an?
|
||
docker exec crowdsec cscli decisions list # aktuelle Bans
|
||
docker exec crowdsec cscli bouncers list # ziehen die Bouncer?
|
||
```
|
||
|
||
Datenquellen pruefen: Traefik schreibt sein Access-Log ins geteilte Volume
|
||
`traefik-logs`, CrowdSec liest es read-only. Die Synologies senden per
|
||
DSM *Log Center → Log Sending* an `192.168.0.142:5514/udp`.
|
||
|
||
## Bekanntes Problem: MikroTik-Bouncer verliert Eintraege
|
||
|
||
**Symptom:** Gebannte IPs erreichen Traefik trotzdem noch, teils tagelang.
|
||
|
||
**Ursache:** Der Bouncer schreibt jeden Eintrag der Address-List `crowdsec` MIT
|
||
Timeout. Laeuft der Timeout auf dem Router ab, glaubt sein In-Memory-Cache
|
||
weiterhin, die Adresse sei vorhanden ("Address <IP> already present") und legt
|
||
sie nie neu an. Die Liste schrumpft dadurch kontinuierlich.
|
||
|
||
Gemessen am 2026-08-09: nur **11.597 von 25.564** aktiven Decisions waren
|
||
tatsaechlich auf dem Router (45,4 %) - auch 30 von 58 eigenen Bans fehlten.
|
||
In den zwei Stunden davor kamen 386 von 390 Requests von IPs, die gebannt
|
||
waren, aber nicht in der Liste standen.
|
||
|
||
**Kein Versionsproblem:** `:latest` ist identisch mit **v0.7.3** (neuestes
|
||
Release, Apr 2025, upstream seitdem still). Ein Update behebt es nicht.
|
||
|
||
**Workaround** (cron, Benutzer lutz): ein Neustart baut den Cache neu auf und
|
||
synchronisiert die komplette Decision-Liste (11.597 -> 25.037 in ~60 s,
|
||
danach 100 % der IPv4-Decisions durchgesetzt).
|
||
|
||
```
|
||
30 4 * * * /usr/bin/docker restart crowdsec-mikrotik-bouncer >/dev/null 2>&1
|
||
```
|
||
|
||
Der Schwund betraegt rund 130 Eintraege/Stunde (~12 %/Tag), der taegliche
|
||
Neustart begrenzt die Abdeckung also nach unten auf ca. 88 %. IPv6-Decisions
|
||
werden generell nicht uebertragen (`MIKROTIK_IPV6: "false"`).
|
||
|
||
Nachpruefen laesst sich das ueber die RouterOS-API (api-ssl 8729, CA-Bundle
|
||
`crowdsec/famfi-ca-bundle.pem`, SNI `mt-az.famfi.home`): Address-List-Eintraege
|
||
mit `list=crowdsec` zaehlen und gegen `cscli decisions list` halten. Die
|
||
Drop-Regel selbst (`/ip firewall raw`, chain=prerouting, in-interface-list=WAN)
|
||
ist in Ordnung - davor steht nur ein Whitelist-Accept mit RFC1918-Adressen.
|
||
|
||
## Secrets
|
||
|
||
`.mikrotik.env` (RouterOS-Passwort + Bouncer-API-Key) ist git-ignoriert und
|
||
root-only. Der LAPI-Key der Traefik-Middleware liegt in
|
||
`/srv/TRAEFIK/etc/traefik/traefik.d/crowdsec.yml` und ist ebenfalls bewusst
|
||
nicht versioniert – siehe TraefikConfig-README.
|
||
|
||
## Verwandt
|
||
|
||
- `~/Projects/TraefikConfig` – Traefik-Konfiguration (`/srv`), Restore-Prozedur
|
||
- `~/Projects/OpenBAO` – PKI und Credential-Helper
|
||
- `~/Projects/ClaudeAdmin` – 4-stuendlicher Healthcheck ueber den Stack
|