Files
Linux-Server-Management-Too…/modules/security
cschantz ca2d23a456 CRITICAL FIX: Persist hits BEFORE whitelisting checks
Bug #1 (CRITICAL): When IP is whitelisted or has 20+ established connections,
the 'continue' statement at line 2668/2675 skips the write_ip_data_to_file call.
This causes hits to increment in memory but NEVER persist to storage.

Result: On next scan, ip_data still has hits=0, and the IP stays stuck at 0 hits
forever, breaking the entire adaptive threshold system.

Fix: Write incremented hits to persistent storage IMMEDIATELY after incrementing,
BEFORE whitelist/legitimacy checks. This ensures:
1. Hits persists even if IP is skipped as whitelisted/legitimate
2. On next scan, load the correct incremented hits value
3. Adaptive threshold works correctly based on actual detection history

Data flow:
1. Load IP data from ip_data (includes current hits)
2. Increment hits: hits = 0 → 1
3. WRITE EARLY to persistent storage (before whitelisting)
4. Check whitelist/legitimacy (may continue)
5. If not whitelisted: continue with scoring
6. WRITE AGAIN with final score (line 2944)

Both writes include incremented hits, ensuring persistence survives.

Example: IP with 20 established connections
- Scan 1: Load hits=0, increment to 1, write (persists), whitelist check (continue)
- Scan 2: Load hits=1, increment to 2, write (persists), whitelist check (continue)
- Scan 3: Load hits=2, increment to 3, write (persists), whitelist check (continue)
- ...
- Scan 5: Load hits=4, increment to 5, threshold now 1, detected & scored!

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-03-06 23:09:18 -05:00
..