Rate limiting, tuning
Adjust Caddy rate_limit thresholds and the SDK brute-force window
Olympus has two independent rate limiting layers, each tunable:
- Caddy
rate_limit, per-IP throttle at the proxy. - SDK brute-force lockout, per-identifier (account-level) lockout after repeated failures.
Both defaults are sensible. Operators tune when:
- Legitimate users get rate-limited (too tight).
- Attacker traffic gets through (too loose).
Caddy rate_limit
Configured in platform/prod/Caddyfile:
rate_limit {
zone login_per_ip {
key {client_ip}
events 10
window 5m
}
}
@login {
path /self-service/login/*
}
rate_limit login_per_ip @loginDefaults in Olympus:
- Login endpoints: 10 attempts per 5 minutes per IP.
- Registration: 3 per minute per IP.
- Recovery: 3 per minute per IP.
Tuning:
- Increase for shared IPs (offices behind NAT, VPN gateways). Bump login_per_ip to 30/5m or 50/10m.
- Decrease to harden against credential-stuffing. 5/5m for highly sensitive deployments.
After editing the Caddyfile, reload:
ssh prod 'podman exec olympus-caddy caddy reload --config /etc/caddy/Caddyfile'No restart needed.
SDK brute-force
Configured per-deployment via settings (olympus.brute_force.window_minutes, olympus.brute_force.max_attempts, olympus.brute_force.lockout_minutes). Read at flow time.
Defaults:
- Window: 15 minutes.
- Max attempts: 5.
- Lockout: 30 minutes (escalating with repeated lockouts).
Tuning via Athena → Settings:
olympus.brute_force.max_attempts: 3, strict.olympus.brute_force.max_attempts: 10, relaxed.olympus.brute_force.lockout_minutes: 1440, 24-hour lockout after threshold.
Reload not required, settings are read live.
When to tune what
| Problem | Layer | Action |
|---|---|---|
| Legit users from an office VPN get blocked | Caddy | Raise login_per_ip events |
| Attackers slipping through | SDK | Lower max_attempts |
| Lockouts last too long, support tickets spike | SDK | Lower lockout_minutes |
| Mass credential-stuffing botnet | Caddy | Add IP allowlist or Cloudflare Turnstile |
| Single attacker on one user account | SDK | Already covered, they'll hit lockout |
Observability
The SDK emits lockout.applied and lockout.released audit events. Watch the rate via Athena → Security → Audit Log:
SELECT DATE(created_at), COUNT(*)
FROM security_audit
WHERE event_type = 'lockout.applied'
GROUP BY 1
ORDER BY 1 DESC LIMIT 7;A sharp uptick is the signal you're under attack. Tighten further or trigger Captcha if not already on.