fail2ban for Asterisk on Debian with systemd (No rsyslog)

The Problem

fail2ban defaults to watching log files. On Debian 12+ systems using journald without rsyslog, the auth log (/var/log/auth.log) does not exist, causing fail2ban to die silently. The sshd jail fails to start, and fail2ban may appear running but have zero active jails.

Symptoms

$ sudo fail2ban-client status
|- Number of jail:    0
`- Jail list:

$ sudo systemctl status fail2ban
# Shows active but check the journal:
$ sudo journalctl -u fail2ban --since "1 hour ago"
# ERROR: Unable to find a corresponding log file for /var/log/auth.log

Fix: Use systemd Backend

/etc/fail2ban/jail.local

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
backend = systemd

[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 3600
findtime = 600

The key line is backend = systemd in [DEFAULT]. This tells fail2ban to read from journald instead of log files.

sudo systemctl restart fail2ban
sleep 3  # wait for socket
sudo fail2ban-client status

Adding the Asterisk SIP Jail

The Asterisk security log is a traditional file (not journald), so the Asterisk jail uses backend = auto which will detect the file.

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

[INCLUDES]
before = common.conf

[Definition]
_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 =

datepattern = ^\[%%Y-%%m-%%d %%H:%%M:%%S

These patterns match Asterisk 18+ security log format. The key security events:

• InvalidAccountID: Registration attempt with non-existent username
• ChallengeResponseFailed: Wrong password after digest challenge
• InvalidPassword: Straightforward bad password
• FailedACL: Source IP not in permitted ACL
• UnexpectedAddress: Registration from unexpected address for known account

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

[asterisk]
enabled  = true
filter   = asterisk
logpath  = /var/log/asterisk/security
backend  = auto
maxretry = 2
findtime = 300
bantime  = 86400

# Aggressive mode: each repeat offense doubles the ban duration
bantime.increment = true
bantime.factor   = 2
bantime.maxtime  = 604800

action   = %(banaction)s[blocktype=DROP]

# Whitelist your known IPs (phones, trunk provider, admin locations)
ignoreip = 127.0.0.1/8
           <your-office-ip>
           <your-sip-trunk-ranges>

The aggressive mode settings:

Testing the Filter

# Test against the actual security log
sudo fail2ban-regex /var/log/asterisk/security \
    /etc/fail2ban/filter.d/asterisk.conf

# Test with a synthetic log line
echo '[2026-02-20 12:00:00] SECURITY[12345] res_security_log.c: \
SecurityEvent="InvalidAccountID",Severity="Error",Service="PJSIP",\
EventTV="2026-02-20T12:00:00",AccountID="admin",\
RemoteAddress="IPV4/UDP/192.168.1.100/5060"' > /tmp/test-ast-sec.log

sudo fail2ban-regex /tmp/test-ast-sec.log \
    /etc/fail2ban/filter.d/asterisk.conf
rm /tmp/test-ast-sec.log

Verification

sudo fail2ban-client status
# Should show: Number of jail: 2 (sshd, asterisk)

sudo fail2ban-client status asterisk
# Shows current ban count and banned IPs

sudo fail2ban-client status sshd
# Shows SSH ban status

Important Notes

• If your iptables firewall already blocks unauthorized SIP traffic before it reaches Asterisk, you may see 0 matches in the security log. This is expected and correct, fail2ban acts as a second layer of defense.
• The Asterisk security log must exist. Ensure logger.conf has a security channel configured.
• Always whitelist your SIP trunk provider IP ranges or you risk blocking your own PSTN connectivity.
• After systemctl restart fail2ban, wait 2-3 seconds before checking status. The control socket takes a moment to initialize.