This guide gives you hints on how to secure your 3CX Phone System.

The 3CX Phone System can receive incoming call requests from the outside to the inside (Inbound Calls), or alternatively outgoing requests from the inside to the outside (Outbound calls).

Inbound Calls

Inbound Calls can only have an internal entity as a destination with 3CX Phone System. The first of the two available exceptions to this rule is if you have a forwarding rule to send the inbound calls to an external number, but this would be an intentional setting on the extension's forwarding rules. The second exception is a call coming from another Bridged 3CX PBX installation . If you do not have any bridges configured, you can exclude this exception from your investigation. We can also ignore this case because if you secure both PBX's at either side of the bridge correctly, then the communications between them should be the type of traffic we can trust.

Outbound Calls

That leaves us with securing Outbound Calls. Outbound Calls can only be requested by an extension. An extension can request an outbound call in one of two ways:

External Caller Using the Remote Calling Feature from the Voicemail System

An external user calls in (at this stage still an Inbound Call), reaches a Digital Receptionist, and presses an option that sends him to the Voicemail Special Menu (by default "999" in a 3-digit install).

He could also get there via the Digital Receptionist Extension Bypass feature by dialing the Voicemail Special Menu number directly at the Digital Receptionist prompt. When the caller is in the Voicemail menu, he will be asked for an extension number. The caller here will dial a valid extension number, at which point the PBX will ask for the PIN number. The caller will dial in the PIN number for the extension number, and if it is valid, the caller is authenticated as that extension number.The caller will be directed to the Voice Mail main menu. He can press "9" to be sent to the options menu. From the options menu, he can press "3" to be able to make an outbound call.

This mode of attack can be exploited by automated outbound dialers by using by using brute-force attacks or dictionary attacks on your Extension_Number/PIN combination. Brute force attacks require many more attempts to achieve this, and typically would cost the attacker more in call tariffs than he could gain - as long as you regularly force your users to change their PIN numbers.

The availability of this function is controlled via the "Settings" > "General" > "Global Options" > "Enable Outgoing calls in Voicemail Menu".

You can defend yourself from this mode of attack by simply disabling the feature. If you need to retain the feature, long random PIN numbers are a must. Set a policy of getting extension users to change the PIN number regularly, and disable the Voicemail functionality for those extension numbers who do not need it. Also delete extension numbers which are no longer needed in the system.

How can a Phone Join the System as an Authenticated/Authorized Extension

A phone plugged into the network cannot simply make calls via the PBX. It must first inform the PBX of its presence by using  an authenticated registration process. The credentials for this registration process are the combination of:

  1. Extension Number.
  2. Authentication ID.
  3. The Authentication Password - which must be supplied when creating the Extension.

You MUST secure the credentials using robust combinations before taking the 3CX PBX into production and exposing it to users and potential abusers. Also note that FAX Extensions are equally capable of making calls from the PBX as any other extension, so you MUST also ensure that Authentication IDs and Authentication Passwords for the FAX Extensions are adequately secured as well.

From Where Can a Phone join the System as an Authenticated/Authorized Extension

One key functionality that most PBX implementers and users demand is the possibility to connect an extension to the PBX from a remote location. This mean that whoever is configuring the remote phone (very often the user himself) will need to have the credentials available to him so as to be able to set up the phone. That is why it makes sense for the 3CX Phone System to accept valid incoming registrations from any IP address.

Securing Remote Connections

To address the issue of roaming remote extensions (either because the user is on the move, or because his Public IP Address is dynamic, or both), 3CX Phone System provides another layer of protection via the 3CX Tunnel protocol. The 3CX tunnel Protocol performs three functions:

  1. The ability to overcome NAT issues by consolidating all traffic over a single port.
  2. The conversion of this consolidated traffic into a custom protocol which requires some form of 3CX Tunnel client at the remote location.
  3. A simple additional authentication/authorization layer by means of the tunnel password.

If the remote user uses 3CXPhone as a remote phone, then you can use 3CX Tunnel- A  solution built in to the 3CXPhone for Windows, and Android that tunnels VoIP through one single port eliminating NAT and STUN issues. Using the 3CX Tunnel also makes VoIP work in 3G and 4G networks or when the telco provider blocks VoIP. 3CX Tunnel is also available for iOS devices however it is not built into the 3CXPhone for iPhone so you need to download and install it separately from the App Store.

If the remote users use other phones, you can still secure the traffic by implementing a stand-alone variant of the 3CX Tunnel client, called the 3CX SBC. This client will establish the tunnel to the PBX (typically over port 5090), and then you simply direct the phones to send traffic to the PBX using a machine running the 3CX SBC - including the possibility of having multiple phones making multiple calls simultaneously over the single tunnelled connection.

Combining the Individual Security Factors Together

If you know that your 3CX PBX will never deliver calls using the internet (no remote extensions, no VoIP Providers, no Bridge connections), then you can simply block incoming traffic on the WAN-to-LAN device fronting your LAN to the Internet.

When it comes to VoIP Providers and Bridges, things can be kept relatively secure. If you need the PBX to communicate outside of the LAN for some added functionality such as Bridges and VoIP Providers, you can set up your WAN-to-LAN device to do port forwarding ONLY for traffic to/from the IP Addresses which belongs to the the VoIP Provider and/or the Bridge location. Conversely if you are running a Bridged connection from a slave PBX which is on a dynamic IP Address, this will make securing the 3CX PBX  that much harder a task.

For remote extensions, the same argument applies as it did for VoIP providers. If the remote extensions are in locations that have Fixed IP addresses, rules on the WAN-to-LAN device can be used to address the issue. However, the challenge here is made harder since it is less likely that the remote locations are on a Fixed Public IP address. This is where the 3CX Tunnel protocol comes into the picture.

Main Point Summary

  • When creating extensions, make sure that the Extension Number, PIN, Authentication ID,  and Authentication password are all different and sufficiently robust. Changing these settings regularly (minus the Extension Number of course) would also be a good idea, but if you are not using auto-provisioning, it will make things very inconvenient. If you do not allow extensions to connect remotely then the need to rotate the Authentication ID, and Authentication passwords is much smaller, and in fact if you are using auto-provisioning, it may not be necessary at all. If you are using provisioning for ALL phones, you could also consider changing the phones' web admin password to some non-default value, to avoid having someone with a web browser trying to peek into the phones management console to get hold of connection parameters
  • Disable the remote calling via Voicemail feature unless you absolutely cannot afford to.
  • Use only static public IP addresses for PBX installations - otherwise securing them will be very hard, especially if you are bridging PBXs together. This is without taking into account other difficulties inherent in trying to run VoIP on dynamic public IP addresses.
  • Restrict the range of public IP Addresses which can communicate with the PBX on port 5060 to those which need to have it - ideally only VoIP provider addresses and Bridge connection IP addresses. Ideally you should not allow remote extensions to connect without using the 3CX Tunnel protocol.
  • Make sure the 3CX Tunnel Password is a secure, strong password. You can change the default 3CX Tunnel Password if you so wish but it MUST be secured before going into full scale use.
  • Roaming users should be REQUIRED to use 3CXPhone WITH the tunnel functionality on their laptops.
  • Remote offices should be REQUIRED to use the 3CX SBC to force traffic through the 3CX Tunnel Protocol.

Please do not consider this guide to be the end to all security considerations but use it as a starting security guide with examples.