Why you need this
Put a SIP server on a public IP and within hours it will be under attack. Automated scanners sweep the internet for port 5060, enumerate extension numbers, and attempt passwords against each one. This is not targeted — it is constant background noise, and it never stops.
The risk is not the noise itself but what follows a success. A compromised extension is used for toll fraud: the attacker places expensive international calls through your trunk, usually overnight or over a weekend, and you receive the bill. Losses of thousands within a single night are routine.
Strong secrets are the primary defence. Fail2ban is the second layer: it watches for repeated failures and blocks the source at the firewall before it can grind through your extension list.
How it works with Asterisk
Fail2ban reads a log, matches failure patterns with a regular expression, and after a threshold of matches from one IP within a window, adds a firewall rule blocking that address for a set time.
For Asterisk the right log to watch is the dedicated security log, conventionally /var/log/asterisk/security. This is far better than parsing the general messages log, because it contains structured security events rather than everything Asterisk has to say.
Enable it in /etc/asterisk/logger.conf:
[logfiles]
security => securityThen reload logging and confirm the file starts filling:
asterisk -rx "logger reload"
tail -f /var/log/asterisk/securityThe events worth banning on
Asterisk emits typed security events. The ones a fail2ban filter should match include:
- InvalidPassword — credentials supplied but wrong. The classic brute-force signature.
- ChallengeResponseFailed — the response to an authentication challenge did not verify.
- InvalidAccountID — an attempt against an extension that does not exist, which is what extension enumeration looks like.
- FailedACL — a request from an address not permitted by an access control list.
Matching all four catches both password guessing and the enumeration phase that precedes it. InvalidAccountID is particularly useful: a legitimate misconfigured phone repeats one wrong extension, while a scanner walks through hundreds.
The jail
Add to /etc/fail2ban/jail.local:
[asterisk]
enabled = true
filter = asterisk
logpath = /var/log/asterisk/security
port = 5060,5061
protocol = udp
maxretry = 5
findtime = 600
bantime = 259200That bans an address after 5 failures within 10 minutes, for three days. Those numbers are a reasonable starting point: long bans are appropriate here because the traffic is automated and there is no legitimate reason for repeated authentication failures from a stranger.
Be deliberate about maxretry though. A genuinely misconfigured office phone retrying with a stale password can ban its own site. Allow-list your known networks:
ignoreip = 127.0.0.1/8 192.168.0.0/16 203.0.113.0/24The gotcha that stops it working
This is the detail that causes most "fail2ban is installed but nothing gets banned" reports, and it is not obvious.
Asterisk's default timestamp format does not work with fail2ban. Fail2ban's date patterns generally anchor to the beginning of the line with ^, and Asterisk writes its date and time inside square brackets — so the anchored pattern never matches, fail2ban cannot parse a timestamp, and the entries are ignored even though the failure text itself matches perfectly.
The fix is to change Asterisk's logging date format to one fail2ban recognises, by setting dateformat in logger.conf. Whichever route you take, verify rather than assume — test the filter against your real log:
fail2ban-regex /var/log/asterisk/security /etc/fail2ban/filter.d/asterisk.confThat prints how many lines matched. If it reports matches but zero "date lines", the timestamp is your problem. Anything reporting 0 matched means the filter is not seeing your events at all.
Check the jail is live and see what it has caught:
fail2ban-client status asterisk
iptables -L -n | grep -i f2bA caveat about the future
Since Asterisk 13, the project has been moving security events toward delivery over AMI rather than log files. Fail2ban remains workable, but log-scraping is best regarded as a practical solution for now rather than a permanent architecture. If you are building something new and substantial, consuming security events from AMI directly is the more durable path.
Fail2ban is not enough on its own
Blocking repeat offenders is a mitigation, not a security model. Alongside it:
- Use long random secrets. Never make the password resemble the extension number — that combination is the first thing every scanner tries.
- Restrict by IP where you can. If your carrier authenticates by IP, limit port 5060 to their addresses rather than the whole internet.
- Cap outbound permissions. Disallow international and premium-rate destinations on extensions that never need them. This bounds the damage if an account is compromised.
- Set a spend alarm with your carrier. Most will alert or cut off at a threshold. This is the control that turns a catastrophe into an incident.
Frequently asked questions
Why is fail2ban installed but banning nothing?
Most often the timestamp format. Asterisk brackets its date/time, which defeats fail2ban's line-anchored date patterns. Run fail2ban-regex against your real log to confirm what is and is not matching.
Which log should fail2ban watch?
The dedicated security log, enabled via logger.conf. It contains structured security events rather than general output, which makes the filter far more reliable.
What ban time should I use?
Long — days rather than minutes. The traffic is automated and there is no legitimate reason for repeated authentication failures from an unknown address. Allow-list your own networks to avoid banning a misconfigured office phone.
Does fail2ban stop toll fraud?
It removes the easiest route in, but it is one layer. Strong secrets, IP restrictions, outbound dialling limits and a carrier spend alarm all matter more once an account is actually compromised.