From 3b17a601000630bc4778870a536c53768e624ac6 Mon Sep 17 00:00:00 2001 From: cschantz Date: Fri, 6 Mar 2026 23:50:17 -0500 Subject: [PATCH] BUG FIX #11: Escalation detection broken due to array update before comparison MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- modules/security/live-attack-monitor-v2.sh | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/modules/security/live-attack-monitor-v2.sh b/modules/security/live-attack-monitor-v2.sh index 85b7bf4..de3ec5b 100755 --- a/modules/security/live-attack-monitor-v2.sh +++ b/modules/security/live-attack-monitor-v2.sh @@ -2585,8 +2585,12 @@ monitor_network_attacks() { continue fi - # Track connection count for this IP - CONNECTION_COUNT[$ip]=$count + # CRITICAL FIX: Don't update CONNECTION_COUNT here yet + # Bug: Previously updated array BEFORE using it for escalation detection + # Result: prev_count would equal current count (both just set), escalation detection always false + # Fix: Read previous value first (line 2876), then update after scoring (line 2886+) + # Save old value before updating - needed for escalation detection + local prev_count="${CONNECTION_COUNT[$ip]:-0}" # Load IP's persistent data FIRST (before threshold calculation) # This gets the current lifetime hits count from ip_data @@ -2875,7 +2879,7 @@ monitor_network_attacks() { # Connection escalation detection # Check if connection count is increasing (more aggressive attack) - local prev_count="${CONNECTION_COUNT[$ip]:-0}" + # prev_count was loaded at line 2590 (BEFORE updating CONNECTION_COUNT) if [ "$count" -gt "$prev_count" ] && [ "$prev_count" -gt 0 ]; then local increase=$((count - prev_count)) if [ "$increase" -ge 50 ]; then @@ -2885,6 +2889,10 @@ monitor_network_attacks() { fi fi + # NOW update CONNECTION_COUNT after escalation detection + # Store current count for next monitoring cycle comparison + CONNECTION_COUNT[$ip]=$count + # Add HTTP attack pre-boost conn_bonus=$((conn_bonus + http_attack_bonus))