ConfigManual
Asterisk

Hardening an Asterisk Server: A Practical Security Checklist

Himanshu Pal

Himanshu Pal

What you are defending against

An internet-facing Asterisk server faces continuous automated attack. Not targeted attention — indiscriminate scanning that finds every exposed SIP port within hours. The attacker's goal is almost always toll fraud: compromise an extension, place high volumes of calls to premium-rate destinations, and leave you the bill.

The defence is layered, because any single control will eventually fail. What follows is ordered by impact, so if you only do the first three you have addressed most of the risk.

1. Reduce network exposure

The strongest control is not being reachable in the first place.

  • Do not expose SIP to the whole internet if you can avoid it. Where trunks are IP-authenticated, restrict port 5060 to the carrier's addresses. Where users are remote, a VPN removes SIP exposure entirely.
  • Open only what is needed. UDP 5060 (or TCP 5061 for TLS), plus the RTP range from rtp.conf. Narrow the RTP range to what your call volume actually requires rather than leaving the default 10000–20000.
  • Never expose management ports. AMI on 5038 and any web admin panel should be bound to localhost or reachable only over a VPN.
  • Change SSH off the default port and disable password authentication in favour of keys.

2. Strong SIP credentials

The most common compromise by a wide margin is a guessable secret.

  • Long, random, unrelated to the extension number. Extension 1001 with the secret 1001 is found within minutes of exposure.
  • Do not reuse secrets across extensions.
  • Set alwaysauthreject (chan_sip) or its PJSIP equivalent so failed attempts return an identical response whether or not the extension exists — otherwise the error itself confirms which extensions are real and hands the scanner a valid list.

3. Restrict what each context may dial

This is the control that limits damage after a compromise, and it is the most consistently neglected.

Structure the dialplan by privilege. International dialling should exist only in contexts assigned to people who make international calls:

[internal-local]
exten => _1XX,1,Dial(PJSIP/${EXTEN},20)

[internal-international]
include => internal-local
exten => _00.,1,Dial(PJSIP/trunk/${EXTEN})

A compromised extension in internal-local cannot place an international call at all — the rules do not exist in its context.

Equally important: never place outbound dialling rules in the context that inbound internet traffic lands in. That single mistake turns your PBX into an open gateway with no compromise required.

4. Cap the damage

Fraud needs volume. Constrain it and the worst case shrinks dramatically.

  • Limit concurrent calls on the trunk to slightly above genuine peak.
  • Ask your carrier to bar destinations you never call. A carrier-side block survives a total compromise of your server, which makes it stronger than any local rule.
  • Set a spend alarm with the carrier. Most offer one; most customers never enable it. This is the difference between a modest surprise and a business-threatening bill.

5. Ban repeat offenders

Run fail2ban against Asterisk's dedicated security log, matching the security events that indicate attack: InvalidPassword, ChallengeResponseFailed, InvalidAccountID and FailedACL.

Use long ban times — there is no legitimate reason for repeated authentication failures from an unknown address — and allow-list your own networks so a misconfigured office phone cannot ban its own site.

6. Lock down management interfaces

  • Bind AMI to localhost and grant each user only the permission classes it needs. Never grant command (CLI execution) or system (shutdown, restart, reload) to a routine integration.
  • Run Asterisk as a non-root user. The packages generally do this; verify rather than assume.
  • Change every default credential, including voicemail PINs, which are a genuine attack surface and are routinely left at the default.

7. Keep it patched

Asterisk security advisories are published regularly and some are remotely exploitable. Subscribe to them, and run a supported LTS version — an unpatched PBX two major versions behind is a liability regardless of everything else on this list.

The same applies to the operating system and to the phones themselves. Handsets with old firmware and default admin passwords are a common way in that never touches the PBX.

8. Monitor, because prevention is not enough

Everything above reduces likelihood. Detection determines how long an incident runs — and duration determines the bill.

Watch CDRs for the fraud signature: a surge of calls to one destination, activity outside business hours, unusually long durations, high concurrency from one extension. An hourly check is enough:

SELECT accountcode, dst, COUNT(*) AS calls, SUM(billsec)/60 AS mins
FROM cdr
WHERE calldate >= NOW() - INTERVAL 1 HOUR
GROUP BY accountcode, dst
HAVING mins > 60;

Alert on anything impossible for normal use. An extension producing an hour of international traffic at 3am is not a person, and catching that within the hour rather than on Monday morning is the whole game.

The checklist

  1. SIP restricted by IP or VPN where possible; only required ports open
  2. Management interfaces bound to localhost, never public
  3. Long random secrets, unique per extension, no extension-number passwords
  4. Failed auth responses identical for valid and invalid extensions
  5. Dialplan layered by privilege; no outbound rules in untrusted contexts
  6. Concurrent call limit set on trunks
  7. Unused international destinations barred at the carrier
  8. Carrier spend alarm enabled
  9. fail2ban running against the security log, verified as actually banning
  10. AMI users on least privilege; no command or system
  11. Default voicemail PINs changed
  12. Asterisk, OS and handset firmware patched; advisories subscribed
  13. CDR anomaly alerting in place and tested

Frequently asked questions

What is the single most important thing to do?

Strong random SIP secrets prevent the most common compromise. But the highest-value pair is that plus restricting which contexts may dial international destinations, because the second one limits the damage when the first fails.

Is fail2ban enough?

No. It raises the cost of brute-forcing but does nothing against stolen credentials or a permissive dialplan. It is one layer.

Why set a carrier spend alarm?

Because it is the only control that works after every other one has failed. Fraud runs until someone notices, and a threshold alert is what makes that hours rather than days.

Should Asterisk be exposed to the internet at all?

Only if it must be. Where trunks are IP-authenticated and users can connect over a VPN, there is no reason for the SIP port to accept traffic from arbitrary addresses.

asterisksecurityhardeningtoll-fraudfirewallchecklist