VOIP security - READ THIS!

From sailpbx
Revision as of 20:29, 7 May 2014 by Adminwiki (talk | contribs)
Jump to: navigation, search

We see a lot of VOIP systems with poor security setups. With the recent increase in SIP phone "phreaking" attacks, it's worth re-iterating the security measures you should take.

In Asterisk

The most important thing you can do to help prevent SIP attacks on your PBX is to implement strong passwords for your SIP extensions. SARK/SAIL will automatically generate a strong password for each new extension you create. If you have older extensions that you created before SAIL generated strong passwords for you (pre 2.2) then you MUST revue and update them if necessary. For these older releases you should also check that you have the following settings in your SIP header


allowguest=no
alwaysauthreject=yes


SAIL automatically generates strong extension passwords for you when you create a new extension and you should not override these passwords. At time of writing, the majority of "phreaking" attacks are simple dictionary type attacks. The attacker sends in lots of SIP register INVITEs using guessable passwords (e.g. password same as extension number). With strong passwords you should survive this type of attack. However, the attackers are gradually getting smarter so you need to careful. Also, don't imagine that because you don't have any remote phones defined that no one can gain access. If your firewall is set to forward inbound SIP traffic to the PBX, then you can still be attacked via your local phones.

Provided you run SAIL 2.2.4-33 or 2.4.1-9 or higher, then SAIL will also automatically generate ACL checking for new locally attached devices. This means that an external attempt to register with the PBX will be that much more difficult for a potential attacker. If you are still worried then install the latest SAIL release (you should at least install 2.2.4-50/2.6.1-7 or higher) and re-generate all of your old extensions if they don't already have strong passwords. Look at what SAIL does when it creates a new extension (particularly the ACLs) and replicate that throughout your extensions.

You should also apply firewall restrictions to your inbound trunks and remote extensions making it more difficult for them to be spoofed. You may think that this is unnecessary to protect a trunk; using the logic "why would anyone spend money on an inbound call to me in order to phreak me?". Trust us there are scams that work just like that.

On your SIP phones

Change the default browser password (or set a password) on ALL of your phones. A common way for hackers to compromise your system is to first hack into your network and then into a phone.

In your SARK (Debian/Shorewall) Firewall

  • Don't open port 5060 to the internet unless you intend to conduct remote SIP operations (using a SIP carrier or a remote SIP phone). With many SIP carriers it isn't necessary to open 5060 at all because they will keep the port alive from the time you register.
  • Don't open port 4569 to the internet unless you intend to conduct remote IAX2 operations (using an IAX2 carrier or a remote IAX device).
  • Don't open any RTP ports (Usually 10000-20000) to the internet unless you intend to conduct remote SIP operations.
  • ONLY open the firewall to remote SIP endpoints you know. If the far end is using a Dynamic IP which changes often, try to limit access to just that IP range - even if it is quite large, or consider using a VPN (see below).
  • Don't allow remote web access to your asterisk workbench (SAIL or otherwise) on a standard port (80 or 443); put it on a high port number on your router and forward it AND restrict access in the firewall to only those IP addresses you wish to allow. Better still, limit access to only the local subnet and use VPN or SSH tunnelling to access it.
  • Move any SSH access to the PBX onto a high port
  • Don't allow remote SSH access to the PBX except to known, trusted end-points
  • DO change the default passwords on your asterisk workbench tool (HTTP and SSH).

In your SARK (SME Server) Firewall

In SAIL-2.6 we define the objects SIP and IAX2 in the SME server database in order to manage the ports (in 3.1 the objects are called sailSIP and saiIAX).

Closing SIP and IAX2 ports in the SME server firewall

config setprop SIP status disabled<br/>
signal-event remoteaccess-update
config setprop IAX2 status disabled<br/>
signal-event remoteaccess-update

For earlier releases of SAIL (2.2.x,2.3.x,2.4.x) you must do an additional step...

config setprop sark UDPPorts 10000-20000<br/>
signal-event remoteaccess-update

Restricting SIP and IAX2 port access in the SME server firewall

This is where you can add an AllowHosts statement to control external access

config setprop sailSIP AllowHosts 111.111.111.111/0,222.222.222.222/24
signal-event remoteaccess-update

In this way you can limit access to just those remote extensions and trunks you want to allow in. The other alternative is to deploy your SAIL/SARK box behind a good quality firewall which can control access to the ports on behalf of the PBX. For frequently changing IP addresses such as home workers or road warriors we would recommend bringing them in over VPN if you can. Adding openvpn to SME server itself or to your firewall server is straightforward and you can then use softphones on VPN connected PC's or hardphones which can run VPN (Snom 370,820,870 can all run openvpn). Finally, you should make sure that you put strong passwords and ACLs onto any IAX to IAX trunks you have that span the internet.

Remote phones

If you can, use a phone type which supports VPN tunneling (Snom 370, 820, 870 all support openvpn, you should also be able to run softphones over a VPN). If you can't, then implement strong passwords and ACL checking of the remote IP address.

Log Analyser

You might consider running a log analyser to give you early warning of attacks and even to take preventative action when an attack occurs. On our SME sites we run OSSEC, on Debian we run Fail2ban. Neither of these tools is a panacea and there are some attacks types which they won't catch.

Third party firewall

Another alternative is to deploy your Asterisk behind a good quality firewall which can control access to the ports on behalf of the PBX.

For frequently changing IP addresses such as home workers or road warriors we would recommend bringing them in over VPN if you can. Adding openvpn to the Asterisk server itself or to your firewall server is straightforward and you can then use softphones on VPN connected PC's or hardphones which can run VPN (Snom 370,820,870 can all run openvpn).

Finally, you should make sure that you put strong passwords and ACLs onto any IAX to IAX trunks that span the internet.

Summary

If you do all of these things then you should be as safe as you can be with the current state of the art in terms of Asterisk, SIP and IAX.