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>
Implement progressive tarpit delays and threat detection to slow down
attackers scanning for exploits. Features include:
- Stick table to track attacks with 2-hour expiry
- Escalating tarpit delays based on threat level and repeat offenses
- Threat level detection (low/medium/high/critical) based on scan attempts
- Rate-based attack detection for burst/sustained/persistent attacks
- Automatic scan attempt tracking via HTTP error responses (400/401/403/404)
- Detection of suspicious paths (admin panels, config files, etc.)
- Trusted network bypass for local/monitoring systems
- Progressive escalation levels that increase tarpit duration
- Critical threat blocking with 429 status
The system uses HAProxy's built-in tarpit mechanism to delay responses
up to 60 seconds for persistent attackers, effectively slowing down
vulnerability scanners while maintaining service for legitimate users.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>