When operating public-facing SIP servers, one inevitable challenge is dealing with malicious scanners like SipVicious (often identified as 'friendly-scanner' in logs). These tools don't just probe for vulnerabilities - they maintain persistent UDP packet storms even after being blocked.

The standard approach using fail2ban with iptables rules has limitations:

# Typical fail2ban filter for SIP attacks
[Definition]
failregex = ^.*WARNING.*<HOST>.*Failed authentication
ignoreregex =

The key issue is that UDP lacks connection state - unlike TCP where RST packets terminate sessions, UDP scanners ignore ICMP unreachable messages and continue flooding.

1. IPTables Rate Limiting

Implement connection rate limiting before packets hit Asterisk:

iptables -A INPUT -p udp --dport 5060 -m hashlimit \
--hashlimit-above 50/sec --hashlimit-burst 100 \
--hashlimit-mode srcip --hashlimit-name sip_flood \
-j DROP

2. Kernel-Level UDP Packet Handling

Adjust Linux kernel parameters to better handle UDP floods:

sysctl -w net.core.rmem_max=26214400
sysctl -w net.ipv4.udp_mem="262144 262144 262144"
sysctl -w net.ipv4.netfilter.ip_conntrack_udp_timeout=30

3. Advanced Fail2Ban Configuration

Enhance your fail2ban setup with early rejection:

[sip-hardened]
enabled = true
filter = asterisk
action = iptables-allports[name=SIP, protocol=all]
         route-null[name=SIP, interface=eth0]
logpath = /var/log/asterisk/messages
maxretry = 3
findtime = 60
bantime = 86400

For critical deployments, consider these additional measures:

• Implement SIP-specific firewall modules like kamailio's pike
• Use geo-blocking for regions you don't serve
• Deploy SIP honeypots to divert scanners
• Consider commercial DDoS protection services for UDP floods

Set up real-time monitoring to detect attack patterns:

# Sample ELK stack grok pattern for SIP attacks
filter {
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:hostname} %{DATA:process}$$%{NUMBER:pid}$$: %{IP:attacker}.*Failed%{GREEDYDATA:details}" }
  }
}

When running a public-facing SIP server, the friendly-scanner (part of SipVicious suite) becomes particularly problematic. Unlike normal scanners that give up after being blocked, these tools continue flooding UDP port 5060 with REGISTER requests even after receiving ICMP unreachable responses.

While fail2ban helps by blocking IPs after failed attempts, we need deeper protection:

# /etc/fail2ban/jail.local
[sip-register]
enabled = true
filter = asterisk
action = iptables-allports[name=SIP, protocol=all]
logpath = /var/log/asterisk/messages
maxretry = 5
findtime = 60
bantime = 86400

Add these iptables rules before your fail2ban chain:

iptables -A INPUT -p udp --dport 5060 -m hashlimit \
--hashlimit-above 50/sec --hashlimit-burst 100 \
--hashlimit-mode srcip --hashlimit-name sip_flood \
-j DROP

iptables -A INPUT -p udp --dport 5060 -m length \
--length 0:300 -j DROP # Drop malformed SIP packets

In sip.conf:

[general]
tos_sip=cs3
tos_audio=ef
tos_video=af41
cos_sip=3
cos_audio=5
cos_video=4

; Throttle registration attempts
registerattempts=5
registertimeout=20

Consider these architectural changes:

• Deploy SIP traffic through a proxy like Kamailio with built-in anti-flood modules
• Implement port knocking for additional authentication layer
• Use GeoIP blocking for known malicious regions

Python example for detecting scan patterns:

#!/usr/bin/env python3
from collections import defaultdict
import re

sip_log = "/var/log/asterisk/messages"
ip_counter = defaultdict(int)

with open(sip_log) as f:
    for line in f:
        if "REGISTER" in line:
            ip = re.search(r'(\d+\.\d+\.\d+\.\d+)', line).group(1)
            ip_counter[ip] += 1
            if ip_counter[ip] > 10:
                print(f"Flood detected from {ip}")
                # Add custom blocking logic here