VoIP Security Basics
Written by rgower on Apr 08, 2006 - 04:10 PM
While Dean delights us with all those stories of how crooks are listening to our telephone conversations, kidnapping our voices and taking out loans, it is worth noting that they are scare stories, they rank with wondering how anybody ever lived long enough to have children because they should have all died at the age of 6 due to the latest international killer lurgi health risk.
Telephone interdiction is and will remain a rare thing. VoIP is just another Internet application and like all Internet applications there are far easier and more profitable methods that are going to be applied first.
It is easy to intercept data packets of all flavours on the net, but to do anything practical with them (as opposed to simply break them) is rather less easy and for all but the most malicious interceptor the time factor is not worth the effort, you will bore them to death long before they start cutting letters out of web pages for ransom e-mails...
Unless you give them a reason to start taking an interest...
The best way not to be interesting is to make certain that you have covered the basic rules:-
Protect your Network- Lose control of it and you are in deep do-dos
Protect your Server- Overtime, but you do have a disaster recovery backup- Don't you?
Protect your Data
Basic Protection
Passwords
It is fair to say ANYBODY who leaves a password at its default setting ought to put up a big flashing neon sign “I'm yours. Take me!”
But what about the password used to replace it?
Many users struggle to remember how to spell their own name and we have to live with that; just don't let them near anything that can cause damage. But an Administrator should at least make an effort, even spurious capitals and numbers inserted into a dictionary word can complicate the life of would be hackers.
DMZ, Firewalls and Internet
No alien network packet has any right to be on your internal network without being molested and thoroughly strip searched beforehand.
Any company Internet connection ought to have a 'real' IP address, the use of dynamic DNS is a kludge and complicates life. Bigger networks would probably prefer an IP for the PBX itself.
Either way, defence should start before data reaches the server. Which means a DMZ in some form with an outer firewall. There is no point in allowing spurious data hitting the PBX, so they may as well be stopped here.
Most ADSL router firewalls lack sophistication and not everybody can afford a Checkpoint approved Firebox, so generally a port is allowed to pass (or not) and where it is from can not be controlled, consequently you still need a firewall at the server.
Given that you should be able to control from where you accept packets. While you can't do much about the RTP streams (which can come from anywhere), you can control registration, limiting it to the service providers IP?
While we are at it, the biggest risks are from inside your network, and you have a duty to protect the Internet at large, so don't forget firewalling applies to the internal and outbound network as well.
Nor, in most instances, is there any excuse for allowing external access to SMTP and HTTP.
If it's not needed to make it work, block it!
Services
When we have blocked everything we can at the firewall, we find that there are still huge holes in our protection. Fortunately, with 'nix at least, most of the weaknesses in services rely upon at least one other service running, even better that service is often some obscure thing that is only used if you need to do something else entirely.
So the simple answer is look at what else is running and turn it off!
Of course, with 'nix virtually every service can be whittled down to allow access to a particular group or user. So in the worst case and you do get broken in to, whoever did it still can't get far.
Remote Administration
Got to mention this because it appears in all those lists of 'Good things' when justifying the IP-PBX.
If you really need to administer the server remotely then limit access to known IP's, use SSH and https, do not allow root login.
Better still, as with remote extensions, a VPN offers more security.
Remote Extensions
Are a nightmare, if only because they have 'users'.
Again, more complicated passwords are better than using the extension number as passwords.
Specified addresses for the extension and/or non-standard ports will help limit who can get in.
Even a Microsoft PPTP connection will go a long way, though you probably would not want POPToP running on an Asterisk server.
Viruses, Trojans etc
Not last and by no means least in the order of business is to accept that at some point a virus can get to you. Can't say I am aware of one yet that will infect Asterisk and Linux, but it must come sooner or later. So a periodic and effective AV scan is called for. Fortunately one of the best, ClamAV, is free and easy to use
Only item left is a decent intrusion detection system. Sadly I do not know of a good free one for Linux.
And Finally
Even after having done all this, you are not totally safe, but they have to find you first and decide it is worth the effort with so many other larger and easier targets (like banks) and they will have to be jolly clever chaps to do it. So by and large the only ones left are the packet interceptors.
Any real network specialist will undoubtedly have taken umbrage by now for teaching him/her to suck eggs. This is all pretty basic network security. But we do not have to read many Gartner/Forrester reports to know that a vast of proportion of networks are not protected. So if I've missed something, please add it?
Genuine home users are probably baffled, but I hope it has been an interesting read even if not supplying ideas?
Telephone interdiction is and will remain a rare thing. VoIP is just another Internet application and like all Internet applications there are far easier and more profitable methods that are going to be applied first.
It is easy to intercept data packets of all flavours on the net, but to do anything practical with them (as opposed to simply break them) is rather less easy and for all but the most malicious interceptor the time factor is not worth the effort, you will bore them to death long before they start cutting letters out of web pages for ransom e-mails...
Unless you give them a reason to start taking an interest...
The best way not to be interesting is to make certain that you have covered the basic rules:-
Protect your Network- Lose control of it and you are in deep do-dos
Protect your Server- Overtime, but you do have a disaster recovery backup- Don't you?
Protect your Data
Basic Protection
Passwords
It is fair to say ANYBODY who leaves a password at its default setting ought to put up a big flashing neon sign “I'm yours. Take me!”
But what about the password used to replace it?
Many users struggle to remember how to spell their own name and we have to live with that; just don't let them near anything that can cause damage. But an Administrator should at least make an effort, even spurious capitals and numbers inserted into a dictionary word can complicate the life of would be hackers.
DMZ, Firewalls and Internet
No alien network packet has any right to be on your internal network without being molested and thoroughly strip searched beforehand.
Any company Internet connection ought to have a 'real' IP address, the use of dynamic DNS is a kludge and complicates life. Bigger networks would probably prefer an IP for the PBX itself.
Either way, defence should start before data reaches the server. Which means a DMZ in some form with an outer firewall. There is no point in allowing spurious data hitting the PBX, so they may as well be stopped here.
Most ADSL router firewalls lack sophistication and not everybody can afford a Checkpoint approved Firebox, so generally a port is allowed to pass (or not) and where it is from can not be controlled, consequently you still need a firewall at the server.
Given that you should be able to control from where you accept packets. While you can't do much about the RTP streams (which can come from anywhere), you can control registration, limiting it to the service providers IP?
While we are at it, the biggest risks are from inside your network, and you have a duty to protect the Internet at large, so don't forget firewalling applies to the internal and outbound network as well.
Nor, in most instances, is there any excuse for allowing external access to SMTP and HTTP.
If it's not needed to make it work, block it!
Services
When we have blocked everything we can at the firewall, we find that there are still huge holes in our protection. Fortunately, with 'nix at least, most of the weaknesses in services rely upon at least one other service running, even better that service is often some obscure thing that is only used if you need to do something else entirely.
So the simple answer is look at what else is running and turn it off!
Of course, with 'nix virtually every service can be whittled down to allow access to a particular group or user. So in the worst case and you do get broken in to, whoever did it still can't get far.
Remote Administration
Got to mention this because it appears in all those lists of 'Good things' when justifying the IP-PBX.
If you really need to administer the server remotely then limit access to known IP's, use SSH and https, do not allow root login.
Better still, as with remote extensions, a VPN offers more security.
Remote Extensions
Are a nightmare, if only because they have 'users'.
Again, more complicated passwords are better than using the extension number as passwords.
Specified addresses for the extension and/or non-standard ports will help limit who can get in.
Even a Microsoft PPTP connection will go a long way, though you probably would not want POPToP running on an Asterisk server.
Viruses, Trojans etc
Not last and by no means least in the order of business is to accept that at some point a virus can get to you. Can't say I am aware of one yet that will infect Asterisk and Linux, but it must come sooner or later. So a periodic and effective AV scan is called for. Fortunately one of the best, ClamAV, is free and easy to use
Only item left is a decent intrusion detection system. Sadly I do not know of a good free one for Linux.
And Finally
Even after having done all this, you are not totally safe, but they have to find you first and decide it is worth the effort with so many other larger and easier targets (like banks) and they will have to be jolly clever chaps to do it. So by and large the only ones left are the packet interceptors.
Any real network specialist will undoubtedly have taken umbrage by now for teaching him/her to suck eggs. This is all pretty basic network security. But we do not have to read many Gartner/Forrester reports to know that a vast of proportion of networks are not protected. So if I've missed something, please add it?
Genuine home users are probably baffled, but I hope it has been an interesting read even if not supplying ideas?
Reply from smiths on Apr 13, 2006 - 09:15 AM
Nice post reminding people (or at least me -you've made me paranoid now) of the basics.
Just one thought on intrusion detection.
Use tripwire on another file checker to make sure that the system files have not been changed. Its important that if a server is compromised that you know as soon as possible. Once had a public server hacked with a root kit (the installer even kindly left the german readme under /dev/funny_name for me to read once I realised, did not know about it for days. Who knows what the server was up to - as it hid things from logs files and all sorts.
When deploying tripwire, you need to think about what to protect and what not to protect. If you can isolate the dynamic data (for example use includes in extension.conf for Asterisk), from the static config data then you can protect the static data. Hoefully then you can spot if things change.
Simon
Reply from rgower on Apr 16, 2006 - 01:05 PM
Having tightened all the bolts on your now thoroughly secure server- Do you actually know if you have actually secured it?
Some way of testing it might be useful?
There are innumerable on-line port testers, the best free one is probably Sygate On-Line Scanner which unusually will test UDP ports. But only tests the address you are addressing from.
More useful are scanners that will test an address you give it, I tend to use three:-
Net Brute is a nice little TCP port scanner that can test Domain Names, address ranges and web page security.
A neat, but simple UDP scanner is WUPS
And finally there is the Microsoft utility Portqry, a command line scanner for both TCP and UDP for those with time on their hands. It is slow, does need a little DOS Batch file creativeness to be useful, but does say how the port is closed.
You can get the software from http://support.microsoft.com/default.aspx?kbid=832919 while instructions for building a clever batch file are here http://blogs.msdn.com/anthonw/archive/2 ... 99247.aspx
| Forum Rules and Guidelines | About VoIP User | Privacy Policy |
All logos and trademarks in this site are property of their respective owner. Comments and posts are property of the poster, all the rest (c) 2003-2006 VoIP User. No part of this site may be reproduced without our prior consent. |
