Fail2ban for Asterisk

SIP brute-force attacks are constant on any internet-facing PBX. Scanners try thousands of extensions and passwords per hour. Fail2ban watches Asterisk's logs for failed authentication attempts and automatically adds firewall rules to block the source IPs. This guide covers enabling Asterisk's security log, writing the fail2ban filter, configuring the jail, and testing it all.

Step 1: Enable Asterisk Security Logging

Asterisk has a dedicated security logging framework that writes structured events for authentication failures, ACL violations, and invalid requests. This is far more reliable to parse than grepping NOTICE lines from the main log.

Add a security logger in logger.conf:

; /etc/asterisk/logger.conf

[logfiles]
; Main log (already exists)
messages => notice,warning,error
full => notice,warning,error,debug,verbose

; Security log - fail2ban reads this
security => security

Reload the logger:

asterisk -rx 'logger reload'

Verify the security log file is being written:

ls -la /var/log/asterisk/security

The file might be empty until a failed auth attempt occurs. You can confirm it's active:

asterisk -rx 'logger show channels'

You should see a line showing security mapped to the SECURITY level.

Step 2: Fail2ban Filter

Create the filter that extracts attacker IPs from Asterisk's security log entries:

# /etc/fail2ban/filter.d/asterisk.conf

[INCLUDES]
before = common.conf

[Definition]
# Match Asterisk security log events for failed auth and invalid accounts
# Log format: [2026-01-15 10:23:45] SECURITY[1234] res_security_log.c: SecurityEvent="...",...,RemoteAddress="IPV4/UDP/1.2.3.4/5060"

_daemon = asterisk

failregex = SECURITY\[\d+\] res_security_log\.c:.*SecurityEvent="InvalidAccountID".*RemoteAddress="IPV4/\w+/<HOST>/\d+"
            SECURITY\[\d+\] res_security_log\.c:.*SecurityEvent="ChallengeResponseFailed".*RemoteAddress="IPV4/\w+/<HOST>/\d+"
            SECURITY\[\d+\] res_security_log\.c:.*SecurityEvent="InvalidPassword".*RemoteAddress="IPV4/\w+/<HOST>/\d+"
            SECURITY\[\d+\] res_security_log\.c:.*SecurityEvent="FailedACL".*RemoteAddress="IPV4/\w+/<HOST>/\d+"
            SECURITY\[\d+\] res_security_log\.c:.*SecurityEvent="UnexpectedAddress".*RemoteAddress="IPV4/\w+/<HOST>/\d+"

ignoreregex =

Each failregex line matches a different security event type:

Step 3: Jail Configuration

Add the Asterisk jail to your fail2ban config:

# /etc/fail2ban/jail.d/asterisk.conf

[asterisk]
enabled  = true
filter   = asterisk
logpath  = /var/log/asterisk/security
backend  = auto
maxretry = 3
findtime = 600
bantime  = 3600
action   = %(banaction)s[blocktype=DROP]

# Never ban your own networks
ignoreip = 127.0.0.1/8 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12

What each setting does:

• maxretry = 3: ban after 3 failed attempts
• findtime = 600: within a 10-minute window
• bantime = 3600: ban lasts 1 hour (3600 seconds)
• ignoreip: never ban your LAN or localhost (add your SIP trunk provider IPs here too)
• blocktype=DROP: silently drop packets rather than REJECT (don't tell the attacker anything)

Aggressive Mode

For servers under heavy attack, tighten the settings and enable incremental bans:

[asterisk]
enabled  = true
filter   = asterisk
logpath  = /var/log/asterisk/security
backend  = auto
maxretry = 2
findtime = 300
bantime  = 86400
bantime.increment = true
bantime.factor   = 2
bantime.maxtime  = 604800
action   = %(banaction)s[blocktype=DROP]
ignoreip = 127.0.0.1/8 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12

With bantime.increment, repeat offenders get exponentially longer bans: 1 day, 2 days, 4 days, up to bantime.maxtime (7 days).

Step 4: Activate

# Restart fail2ban to pick up the new jail
sudo systemctl restart fail2ban

# Verify the jail is active
sudo fail2ban-client status asterisk

Expected output:

Status for the jail: asterisk
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/asterisk/security
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Testing

Test the Filter Against Your Log

Before relying on the jail, verify the filter actually matches your log format:

sudo fail2ban-regex /var/log/asterisk/security \
    /etc/fail2ban/filter.d/asterisk.conf

This shows how many lines matched each regex and how many IPs were found. If you get zero matches and you know there are failed attempts in the log, your log format may differ, check the actual lines in /var/log/asterisk/security and adjust the regex.

Generate a Test Event

From another machine (not in your ignoreip list), try to register a nonexistent extension:

# From a test machine -- requires sipsak or similar
sipsak -U -s sip:fakeuser@your-pbx-ip

Or simply wait. SIP scanners will find an internet-facing PBX within hours.

Then check:

# See recent security events
tail -20 /var/log/asterisk/security

# See if fail2ban caught it
sudo fail2ban-client status asterisk

Management Commands

# Check jail status and currently banned IPs
sudo fail2ban-client status asterisk

# Manually unban an IP (e.g., you locked yourself out)
sudo fail2ban-client set asterisk unbanip 203.0.113.50

# Manually ban an IP
sudo fail2ban-client set asterisk banip 198.51.100.99

# See all active jails
sudo fail2ban-client status

# Check fail2ban's own log for errors
sudo tail -50 /var/log/fail2ban.log

Firewall Backend

Fail2ban works with both iptables and nftables. Most modern distributions default to nftables. Check which backend you're using:

# See current ban action
sudo fail2ban-client get asterisk action

If you need to explicitly set the backend, add to your jail config:

# For iptables
banaction = iptables-multiport

# For nftables
banaction = nftables-multiport

Adding SIP Trunk Provider IPs to ignoreip

If your SIP trunk provider sends traffic from known IPs, add them to ignoreip so they never get banned, even if there's a brief authentication glitch during a trunk re-registration:

# In /etc/fail2ban/jail.d/asterisk.conf
ignoreip = 127.0.0.1/8 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12
           203.0.113.0/24
           198.51.100.50/32

Log Rotation

Make sure Asterisk's security log rotates so fail2ban doesn't read stale data from an enormous file. If you use logrotate:

# /etc/logrotate.d/asterisk (add security log if not already present)
/var/log/asterisk/security {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        /usr/sbin/asterisk -rx 'logger reload' > /dev/null 2>&1 || true
    endscript
}

Defence in Depth

Fail2ban is one layer. For a well-protected Asterisk server, combine it with:

• PJSIP IP ACLs: block unknown IPs at the Asterisk level before authentication
• Strong endpoint passwords: 20+ character random strings
• TLS + SRTP: encrypt signaling and media
• Non-standard SIP port: move off 5060 to reduce scanner noise (security through obscurity, but it helps)
• Firewall rules: only allow SIP from known ranges at the network level