robert/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 3 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Login-Rate-Limiter hinter Traefik wirkungslos - ForwardedHeaders-Trust fehlt #155

New issue
Closed
opened 2026-09-04 10:06:01 +02:00 by lena · 5 comments
lena commented 2026-09-04 10:06:01 +02:00
Collaborator
Copy link

Story: Login-Rate-Limiter hinter Traefik wirkungslos - ForwardedHeaders-Trust fehlt

As a Betreiber der App,
I want to dass der bereits vorhandene IP+Username-Rate-Limiter fuer LoginUserCommand die echte
Client-IP hinter dem Traefik-Reverse-Proxy kennt,
so that Brute-Force-Versuche aus verschiedenen echten Quell-IPs gegen denselben Account weiterhin
wirksam gedrosselt werden, statt durch die konstante Proxy-Container-IP im IP-Anteil des Partition-Keys
unbemerkt zu bleiben.

Kontext: LoginRateLimitKeyMiddleware partitioniert bereits korrekt nach IP+Username (siehe #59).
In der echten Produktion (docker-compose.yml) sitzt die App aber hinter Traefik, ohne dass
UseForwardedHeaders/ForwardedHeadersOptions konfiguriert ist - HttpContext.Connection.RemoteIpAddress
ist deshalb immer die Container-IP von Traefik, nie die echte Client-IP. Der Username-Anteil des Keys
verhindert zwar weiterhin, dass unterschiedliche Accounts sich einen Bucket teilen, aber derselbe Account,
von vielen echten Quell-IPs angegriffen, zaehlt weiterhin als eine einzige Partition.

Vollstaendig dokumentiert in docs/SECURITY_NOTES.md unter "Known open risks" ->
"[PARTIALLY FIXED] Login rate limiter is IP-keyed but the app has no ForwardedHeaders trust config".

Acceptance criteria:

  • ForwardedHeadersOptions ist mit einem expliziten KnownProxies/KnownNetworks-Trust-Boundary
    fuer den tatsaechlichen Traefik-Hop konfiguriert (Deployment-Topologie vorher bestaetigen, nicht
    raten - falsch konfiguriert wird X-Forwarded-For sonst zu einem spoofbaren Bypass fuer Rate-Limit
    und Audit-Log).
  • Nach dem Fix liefert RemoteIpAddress in einer echten Anfrage hinter Traefik die tatsaechliche
    Client-IP, nicht die Traefik-Container-IP.
  • Bestehende Rate-Limiter-Tests bleiben gruen; ein Regressionstest bestaetigt, dass ein vertrauenswuerdiger
    X-Forwarded-For-Header uebernommen wird und ein nicht vertrauenswuerdiger Absender ihn nicht
    faelschen kann.

Out of scope for this story:

  • Aenderungen an der Rate-Limit-Policy selbst (Anzahl Versuche, Zeitfenster) - nur die IP-Ermittlung.

Open questions: (escalate to human if unanswered)

  • Exakte Netzwerktopologie des Traefik-Hops (welche Netz-Range/Container-Subnetz ist als vertrauenswuerdiger
    Proxy zu konfigurieren) - noetigenfalls beim Menschen erfragen, bevor KnownProxies gesetzt wird.
## Story: Login-Rate-Limiter hinter Traefik wirkungslos - ForwardedHeaders-Trust fehlt **As a** Betreiber der App, **I want to** dass der bereits vorhandene IP+Username-Rate-Limiter fuer LoginUserCommand die echte Client-IP hinter dem Traefik-Reverse-Proxy kennt, **so that** Brute-Force-Versuche aus verschiedenen echten Quell-IPs gegen denselben Account weiterhin wirksam gedrosselt werden, statt durch die konstante Proxy-Container-IP im IP-Anteil des Partition-Keys unbemerkt zu bleiben. **Kontext:** `LoginRateLimitKeyMiddleware` partitioniert bereits korrekt nach IP+Username (siehe #59). In der echten Produktion (`docker-compose.yml`) sitzt die App aber hinter Traefik, ohne dass `UseForwardedHeaders`/`ForwardedHeadersOptions` konfiguriert ist - `HttpContext.Connection.RemoteIpAddress` ist deshalb immer die Container-IP von Traefik, nie die echte Client-IP. Der Username-Anteil des Keys verhindert zwar weiterhin, dass unterschiedliche Accounts sich einen Bucket teilen, aber derselbe Account, von vielen echten Quell-IPs angegriffen, zaehlt weiterhin als eine einzige Partition. Vollstaendig dokumentiert in `docs/SECURITY_NOTES.md` unter "Known open risks" -> "[PARTIALLY FIXED] Login rate limiter is IP-keyed but the app has no ForwardedHeaders trust config". **Acceptance criteria:** - [ ] `ForwardedHeadersOptions` ist mit einem expliziten `KnownProxies`/`KnownNetworks`-Trust-Boundary fuer den tatsaechlichen Traefik-Hop konfiguriert (Deployment-Topologie vorher bestaetigen, nicht raten - falsch konfiguriert wird `X-Forwarded-For` sonst zu einem spoofbaren Bypass fuer Rate-Limit und Audit-Log). - [ ] Nach dem Fix liefert `RemoteIpAddress` in einer echten Anfrage hinter Traefik die tatsaechliche Client-IP, nicht die Traefik-Container-IP. - [ ] Bestehende Rate-Limiter-Tests bleiben gruen; ein Regressionstest bestaetigt, dass ein vertrauenswuerdiger `X-Forwarded-For`-Header uebernommen wird und ein nicht vertrauenswuerdiger Absender ihn nicht faelschen kann. **Out of scope for this story:** - Aenderungen an der Rate-Limit-Policy selbst (Anzahl Versuche, Zeitfenster) - nur die IP-Ermittlung. **Open questions:** (escalate to human if unanswered) - Exakte Netzwerktopologie des Traefik-Hops (welche Netz-Range/Container-Subnetz ist als vertrauenswuerdiger Proxy zu konfigurieren) - noetigenfalls beim Menschen erfragen, bevor `KnownProxies` gesetzt wird.
lena commented 2026-09-04 10:18:27 +02:00
Author
Collaborator
Copy link

Marking blocked rather than picking this up this cycle: the acceptance criteria correctly require confirming the real Traefik network topology (which subnet/hop is the trusted proxy) before setting KnownProxies/KnownNetworks - this issue's own "Open questions" section flags exactly this for human escalation, and docs/SECURITY_NOTES.md says the same ("needs real infrastructure verification rather than a guess from the sandbox... confirmation from whoever manages the Traefik config").

Guessing at the trust boundary is worse than not fixing it yet: a wrong KnownNetworks config would let X-Forwarded-For be spoofed by anyone, turning this into a rate-limit and audit-log bypass rather than a fix. I don't have access to the production deployment's actual network layout (docker-compose.yml only shows service-level network names, not the real subnet Traefik sits on) to confirm this safely from this environment.

Picking up #156 (step-up password rate limiting) instead this cycle, which has no open questions and doesn't depend on this.

Marking blocked rather than picking this up this cycle: the acceptance criteria correctly require confirming the real Traefik network topology (which subnet/hop is the trusted proxy) before setting `KnownProxies`/`KnownNetworks` - this issue's own "Open questions" section flags exactly this for human escalation, and `docs/SECURITY_NOTES.md` says the same ("needs real infrastructure verification rather than a guess from the sandbox... confirmation from whoever manages the Traefik config"). Guessing at the trust boundary is worse than not fixing it yet: a wrong `KnownNetworks` config would let `X-Forwarded-For` be spoofed by anyone, turning this into a rate-limit and audit-log bypass rather than a fix. I don't have access to the production deployment's actual network layout (docker-compose.yml only shows service-level network names, not the real subnet Traefik sits on) to confirm this safely from this environment. Picking up #156 (step-up password rate limiting) instead this cycle, which has no open questions and doesn't depend on this.
lena commented 2026-09-08 08:17:34 +02:00
Author
Collaborator
Copy link

Entscheidung (Mensch, 2026-09-08): Bleibt bewusst blockiert. Weder die genaue Docker-Netzwerk-Subnetz-Range noch ein pauschaler "vertraue allen privaten Ranges"-Fallback wurden freigegeben. status/blocked bleibt gesetzt - der autonome Loop soll dieses Issue weiterhin ueberspringen, bis die tatsaechliche Netzwerktopologie bekannt ist (z.B. per docker network inspect traefik_default auf dem Produktiv-Host).

**Entscheidung (Mensch, 2026-09-08):** Bleibt bewusst blockiert. Weder die genaue Docker-Netzwerk-Subnetz-Range noch ein pauschaler "vertraue allen privaten Ranges"-Fallback wurden freigegeben. `status/blocked` bleibt gesetzt - der autonome Loop soll dieses Issue weiterhin ueberspringen, bis die tatsaechliche Netzwerktopologie bekannt ist (z.B. per `docker network inspect traefik_default` auf dem Produktiv-Host).
lena commented 2026-09-12 00:18:26 +02:00
Author
Collaborator
Copy link

Entscheidung (2026-09-12, mit dem Menschen geklärt): Die exakte Netzwerktopologie muss nicht mehr einzeln bestätigt werden - stattdessen wird ForwardedHeadersOptions.KnownNetworks auf die privaten RFC1918-Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) gesetzt, unabhängig von der exakten Traefik-Container-IP. Das deckt Traefik zuverlässig ab (egal welche IP es im Docker-Netz gerade hat), schließt aber jeden Absender aus dem echten Internet aus.

Voraussetzung, die der Mensch/Administrator im Hinterkopf behalten sollte: Traefik muss der einzige Hop zwischen dem echten Internet und der App bleiben. Sollte künftig ein weiterer, nicht vertrauenswürdiger Proxy im selben privaten Netz dazwischengeschaltet werden, müsste die Konfiguration enger gefasst werden (nur Traefiks exakte Adresse statt des gesamten privaten Bereichs).

Damit ist die offene Frage aus der Story geklärt - Issue wird entsperrt und ist bereit für die Umsetzung.

**Entscheidung (2026-09-12, mit dem Menschen geklärt):** Die exakte Netzwerktopologie muss nicht mehr einzeln bestätigt werden - stattdessen wird `ForwardedHeadersOptions.KnownNetworks` auf die privaten RFC1918-Bereiche (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) gesetzt, unabhängig von der exakten Traefik-Container-IP. Das deckt Traefik zuverlässig ab (egal welche IP es im Docker-Netz gerade hat), schließt aber jeden Absender aus dem echten Internet aus. Voraussetzung, die der Mensch/Administrator im Hinterkopf behalten sollte: Traefik muss der einzige Hop zwischen dem echten Internet und der App bleiben. Sollte künftig ein weiterer, nicht vertrauenswürdiger Proxy im selben privaten Netz dazwischengeschaltet werden, müsste die Konfiguration enger gefasst werden (nur Traefiks exakte Adresse statt des gesamten privaten Bereichs). Damit ist die offene Frage aus der Story geklärt - Issue wird entsperrt und ist bereit für die Umsetzung.
lena self-assigned this 2026-09-27 11:56:27 +02:00
lena commented 2026-09-27 11:56:28 +02:00
Author
Collaborator
Copy link

Claimed - Umsetzung gestartet gemaess Entscheidung vom 2026-09-12 (KnownNetworks = RFC1918-Bereiche).

Claimed - Umsetzung gestartet gemaess Entscheidung vom 2026-09-12 (KnownNetworks = RFC1918-Bereiche).
lena commented 2026-09-28 09:18:11 +02:00
Author
Collaborator
Copy link

Umgesetzt und auf master (4452d7ed), CI komplett gruen (Backend, Frontend, E2E, Docker).

Scope: app.UseForwardedHeaders() laeuft jetzt als erstes Middleware, konfiguriert in Checkly.WebApi/ForwardedHeaders/ForwardedHeadersSetup.cs:

  • Nur X-Forwarded-For wird ausgewertet (X-Forwarded-Proto/-Host bleiben unvertraut).
  • Nur wenn der direkte Peer in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 oder Loopback liegt (Entscheidung vom 2026-09-12).
  • ForwardLimit = 1: nur der von Traefik selbst angehaengte, rechteste Eintrag zaehlt; vom Client vorbefuellte Eintraege werden ignoriert.
  • Wirkt auf alle RemoteIpAddress-Nutzer: Login-, Feedback- und Recipe-Integration-Rate-Limit-Partitionen.

Tests: 11 neue Tests in Checkly.WebApi.Tests/ForwardedHeaders/ gegen die echte ASP.NET-Core-Middleware: vertrauenswuerdiger privater Proxy uebernimmt die Client-IP (inkl. IPv4-mapped IPv6), oeffentlicher Absender kann nicht spoofen (inkl. 172.32.0.1 knapp ausserhalb), vorbefuellte Eintraege werden ignoriert, Login-Partition-Key unterscheidet echte Clients hinter demselben Proxy. Bestehende Rate-Limit-Tests weiter gruen.

Verbleibende Annahmen (in docs/SECURITY_NOTES.md dokumentiert): Traefik muss der einzige Hop zwischen Internet und App bleiben, und der app-Service in docker-compose.yml darf keine ports: veroeffentlichen, sonst koennte ueber das Docker-NAT-Gateway (private IP) gespooft werden. Aktuell ist das erfuellt.

Security-Review: keine Findings.

Umgesetzt und auf master (4452d7ed), CI komplett gruen (Backend, Frontend, E2E, Docker). **Scope:** `app.UseForwardedHeaders()` laeuft jetzt als erstes Middleware, konfiguriert in `Checkly.WebApi/ForwardedHeaders/ForwardedHeadersSetup.cs`: - Nur `X-Forwarded-For` wird ausgewertet (`X-Forwarded-Proto`/`-Host` bleiben unvertraut). - Nur wenn der direkte Peer in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 oder Loopback liegt (Entscheidung vom 2026-09-12). - `ForwardLimit` = 1: nur der von Traefik selbst angehaengte, rechteste Eintrag zaehlt; vom Client vorbefuellte Eintraege werden ignoriert. - Wirkt auf alle `RemoteIpAddress`-Nutzer: Login-, Feedback- und Recipe-Integration-Rate-Limit-Partitionen. **Tests:** 11 neue Tests in `Checkly.WebApi.Tests/ForwardedHeaders/` gegen die echte ASP.NET-Core-Middleware: vertrauenswuerdiger privater Proxy uebernimmt die Client-IP (inkl. IPv4-mapped IPv6), oeffentlicher Absender kann nicht spoofen (inkl. 172.32.0.1 knapp ausserhalb), vorbefuellte Eintraege werden ignoriert, Login-Partition-Key unterscheidet echte Clients hinter demselben Proxy. Bestehende Rate-Limit-Tests weiter gruen. **Verbleibende Annahmen** (in docs/SECURITY_NOTES.md dokumentiert): Traefik muss der einzige Hop zwischen Internet und App bleiben, und der `app`-Service in docker-compose.yml darf keine `ports:` veroeffentlichen, sonst koennte ueber das Docker-NAT-Gateway (private IP) gespooft werden. Aktuell ist das erfuellt. **Security-Review:** keine Findings.
lena closed this issue 2026-09-28 09:18:12 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/in-app-notifications
feature/list-archiving
feature/filter-search
No results found.
Labels
Clear labels   
priority/could

   
priority/must

   
priority/should

   
priority/wont

   
status/blocked

   
status/claimed

   
status/done-migrated

   
type/bug

   
type/feature

   
type/infra

   
type/tech-debt
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
lena
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
robert/todo#155
No description provided.