ISSUE:
The escalation detection logic (detecting when an attack is becoming more aggressive)
completely failed because CONNECTION_COUNT was being updated BEFORE the escalation
check used its previous value.
TIMELINE OF BUG:
1. Line 2589 (OLD): CONNECTION_COUNT[$ip]=$count (sets array to current count)
2. Line 2878 (OLD): prev_count = CONNECTION_COUNT[$ip] (reads JUST-SET value)
3. Line 2879: if [ "$count" -gt "$prev_count" ] (always FALSE - they're equal!)
IMPACT:
- Escalation detection completely non-functional
- IPs with rapidly increasing attack counts don't get +25 bonus
- IPs with gradually escalating attacks don't get +15 bonus
- Missing critical threat signal: growing attacks should get higher priority
EXAMPLE FAILURE:
- Cycle 1: IP with 10 SYN connections → stored in CONNECTION_COUNT
- Cycle 2: Same IP with 100 SYN connections (10x increase!)
- OLD CODE: Set CONNECTION_COUNT[IP]=100, then read prev_count=100
- Condition: 100 > 100? FALSE → no escalation bonus
- ACTUAL: This was 10x escalation and should get +25 bonus!
ROOT CAUSE:
Array elements should be read BEFORE being updated. The code was:
1. Update array at line 2589
2. Use old value at line 2878 (but it's already new!)
FIX:
1. Read previous value BEFORE updating (line 2590, saved as local var)
2. Use saved prev_count in escalation detection (line 2884)
3. Update CONNECTION_COUNT AFTER escalation detection (line 2891)
This ensures:
- Previous count is captured before any modification
- Escalation detection uses correct historical data
- Array is updated for next monitoring cycle
VERIFICATION:
- Syntax: ✓ Pass
- Logic: ✓ prev_count now contains previous cycle's value
- Flow: ✓ Array updated only after it's been used for comparison
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
cschantz
3b17a60100