Risk D - Prison break

A typical call server from one of the larger VoIP vendors allows you to support IP trunking, whereby you get quicker ROI by switching all branch to branch communication to IP. Long story short, IP trunking is great, it allows you to suddenly take your VoIP enclave and connect it to any place you want in the outside world. Have a branch office or offices? no problem, proprely setup IP trunking over something such as SIP-T is a great thing, no doubt about it; take the MCS series from Nortel, its running SIP-T tweaked out to adhere to Nortel standard. Of all the benefits, introducing another point of entry into your domain is dangerous, let me stress, very dangerous.

Too often will unproperly configured IP trunks leave you vulnerable. How you ask? well take for example a typical setup whereby you've got your Call Manager sitting a few layers from your core routing switches facing the outside world. Let's imagine this outside point is known and not private, take a DS3 lease from Sprint and you're ready to go. How would it be possible for packets that are dangerous to make it to your MCS? Simple, like any other dangerous packet, it has a source, a destination, and usually a payload that will get past primitive firewalls and IPS doing content inspection on protocols that are unrelated to VoIP.

Possible Remedies

• Introduce a VoIP-aware SBC, or what I like to call "middleman", that can screen garbage before it reaches your trunk point on your vulnerable call manager.
• Introduce a IDS/IPS to detect/mitigate against attacks across VoIP protocols such as SIP, Skinny  or UNIStim.
• Lastly put in a box that runs all traffic via iptables ULOG and send those dumps to someone that you know is half-smart in hacking or VoIP security. If their good, they will find ways to see and detect attacks quickly on their own.

• Let's take a look at the first point. A VoIP aware SBC. Where would someone find such a thing? I will tell you right now there is nothing really tangible out there. Maybe Covergence can do something to move its virtual appliance to people like you in the enterprise, but we'll see. Long story short, it does not look good - YET.
• The second point is more interesting; today's market is flooded with IDS/IPS products claiming they can protect you against everything except god himself. Find one with a robust VoIP signaling suite.
• Third point is optional, but very simple and effective. It takes 30 minutes to load a 1U with Linux and get iptables collecting all traffic. Trust me, when the shit hits the fan it's better to have possibly uselss data versus no data.
• The feasibility of the above points is directly related to how paranoid you, or your security entourage is. While the likelyhood of attack taking place on your IP trunk via some unknown vulnerability at the call server is small, remember it takes only one incident. Again back to my point that a good VoIP security strategy is only as strong as its weakest link.

Risk E - Lost in translation

In today's environment many enterprises are faced with a decision, do I rely solely on IP trunking to go to the outside world, or do I use IP trunking for branch to branch activity and PSTN for everything else? In the majority of cases, the answer is the latter. It is very difficult to convince anyone responsible for the telecom in an organization to rely 100% on IP, at least today. And why should they? until the VoIP market matures and we have 5 nine's reliabiltiy guaranteed by our friends at the ISP's on VoIP, there is no reason to feel bad about it. However, all this discussion does not preclude you from choosing a PBX that is fully IP. What I mean is that if your corporate strategy is to adopt IP fully in the next few years, then going with a fully IP enabled PBX is the way to go, meanwhile solving your PSTN dilemma in the short term via a SS7-VoIP gateway. It will allow you to maximize your returns in the long run, since a PBX is usally pretty pricey. 

From the security point of view, I treat anything that takes input A, does voodoo magic on it, and spits out output B, as dangerous. No matter what marketing propaganda you flash at me, I will not trust the system. Taken that stance, its now the job of whatever gateway solution to convince me otherwise. You see, that's the stance you should take, when you call to buy one of these animals. You clearly state that you're in the market to spend X amount, but you need to be convinced from the security perspecitve that PSTN traffic is suddenly not going to introduce unwanted anomolies into your VoIP network; because it could, it very well could. If you have no one to do it, then call me up, I might not do a full blown analysis or vulnerability assessment, but I guarantee I'll give you an honest answer from a security professional on what I think - don't be shy.

I digress, there has not been one single publicly released vulnerabiltiy related to SS7 to VoIP translation but I assure you that they exist. Why am I so confident? For starters take a look at the SS7 spec., then map that to the SIP RFC spec. Now do all of that in an application. Take that as you will.

Possible Remedies

• Introduce an VoIP-aware SBC, or what I like to call "middleman", that can screen garbage before it reaches anything.
• Introduce a IDS/IPS to detect/mitigate against attacks across VoIP protocols such as SIP, Skinny or UNIStim.
• Lastly put in a box that runs all traffic via iptables ULOG and send those dumps to someone that you know is half-smart in hacking or VoIP security. If their good, they will find ways to see and detect attacks quickly on their own.
• Notice the similarity to Risk D, maybe there a pattern emerging....

• Same as Risk D.
• I would also like to add that the risk of attack coming from a PSTN arouce is much less than an IP trunk. Take that piece advice to heart when making all of your decisions.

Feel free to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it and join us next time for the conclusion of security in the enterprise.

This article is subject to copyrights against its respective writer. Feel free to contact them if you wish to use the article in some intermediate form.

---