Summary
Implement DDoS mitigation at the HAProxy layer via configurable rate limiting, connection throttling, and automatic IP banning.
Motivation
Volumetric and low-rate application-layer attacks are the most common threat faced by publicly exposed services. Enforcing limits at the HAProxy ingress layer is cheaper than letting traffic reach upstream applications and is a natural fit for a guard-proxy product.
Proposed scope
Rate limiting (request rate)
- Per-source-IP request-rate limit using HAProxy
stick-table with http_req_rate counter.
- Configurable window (e.g. 10 s) and threshold (e.g. 100 req / window).
- Requests exceeding the threshold receive
429 Too Many Requests.
Connection throttling
- Per-source-IP concurrent connection limit (
conn_cur).
- Global connection queue limit to protect against connection exhaustion.
Automatic IP banning
- After N consecutive limit violations within a configurable period, the source IP is added to a ban table.
- Ban duration is configurable (default: 5 minutes).
- Admin can view and manually release banned IPs via the API/UI.
Slow-loris / incomplete-request protection
- Set
timeout http-request and timeout client conservatively.
- Optionally enforce minimum request rate (
http_req_rate over very short window).
Admin UI & API
- Per-rule DDoS settings: enable/disable, rate limit threshold, connection limit, ban threshold, ban duration.
- Dashboard widget showing currently banned IPs and real-time request rates (future: integrate with metrics endpoint).
Alerting hook (stretch goal)
- Emit a webhook or log event when an IP is auto-banned, so external SIEM/alerting systems can react.
Out of scope
- Deep packet inspection
- Anycast / BGP blackholing
- Full WAF rule sets (tracked separately under
area/waf)
Acceptance criteria
Summary
Implement DDoS mitigation at the HAProxy layer via configurable rate limiting, connection throttling, and automatic IP banning.
Motivation
Volumetric and low-rate application-layer attacks are the most common threat faced by publicly exposed services. Enforcing limits at the HAProxy ingress layer is cheaper than letting traffic reach upstream applications and is a natural fit for a guard-proxy product.
Proposed scope
Rate limiting (request rate)
stick-tablewithhttp_req_ratecounter.429 Too Many Requests.Connection throttling
conn_cur).Automatic IP banning
Slow-loris / incomplete-request protection
timeout http-requestandtimeout clientconservatively.http_req_rateover very short window).Admin UI & API
Alerting hook (stretch goal)
Out of scope
area/waf)Acceptance criteria
stick-tableand ACL blockshaproxy -cpasses on generated config