# Implementing tarpit and dynamic blocking in HAProxy 2.6.12 HAProxy 2.6.12 provides robust mechanisms for implementing tarpit delays and dynamic IP blocking through stick-tables, ACLs, and sophisticated rate limiting rules. The combination of these features creates a powerful defense system that can automatically detect and mitigate various attack patterns while maintaining minimal performance overhead of approximately 2-3% CPU usage. This configuration approach enables graduated responses from warnings to complete blocks, with memory requirements of roughly 150MB for comprehensive security coverage of 100,000 tracked IPs. ## Stick-table configuration fundamentals HAProxy 2.6.12's stick-table system forms the backbone of dynamic blocking mechanisms. The basic syntax follows a straightforward pattern where tables store various counters and metrics about client behavior. Each table entry consumes approximately **64 bytes of base memory plus 8 bytes per stored counter**, making it efficient even at scale. ```haproxy # Core stick-table declaration with multiple data types backend st_security stick-table type ip size 100k expire 300s store \ http_req_rate(10s),conn_rate(10s),http_err_rate(60s),gpc0,gpc1 ``` The available data types in HAProxy 2.6.12 include `http_req_rate(period)` for tracking HTTP request rates, `conn_rate(period)` for connection rates, `bytes_in_rate(period)` for bandwidth monitoring, and general purpose counters `gpc0` and `gpc1` for custom tracking logic. The `gpc0_rate(period)` and `gpc1_rate(period)` counters enable rate calculations on custom events, particularly useful for tracking violation frequencies. For production environments handling millions of requests, the configuration should balance memory usage with tracking requirements. A typical setup tracking 100,000 unique IPs with four counters requires approximately **96MB of memory**. The expire parameter automatically removes inactive entries, preventing memory exhaustion while maintaining relevant security data. ## Rate limiting with automatic escalation Dynamic rate limiting in HAProxy 2.6.12 leverages stick-tables to track request patterns and automatically escalate responses based on violation severity. The system implements progressive penalties that adapt to attack intensity while minimizing false positives for legitimate traffic spikes. ```haproxy frontend web_protection bind *:80 # Multi-level tracking table stick-table type ip size 100k expire 300s store \ http_req_rate(10s),conn_rate(10s),gpc0,gpc0_rate(60s) # Track all incoming requests http-request track-sc0 src # Define violation thresholds acl rate_warning sc_http_req_rate(0) gt 20 acl rate_violation sc_http_req_rate(0) gt 50 acl rate_severe sc_http_req_rate(0) gt 100 acl repeat_offender sc_gpc0_rate(0) gt 3 # Increment violation counter for rate abuse http-request sc-inc-gpc0(0) if rate_violation # Progressive response system http-request set-header X-Rate-Warning "approaching limit" if rate_warning http-request tarpit if rate_violation http-request deny deny_status 429 if rate_severe or repeat_offender # Set appropriate timeouts timeout tarpit 10s default_backend servers ``` This configuration creates a **three-stage response system** where initial violations receive warnings, moderate violations trigger tarpit delays, and severe or repeated violations result in immediate denial. The `gpc0_rate` counter tracks violation frequency over 60 seconds, identifying persistent attackers who repeatedly test rate limits. ## Tarpit configuration for attack mitigation Tarpit mechanisms in HAProxy 2.6.12 introduce deliberate delays before returning error responses, effectively slowing down automated attacks while consuming minimal server resources. The optimal timeout values vary by attack type: **5-10 seconds for rate limiting violations, 10-30 seconds for vulnerability scanning, and 30-60 seconds for persistent bot attacks**. ```haproxy frontend security_frontend bind *:80 timeout tarpit 15s # Vulnerability scan detection patterns acl vuln_paths path_beg /.env /.git /admin /wp-admin /phpMyAdmin acl sql_injection path_reg -i "(select|union|insert|delete|drop)" acl directory_traversal path_reg -i "(\.\.\/|%2e%2e)" # Bot and scanner detection acl scanner_agents hdr_reg(user-agent) -i \ "(sqlmap|nikto|nmap|masscan|burp|zap)" acl missing_headers hdr_cnt(accept) eq 0 hdr_cnt(accept-language) eq 0 acl old_protocol req.proto_http -m str "HTTP/1.0" # Apply graduated tarpit delays http-request tarpit deny_status 403 \ hdr X-Block-Reason "vulnerability-scan" if vuln_paths http-request tarpit deny_status 403 \ hdr X-Block-Reason "injection-attempt" if sql_injection http-request tarpit deny_status 500 \ hdr X-Block-Reason "bot-detected" if scanner_agents or missing_headers default_backend servers ``` The configuration differentiates between `http-request deny` for immediate rejection and `http-request tarpit` for delayed responses. While deny actions release connection slots immediately with minimal resource usage, tarpit actions **hold connections open for the specified timeout period**, consuming connection slots but effectively frustrating automated attack tools. ## Pattern matching and request analysis HAProxy 2.6.12's ACL system enables sophisticated pattern matching across URLs, headers, and request methods. The system can detect complex attack patterns through regular expressions while maintaining high performance through optimized matching algorithms. ```haproxy frontend pattern_detection bind *:80 # URL-based pattern matching acl malicious_path path_reg -i -f /etc/haproxy/vuln_patterns.txt acl api_abuse path_beg /api/ method POST sc_http_req_rate(0) gt 10 # Header-based analysis acl suspicious_referrer hdr_reg(referer) -i "(poker|casino|pharmacy)" acl header_injection hdr_reg(x-forwarded-for) -i "