Fix tarpit to only apply AFTER backend error responses

Corrected the tarpit logic flow to work as intended:

1. Backend tracks 400/401/403/404 error responses via http-response
2. Counter increments AFTER the backend responds with an error
3. Frontend checks counter on SUBSEQUENT requests
4. Tarpit/blocking only applies after error thresholds are reached:
   - 5+ errors: Potential scanner (no action yet)
   - 15+ errors: Likely scanner (tarpit if also burst traffic)
   - 30+ errors: Confirmed scanner (always tarpit)
   - 50+ errors: Aggressive scanner (block with 429)

This ensures:
- Normal traffic is never delayed
- First requests always go through normally
- Only clients that accumulate errors get progressively slowed/blocked
- The tarpit is a response to bad behavior, not a preemptive measure

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

templates/hap_backend.tpl

@@ -17,6 +17,8 @@ backend {{ name }}-backend
     acl suspicious_path path_reg -i \.(env|git|svn|backup|bak|old)
     
     # Track scan attempts in the frontend stick table
+    # This increments the counter AFTER the backend responds with an error
+    # The frontend will check this counter on SUBSEQUENT requests
     http-response sc-inc-gpc0(0) if is_scan_attempt
     
     {% for server in servers %}

templates/hap_listener.tpl

@@ -25,25 +25,23 @@ frontend web
     http-request set-path /blocked-ip if { src -f /etc/haproxy/blocked_ips.map }
     use_backend default-backend if { src -f /etc/haproxy/blocked_ips.map }
     
-    # Define threat levels based on scan attempts and rates
-    acl has_scan_attempts sc0_get_gpc0 gt 0
-    acl low_threat sc0_get_gpc0 ge 3 sc0_get_gpc0 lt 10
-    acl medium_threat sc0_get_gpc0 ge 10 sc0_get_gpc0 lt 25  
-    acl high_threat sc0_get_gpc0 ge 25 sc0_get_gpc0 lt 50
-    acl critical_threat sc0_get_gpc0 ge 50
+    # Define threat levels based on accumulated error responses from backends
+    # These will be checked on subsequent requests after errors are tracked
+    acl scanner_low sc0_get_gpc0 ge 5          # 5+ errors = potential scanner
+    acl scanner_medium sc0_get_gpc0 ge 15      # 15+ errors = likely scanner
+    acl scanner_high sc0_get_gpc0 ge 30        # 30+ errors = confirmed scanner
+    acl scanner_critical sc0_get_gpc0 ge 50    # 50+ errors = aggressive scanner
     
-    # Rate-based detection (burst attacks)
-    acl burst_attack sc0_http_err_rate gt 5     # >5 errors in 10 seconds
+    # Rate-based detection (burst of errors)
+    acl burst_scanner sc0_http_err_rate gt 5   # >5 errors in 10 seconds
     
-    # Combined threat detection
-    acl is_threat has_scan_attempts
-    acl needs_tarpit low_threat or medium_threat or high_threat or burst_attack
+    # BLOCKING RULES - Block aggressive scanners completely
+    # Only block after significant error accumulation
+    http-request deny deny_status 429 if scanner_critical
     
-    # TARPIT RULES - Only apply to actual threats
-    # Apply tarpit only if there are scan attempts
-    http-request tarpit if needs_tarpit
+    # TARPIT RULES - Slow down detected scanners
+    # Apply progressive delays based on error count
+    http-request tarpit if scanner_high
+    http-request tarpit if scanner_medium burst_scanner
     
-    # Complete block for critical threats
-    http-request deny deny_status 429 if critical_threat
-    
-    # Increment scan counter when tarpit is applied (this happens after response in backend)
+    # Note: The backend will increment sc0_get_gpc0 when it sees 400/401/403/404 responses