Lutz Finsterle 61c008216f CrowdSec v1.7.8 -> v1.8.1
1.8.0 ist weitgehend additiv (Bot-Detection ist opt-in, dazu eine k8s-Quelle)
und schliesst zwei DoS-Luecken in der HTTP- und der k8s-audit-Acquisition -
beide nutzen wir hier nicht, GHSA-g2x2-jgfg-pg7g und GHSA-rh69-4vqj-9gj8.
1.8.1 korrigiert nur einen Fehlalarm der Bot-Erkennung.

Vor dem Austausch beide Volumes kalt gesichert (Config 446K, DB 38M unter
/home/lutz/backups). Danach geprueft: Collections alle enabled, Syslog-Quelle
der Synologies lauscht wieder auf 5514, Traefik-Access-Log wird getailt,
Decisions erhalten.

Den MikroTik-Bouncer hinterher bewusst neu gestartet statt auf "Container
laeuft" zu vertrauen - er merkt einen LAPI-Neustart erst beim naechsten
Handshake, genau daran hing der stille Ausfall im September. Er meldet
wieder "Address ... already present" gegen die Address-List der AX3.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-24 09:43:10 +02:00
2026-10-24 09:43:10 +02:00

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 – 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

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 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
Description
No description provided
Readme 50 KiB
Languages
Shell 100%