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>
Das Image stammte vom 22.06.2026; der Tag v3.7 war seither elf Patch-Releases
weiter. Jetzt explizit gepinnt, damit ein Neustart nicht unbemerkt die Version
wechselt. Nach dem Austausch geprueft: Apex und beide Pangolin-Subdomains
antworten wie vorher, das CrowdSec-Plugin laedt seinen Stream-Cache.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Die Traefik-Konfiguration unter /srv/TRAEFIK/etc/traefik ist jetzt in einem
eigenen Repo (lutz/TraefikConfig) versioniert; hier steht, wie die beiden
Repos zusammenspielen und was wo liegt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Since Jul 12 the stack ingests Synology DSM syslog (fids/fids2 -> Log
Center -> 192.168.0.142:5514/udp), but only the published port was in the
working tree and the actual config lived exclusively in the crowdsec-config
named volume -- a volume reset would have silently dropped the Synology
detection and the escalating ban policy.
Moved into the repo and bind-mounted (single source of truth; the shadowed
copies were removed from the volume):
- crowdsec/acquis-synology.yaml -> acquis.d/synology.yaml (syslog listener)
- crowdsec/parsers/famfihome-synology-connection.yaml -> s01-parse/
(local parser for DSM 7 "Connection" failed sign-ins -> synology-dsm-bf)
- crowdsec/profiles.yaml (escalating ban (count+1)*12h, capped at 168h)
Also commits the previously untracked 5514:514/udp port mapping.
Verified after recreate: syslog listener bound on :514, lines arriving from
192.168.0.234, traefik access.log tail active, local parser loaded, cscli
explain on a DSM sign-in failure still reaches crowdsecurity/synology-dsm-bf,
26 active decisions preserved, both bouncers pulling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- New crowdsec-mikrotik-bouncer service: mirrors CrowdSec decisions into a
RouterOS address-list on the AX3 for WAN edge-dropping (covers all ports,
incl. VPN/SSH), complementing the L7 Traefik bouncer.
- Connects over api-ssl/TLS using an OpenBAO-issued cert; trusts the OpenBAO
root+intermediate via SSL_CERT_FILE (crowdsec/famfi-ca-bundle.pem).
- Secrets (MIKROTIK_PASS, LAPI key) kept in root-only .mikrotik.env, git-ignored.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
