VOIP security - READ THIS!

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 avoid 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. There are a lot of other bits and pieces under the covers which SAIL does to help with security.

Does SAIL make you safe? No it doesn't, - nothing does, but it is as good or better than anything else if you don't override what it tries to do for you.

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.

In your Firewall

• Don't open port 5060 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 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) unless you intend to conduct remote SIP operations.

• ONLY open the firewall to SIP endpoints you know (unless the far end is using a Dynamic IP which changes often, in which case try to limit access to just that range - even if it is quite large, or consider using a VPN - see below).

SME Server Firewall

In SAIL-2.6 we define the objects SIP and IAX2 in the SME server database 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 signal-event remoteaccess-update

config setprop IAX2 status disabled 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 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 SIP 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 own site we run OSSEC which seems to work well for us.

In the Firewall

Don't open port 5060 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 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) unless you intend to conduct remote SIP operations.

ONLY open the firewall to SIP endpoints you know (unless the far end is using a Dynamic IP which changes often, in which case try to limit access to just that range - even if it is quite large, or consider using a VPN - see below). SME Server Firewall

In SAIL-2.6 we define the objects SIP and IAX2 in the SME server database 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 signal-event remoteaccess-update

config setprop IAX2 status disabled 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 signal-event remoteaccess-update Restricting SIP and IAX2 port access in the SME server firewall

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

config setprop SIP <NoOp>AllowHosts 111.111.111.111/0,222.222.222.222/24 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 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 own site we run OSSEC which seems to work well for us.

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.