Learn HAProxy - Rate Limiting & Protection

#Introduction

No application is immune to excessive traffic. Whether it's bot attacks, login brute force, or unexpected spikes, HAProxy must act as a firm traffic regulator.

Episode 10 builds layered protection: connection limits at the frontend level, IP-based rate limiting with stick tables, brute force mitigation on login endpoints, and rejection of requests that meet dangerous conditions. All of it happens at the edge, before a request ever touches a backend.

#Basic Rate Limiting with Stick Tables

#Limiting the Request Rate per IP

The most common pattern: count how many requests each IP sends within a time window, then reject anything above the threshold:

frontend web_front
    bind *:80
    mode http
 
    stick-table type ip size 100k expire 30s \
        store http_req_rate(10s)
    http-request track-sc0 src
 
    acl too_many_req sc0_http_req_rate gt 20
    http-request deny deny_status 429 if too_many_req
 
    default_backend web_back

The http-request track-sc0 src directive connects the client IP to the stick table. The ACL sc0_http_req_rate gt 20 is true when a client sends more than 20 requests in 10 seconds, and http-request deny deny_status 429 if too_many_req then returns status 429 Too Many Requests.

#Connection and Request Limits

#Limiting Connections at the Frontend

Besides per-request rates, also limit the number of active connections so servers don't get flooded:

frontend web_front
    bind *:80
    mode http
    maxconn 3000
    timeout queue 10s
    default_backend web_back
 
backend web_back
    maxconn 2500
    server web1 127.0.0.1:8080 maxconn 1200
    server web2 127.0.0.1:8081 maxconn 1200

The maxconn 3000 directive at the frontend limits concurrent connections, and maxconn 1200 per server prevents any single server from being overloaded. timeout queue holds requests in a queue temporarily when all servers are full.

#Per-Connection Limits

Per-connection limits can also be IP-based using a stick table:

backend conn_limiter
    stick-table type ip size 100k expire 30s \
        store conn_cur
    server limiter 127.0.0.1:1 check
 
frontend web_front
    bind *:80
    mode http
    http-request track-sc0 src table conn_limiter
    http-request deny deny_status 429 \
        if { sc0_conn_cur(conn_limiter) ge 10 }
    default_backend web_back

The conn_cur counter records active connections per IP. sc0_conn_cur(conn_limiter) ge 10 rejects clients opening 10 or more simultaneous connections — a defense against connection-squandering attacks.

#Brute Force Login Mitigation

#Limiting Failed Login Attempts

Login endpoints are the most popular brute force target. Limit attempts per IP within a time window:

frontend web_front
    bind *:80
    mode http
 
    acl is_login path_beg /login
    acl login_failed status 401
 
    stick-table type ip size 100k expire 10m \
        store gpc0_rate(10m)
    http-request track-sc0 src if is_login
 
    http-request deny deny_status 429 if is_login \
        { sc0_gpc0_rate gt 5 }
    http-response sc-inc-gpc0(0) if is_login login_failed
 
    default_backend web_back

The line http-response sc-inc-gpc0(0) if is_login login_failed increments the counter when a login attempt fails (status 401), and sc0_gpc0_rate gt 5 rejects the next login request once there have been 5 failures within 10 minutes.

#Adding Response Delaying

A complementary technique: extend the response timeout for suspicious IPs so brute force slows down:

frontend web_front
    bind *:80
    mode http
 
    acl suspicious sc0_gpc0 gt 2
    timeout client 5s if suspicious
    default_backend web_back

timeout client 5s if suspicious extends the client timeout for IPs with a suspicious history. Combining deny and delay makes brute force expensive for attackers.

#Request Blocking and Deny Conditions

#Rejecting Dangerous Requests

Besides excess traffic, some requests must be rejected because of their patterns:

frontend web_front
    bind *:80
    mode http
 
    acl path_attack path_reg -i /(wp-admin|\.\.\/|\.git)
    acl bad_method method TRACE CONNECT
    acl bad_agent hdr(user-agent) -i sqlmap nikto
 
    http-request deny deny_status 403 if path_attack
    http-request deny deny_status 403 if bad_method
    http-request deny deny_status 403 if bad_agent
 
    default_backend web_back

acl path_attack path_reg -i /(wp-admin|\.\.\/|\.git) matches suspicious path patterns, acl bad_method method TRACE CONNECT blocks dangerous methods, and acl bad_agent hdr(user-agent) -i sqlmap nikto rejects attack tool agents. All three return 403 Forbidden.

#Combining Conditions with Logical Operators

Conditions can be chained with or and and:

frontend web_front
    bind *:80
    mode http
 
    acl no_host hdr_count(host) eq 0
    acl is_attack hdr(user-agent) -i sqlmap
 
    http-request deny deny_status 400 if no_host
    http-request deny deny_status 403 if is_attack or path_attack
    default_backend web_back

if no_host rejects requests without a Host header (a pattern of automated probes), and if is_attack or path_attack combines two conditions into a single decision.

#Closing

Episode 10 gives HAProxy defensive muscle: connection limits, per-IP rate limiting, brute force mitigation, and rejection of dangerous requests. All of it happens at the edge, so backends only see traffic that has already been filtered.

Key takeaways:

• Stick tables are the heart of IP-based rate limiting.
• http_req_rate limits requests; conn_cur limits active connections.
• gpc0_rate and sc-inc-gpc0 mitigate login brute force.
• deny_status 429 fits rate limiting; 403 fits forbidden requests.
• Chain ACLs with or and and for precise rules.

In the next episode we'll cover HAProxy as an API gateway — reverse proxying for REST and gRPC, path rewriting, virtual hosts, authentication integration with JWT, and microservices and service discovery patterns.