Allow users to experiment with different DDoS mitigation strategies by
choosing between three challenge types:
1. Button Challenge (default): Simple click-to-verify, best UX
2. Question Challenge: Multiple-choice questions, better bot filtering
3. Proof-of-Work Challenge: SHA-256 computation, strongest protection
Features:
- Three distinct challenge page generators with unique HTML/CSS/JS
- Question pool with 7 simple multiple-choice questions
- JavaScript-based PoW using Web Crypto API (SHA-256)
- Configurable PoW difficulty (3-6 leading zeros)
- Verification logic for each challenge type
- Automatic challenge cleanup after verification
- 10 new comprehensive tests covering all challenge types
Configuration:
- challenge_type: 'button' (default), 'question', or 'pow'
- pow_difficulty: 3=fast, 4=moderate (default), 5=slow, 6=very slow
The PoW challenge creates real computational cost for attackers. With
difficulty 4, each request requires ~65,000 hash computations (~1-3s).
This makes volumetric attacks expensive while remaining transparent to
legitimate users.
Files modified:
- scripts/ddos_protection_challenge.lua: +346 lines (challenge generators, verification)
- tests/ddos_protection_challenge.lua: +198 lines (10 new tests)
- scripts/ddos_protection_challenge.README.md: +93 lines (detailed docs)
- conf.example.ddos_protection.lua: Updated with challenge_type option
- conf.example.ddos_protection_challenge_types.lua: New file with 4 config examples
Allow users to specify which paths should be protected by the challenge
system, enabling selective protection of expensive endpoints while
leaving static assets and other paths unrestricted.
Changes:
- Add protected_paths config option (list of PCRE regex patterns)
- Only apply challenge/ban logic to paths matching protected patterns
- If protected_paths is empty/unset, protect all paths (default behavior)
- Special endpoints (verify/trap) always function regardless of config
- Add 8 new tests for path-based filtering scenarios
- Update documentation with examples and best practices
- Update example config to show protected_paths usage
This allows more granular control - for example, protecting only /api/*
and /search while allowing free access to static assets, reducing UX
friction while still protecting expensive operations.
Implements a Cloudflare-style "Under Attack" mode that protects against
DDoS attacks, scraping, and automated bots.
Features:
- Challenge-response system requiring human interaction
- Honeypot link that automatically bans IPs of bots that click it
- Cookie-based token system for validated users (24h default)
- Temporary IP banning (1h default)
- Comprehensive test suite
The module intercepts requests before they hit the backend, reducing
computational cost from scraping and DDoS attempts. It's particularly
effective against simple scrapers and volumetric attacks.
Files added:
- scripts/ddos_protection_challenge.lua - Main module implementation
- tests/ddos_protection_challenge.lua - Comprehensive test suite
- scripts/ddos_protection_challenge.README.md - Full documentation
- conf.example.ddos_protection.lua - Example configuration
- test.lua - Added test import
