How to Protect a PBX from SIP Scanning and Brute-Force Attempts

Soon after a PBX becomes reachable on the public internet, often within hours and sometimes within minutes, automated scanners find it and start trying to register. This is not targeted; it is background noise that hits every address. Your task is to make sure none of that noise can turn into a successful login or a billed call. This guide works from the network inward: first reduce exposure, then harden what remains exposed, then limit the damage of any success.

Step 1: Keep the SIP port off the public internet

The single most effective control is to make the SIP port unreachable from arbitrary addresses. Scanners cannot guess passwords on a server they cannot reach.

Use a VPN

Give every remote phone and softphone a VPN connection into the office network. The PBX listens only on internal addresses. This has three advantages:

• Scanners never see the server.
• The VPN encrypts SIP and RTP, so you can use plain UDP or TCP on PBX systems that cannot present a public-CA TLS certificate.
• NAT problems largely disappear because every device has a routable internal address.

The cost is some setup work and a VPN client on each device. For small teams this is usually the best trade.

Use an IP allow-list

If your users connect from fixed addresses, such as a branch office or a provider's known media servers, allow only those addresses to reach the SIP port at the firewall. Everything else is dropped before it reaches the PBX.

Asterisk also supports allow-lists at the SIP layer. For chan_sip, use deny=0.0.0.0/0.0.0.0 followed by permit= lines for each allowed network on the peer. For PJSIP, add a type=acl section with deny and permit lines, which the res_pjsip_acl module applies to all inbound SIP traffic, or set permit and deny on individual endpoints. An identify section with match= only maps a source address to an endpoint. It does not block other addresses. Check the documentation for your Asterisk version for the exact syntax.

If it must be public

Some deployments cannot avoid a public SIP port, for example when a trunk provider does not publish fixed addresses or when staff connect from unpredictable networks. In that case, everything in the remaining steps matters more.

Step 2: Add fail2ban

fail2ban watches log files for patterns that indicate failed authentication and adds a firewall rule to block the source address for a period of time. It is a standard tool on Linux-based PBX systems, and distributions such as FreePBX and Issabel include it or provide a package.

A working setup needs three things:

1. Security logging on the PBX. Asterisk can write a dedicated security event log. The Asterisk Security Event Logger page describes how to enable the security log level in logger.conf.
2. A fail2ban filter that matches the failed-registration lines in that log.
3. A jail that ties the filter to a ban action, with sensible thresholds.

A typical jail definition looks like this:

[asterisk]
enabled  = true
filter   = asterisk
logpath  = /var/log/asterisk/security
maxretry = 5
findtime = 600
bantime  = 86400

This bans an address for a day after five failures within ten minutes. Adjust the numbers to your environment. Also whitelist your own office and trunk provider addresses in ignoreip so that a misconfigured desk phone does not lock your users out.

Remember that fail2ban works per source address. A distributed attack that sends one attempt per address will not trigger it. That is why the next step still matters.

Step 3: Make every secret strong and unique

Scanning only becomes a breach when a guess succeeds. Remove that possibility:

• Generate a long random password for every extension. Sixteen characters or more.
• Never reuse a password across extensions, and never derive it from the extension number.
• Where the PBX allows it, set an authentication username that differs from the extension number. Scanners usually try the extension number as the username.
• Change any default web admin or database credentials that shipped with the PBX distribution.

If a client supports secure storage, use it. SIPdia, for example, stores the SIP password in the Apple Keychain and exposes a separate Auth username field for PBXs that support one.

Step 4: Stop leaking information

Scanners learn which extensions exist by watching for different responses. If an unknown user gets a 404 but a known user gets a 401, the scanner has a list of valid usernames within seconds.

• In chan_sip, set alwaysauthreject=yes so every failed request receives the same response.
• PJSIP challenges requests for unknown users in the same way as for known ones by default, so it does not reveal which extensions exist.
• Disable guest calls: allowguest=no in chan_sip. In PJSIP, do not define an anonymous endpoint unless you need one.
• Consider hiding the server version in SIP messages. In chan_sip the useragent option sets the string that is sent. In PJSIP it is the user_agent option in the global section.

Step 5: Change the port, but do not rely on it

Moving SIP from 5060 to another port reduces the volume of log noise from the least sophisticated scanners. It does not stop a scanner that sweeps the whole port range or a scanner that finds you through DNS SRV records. Treat a non-default port as a minor convenience that keeps logs readable, not as a security measure.

If you do change it, update clients accordingly. In SIPdia, add the port after the host in the Server field, for example pbx.example.com:5080. The SIP port reference lists the usual defaults for each transport.

Step 6: Limit what a compromised account can do

Assume one extension's credentials will eventually leak. Limit the cost:

• Block international and premium-rate destinations on outbound routes for extensions that do not need them.
• Set a maximum number of concurrent calls per extension.
• Restrict call forwarding to external numbers, or disable it for extensions that never use it.
• Ask your trunk provider for daily spending limits and destination blocks.
• Use separate trunk credentials per site so a leak does not expose every office.

These settings turn a successful brute force into a nuisance rather than a large invoice.

Step 7: Watch the call detail records

Every PBX keeps CDRs. Review them, or set up alerts, for:

• Calls outside business hours from normally idle extensions.
• Repeated short calls to the same foreign destination.
• Sudden changes in total daily call volume.
• Registrations from unexpected countries or hosting providers.

Many fraud incidents run for days before anyone looks. A ten-minute weekly review, or an automated alert on volume thresholds, shortens that window dramatically.

Step 8: Keep the PBX updated

The Asterisk project publishes security advisories, and maintained distributions built on it ship updates that include the fixes. Old versions carry known weaknesses that scanners test for specifically. The Asterisk versions page lists each release series with its security-fix-only and end-of-life dates. Keep the underlying operating system patched as well. If a PBX distribution has stopped receiving updates, plan a migration.

Putting it together

Layer	Control	Effect
Network	VPN or IP allow-list	Scanners cannot reach the server
Network	fail2ban	Repeated guesses from one address are blocked
Account	Strong unique secrets, separate auth username	Guesses do not succeed
PBX	Same response for unknown users, no guest calls	Scanners learn nothing
Dial plan	Route and spending restrictions	A leak cannot become expensive
Operations	CDR review, updates	Problems are found and fixed early

No single row is sufficient. Together they make the PBX uninteresting to automated attackers, which is the realistic goal.

Next steps

If your PBX runs Asterisk, FreePBX or Issabel, the Asterisk integration page covers client settings that work with a hardened server. For the client side of the same picture, read how to secure a SIP account and the overview of common SIP security risks.