If you have been asking yourself how to secure 3CX PhoneSystem, read on…

3CX PhoneSystem can receive call requests from the outside to the inside (Inbound Calls), or alternatively from the inside to the outside (Outbound calls).

Inbound Calls can only have an internal entity as a destination with 3CX PhoneSystem. One of 2 exceptions is if you have a forwarding rule to send the call to an external number, but this would be an intentional setting on the extension’s forwarding rules. The other exception is a call coming from another Bridged 3CX installation – but if you do not have any bridges configured, you can exclude this area of investigation. We can also ignore this area because if you secure both PBXs at either side of the bridge correctly, then communications between them should be traffic we can trust.

So that leaves us with Outbound Calls.

Outbound Calls can only requested by an extension. An extension can request an outbound call in one of 2 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 dialling 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 here 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 VoiceMail 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 dictionary attacks on your Extension_Number/PIN combination, or by using brute-force attacks. 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 latest build of 3CX PhoneSystem V8 disables this functionality by default. The availability of this function is controlled via the “General->Settings->Global Options” page, or, in some older versions of 3CX PhoneSystem, via the Custom Parameters page by setting the “VMDIALOUTENABLED” parameter to “0″.

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, with a policy of getting extension users to change the PIN number regularly, vigilance to disable the voicemail functionality IN TOTAL for those extension number who do not need to have it, and vigilance to delete those extension numbers which are no longer needed on the system.

Extension caller making a normal call

This needs to be examined in more detail.

How a phone can join the system as an authenticated/authorised extension

A phone simply plugged into the network cannot simply make calls via the PBX. It must first inform the PBX of its presence by way of an authenticated registration process. The credentials for this registration process are the combination of the Extension Number, the Authentication ID, and the Authentication Password – which must be supplied when creating the Extension. By default, the Extension creation screen, proposes the Authentication ID, Authentication Password, and PIN Number to be identical to the Extension Number – but this is intended ONLY TO SIMPLIFY FIRST-TIME IMPLEMENTATION. You MUST secure the credentials using more robust combinations before taking the PBX into production and exposing it to users and potential abusers – if you want to defend yourself from abuse. Note also 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.

From where a phone can join the system as an authenticated/authorised extension

One key functionality that most PBX implementors and users demand is the possibility to hook an extension onto the PBX from a remote location. This does mean that whoever is configuring the remote phone (very often the user himself) will need to have the credentials in hand to set up the phone.

It follows therefore that 3CX PhoneSystem will accept valid incoming registration 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 PhoneSystem provides another layer of protection via the 3CX Tunnel protocol. The 3CX tunnel Protocol performs 3 functions:

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

If the remote user uses the 3CX Phone as his remote phone, then things are relatively simple because the 3CX Phone includes its own built-in 3CX Tunnel client, and configuration is minimal.

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 SIP Proxy Manager. 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 the machine running the 3CX SIP Proxy Manager as a proxy – including the possiblility of having multiple phones making multiple calls simultaneously over the single tunneled connection. Note that as at the time of writing, Aastra phones cannot make use of this functionality. Other vendors’ phones work well.

Combining the individual factors together

If you know that your PBX will never be delivering 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.

For VoIP Providers and Bridges, we can still keep things relatively secure. If you need the PBX to communicate to the outside for some 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 IP Addresses which belong to the the VoIP Provider and/or the bridge location. Obviously if you are running a bridge connection from a slave PBX which is on a dynamic IP Address, it will make things much harder to secure.

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

Summary of main points

• When creating extensions, make sure extension number, pin, authid, authpassword are all different and sufficiently robust. Changing pin, authid, and authpassword regularly would also be a good idea, but if you are not using provisioning, will make things very inconvenient. If you do not allow extensions to connect remotely then the need to rotate authid and authpassword is much smaller, and in fact, if you are using provisioning, may not be at all necessary. 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 some rogue with a web browser trying to peek into the phones management console to get hold of connection parameters.
• Disable the remote calling via voicemail 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 apart from other difficulties inherent with 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 only those which need to have it – ideally only voip provider addresses and bridge connection ip addresses. Ideally you would not allow remote extensions to connect without using the 3CX Tunnel protocol.
• Make sure the 3CX Tunnel Password is set to some strong password value. The default value “abc” is obviousy only intended for testing use, and MUST be secured before going into production use.
• Roaming users should be REQUIRED to use 3CX Phone WITH the tunnel functionality on their laptops.
• Remote offices should be REQUIRED to use the 3CX SIP Proxy Manager to force traffic through the 3CX Tunnel Protocol.

Please do not consider this explanation to be complete, but only as a starting guide with some examples.