VOIP security - READ THIS!
- 1 Background
- 2 In Asterisk
- 3 On your SIP phones
- 4 In your SARK (Debian/Shorewall) Firewall
- 5 In your SARK (SME Server) Firewall
- 6 Restricting SIP and IAX2 port access in the SME server firewall
- 7 Remote phones
- 8 Log Analyser
- 9 Third party firewall
- 10 Summary
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. The hackers aren't usually interested in making phone calls to talk to anyone. Instead they simply want to make lots of calls to high-cost offshore premium rate numbers which they own. In effect they are simply syphoning money from your bank account to theirs.
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
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 REGISTERs 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. In addition, many attacks simply take the form of unsolicited INVITE's. If you leave your system open then these can often succeed.
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 3.1.1 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 browser. Many phones support in-browser dialling, which is a cool feature but it could cost you a lot of money if someone compromises the phones themselves and uses them to get calls away.
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 to your PBX. While you're at it, 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, better still use VPN to access SSH.
- DO change the default passwords on your asterisk workbench tool (HTTP and SSH).
In your SARK (SME Server) Firewall
SAIL moved away from SME server completely in Version 4 but if you still have a pre V4 version then read on...
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 188.8.131.52/0,184.108.40.206/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. Finally, you should make sure that you put strong passwords and ACLs onto any IAX to IAX trunks you have that span the internet.
If you can, use a phone type which supports VPN tunneling (Many Snom and Yealink models 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.
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 attack types which they won't catch but they have the benefit of always being on-site monitoring your logs for you.
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.
Finally, you should make sure that you put strong passwords and ACLs onto any IAX to IAX trunks that span the internet.
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.