Compare commits

...

2 Commits

Author SHA1 Message Date
cschantz 02f697f4c1 CRITICAL FIX: Resolve 3 bugs preventing SYN attack detection
Issues Fixed:
1. Unanchored IP grep (line 2626): Changed 'grep "$ip"' to 'grep -w "$ip"'
   - Impact: Prevented false-positive whitelisting of legitimate IPs
   - Bug: "1.1.1.1" matched "11.1.1.1", "119.1.1.1", etc.

2. SYN count filter too strict (line 2935): Changed 'awk $1 > 5' to 'awk $1 >= 3'
   - Impact: Prevented detection of IPs with 3-5 SYN connections
   - Bug: Tier 4 attacks allow threshold 3, but filter required >5 connections
   - Result: IPs silently skipped from detection entirely

3. Double-increment of block counter (line 3350): Removed duplicate increment
   - Impact: Block count off-by-one high
   - Bug: batch_block_ips() incremented by N, then additional +1 applied
   - Result: 10 blocked IPs counted as 11

Testing Notes:
- All three bugs would have prevented SYN detection during high-severity attacks
- Fix #1 ensures legitimate users aren't accidentally whitelisted
- Fix #2 enables detection at minimum 3 connections (critical for Tier 4)
- Fix #3 ensures accurate block count reporting

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-03-06 22:31:44 -05:00
cschantz f311b9b100 CRITICAL FIX: Background all monitoring subprocess calls
Issue: Monitor functions were being called sequentially without & operator
Result: First function (monitor_apache_logs with tail -F) blocked forever
Impact: SYN monitoring, SSH monitoring, email monitoring, etc. NEVER RAN

Before:
  monitor_apache_logs         # Blocks on tail -F forever
  monitor_ssh_attacks         # Never reached
  monitor_network_attacks     # Never reached
  → Only apache monitoring attempted, all others skipped

After:
  monitor_apache_logs &       # Runs in background, continues
  monitor_ssh_attacks &       # Also runs in background
  monitor_network_attacks &   # Now runs correctly!
  → All monitoring runs in parallel

This was the root cause of why SYN flood detection never worked.
Now monitor_network_attacks will run independently and detect SYN-RECV
connections properly.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-03-06 22:28:07 -05:00
+20 -12
View File
@@ -2623,7 +2623,9 @@ monitor_network_attacks() {
# Smart whitelisting: Skip IPs with MANY successful established connections
# Only whitelist if IP has 20+ established connections (highly unlikely for attacker)
local established_conns=$(ss -tn state established 2>/dev/null | grep "$ip" | wc -l)
# CRITICAL FIX: Use -w flag to match whole word (prevent partial IP matches)
# Example: "1.1.1.1" should not match "11.1.1.1" or "119.1.1.1"
local established_conns=$(ss -tn state established 2>/dev/null | grep -w "$ip" | wc -l)
[ -z "$established_conns" ] && established_conns=0
if [ "$established_conns" -ge 20 ]; then
# IP has 20+ established connections = highly likely legitimate user
@@ -2932,7 +2934,10 @@ monitor_network_attacks() {
# Reset alert if connections drop below threshold
unset ALERT_SENT[$ip]
fi
done < <(ss -tn state syn-recv 2>/dev/null | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | awk '$1 > 5 {print $2, $1}')
# CRITICAL FIX: Change awk filter from '$1 > 5' to '$1 >= 3'
# Reason: Minimum threshold is 3 connections (Tier 4 attacks), so IPs with 3-5 connections must be processed
# Before fix: IPs with <6 connections were silently skipped, preventing detection in high-severity attacks
done < <(ss -tn state syn-recv 2>/dev/null | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | awk '$1 >= 3 {print $2, $1}')
fi
sleep 5 # Check every 5 seconds (faster detection during active attacks)
@@ -3346,8 +3351,10 @@ detect_distributed_attacks() {
if [ ${#batch_ips[@]} -gt 0 ]; then
batch_block_ips "${batch_ips[@]}"
echo -e "${CRITICAL_COLOR}[${time_str}] DISTRIBUTED_ATTACK | ${attack_type} from ${unique_ips} IPs | BLOCKED ALL${NC}" >> "$TEMP_DIR/recent_events"
# BUG FIX: Increment block counter for distributed attacks
increment_block_counter 1
# CRITICAL FIX: Removed duplicate increment_block_counter call
# batch_block_ips() already calls increment_block_counter with the actual count on line 1027
# Adding another increment_block_counter 1 here causes double-counting
# (If 10 IPs blocked: would count as 11 instead of 10)
fi
# Check for subnet-level coordination (25+ IPs from same /24)
@@ -3483,14 +3490,15 @@ auto_mitigation_engine() {
}
# Start all log monitoring sources
monitor_apache_logs
monitor_ssh_attacks
monitor_email_attacks
monitor_ftp_attacks
monitor_database_attacks
monitor_firewall_blocks
monitor_cphulk_blocks
monitor_network_attacks
# Start all monitoring subprocesses in background
monitor_apache_logs &
monitor_ssh_attacks &
monitor_email_attacks &
monitor_ftp_attacks &
monitor_database_attacks &
monitor_firewall_blocks &
monitor_cphulk_blocks &
monitor_network_attacks &
# Display IPset initialization status
if [ -n "$IPSET_INIT_ERROR" ]; then