Brute-force detection doesn't cover Vaultwarden or Navidrome native logins #121

New issue

Open

opened 2026-08-17 17:49:55 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-17 17:49:55 -04:00

Owner

Vaultwarden — the vault login (/identity/connect/token) is public. Protections today: Vaultwarden's built-in login ratelimit and Traefik's generic ratelimit@file (100/s, tuned for burst, not credential guessing). This is the highest-value credential target in the stack. The hub has a vaultwarden collection (parser + brute-force scenario); needs EXTENDED_LOGGING/LOG_FILE to a bind-mounted file (same /var/log/<app> pattern as jellyfin) or a docker acquis source.
Navidrome — public native login. A local whitelist parser exists (navidrome-whitelist.yaml, the false-ban fix) but nothing detects failed logins. Check the hub first; failed-login log lines are regular enough for a local parser+scenario if nothing's there.

Related asymmetry on the metrics side: only Authelia's failures alert (AutheliaHighFailedAuthn). Once CrowdSec decisions exist for these sources they surface through cs_active_decisions for free; a Loki-ruler rule (#105) is the alternative if a hub collection turns out not to exist.

The ForwardAuth bypass trades moved the auth boundary into each app, but log-based detection only followed for some of them. CrowdSec's acquis tails traefik/authelia/jellyfin/seerr/calibre-web — the two remaining *public native-auth* surfaces are invisible to it: - **Vaultwarden** — the vault login (`/identity/connect/token`) is public. Protections today: Vaultwarden's built-in login ratelimit and Traefik's generic `ratelimit@file` (100/s, tuned for burst, not credential guessing). This is the highest-value credential target in the stack. The hub has a vaultwarden collection (parser + brute-force scenario); needs `EXTENDED_LOGGING`/`LOG_FILE` to a bind-mounted file (same `/var/log/<app>` pattern as jellyfin) or a docker acquis source. - **Navidrome** — public native login. A local whitelist parser exists (`navidrome-whitelist.yaml`, the false-ban fix) but nothing detects failed logins. Check the hub first; failed-login log lines are regular enough for a local parser+scenario if nothing's there. Related asymmetry on the metrics side: only Authelia's failures alert (`AutheliaHighFailedAuthn`). Once CrowdSec decisions exist for these sources they surface through `cs_active_decisions` for free; a Loki-ruler rule (#105) is the alternative if a hub collection turns out not to exist.

mysticalsoap added the

audit-work

label

2026-08-17 17:49:55 -04:00

mysticalsoap referenced this issue

2026-08-17 17:50:17 -04:00

Stack analysis: feature gaps and divergence from other homelabs #116