Slashdot Mirror
Security In Voice Over IP Converged Networks
dotslash writes: "This article at Internet Telephony Magazine has a very interesting analysis of security issues created by converging data and telephony networks with VoIP: "When the phenomenon of "convergence" between telephony and Internet started, it also brought closer the world of the phreaker and the hacker. VoIP brings all this to the next level. Unfortunately, the security inherent in VoIP solutions is equivalent to that of the early Internet: Non-existent.""
Anyone equiped with a standard issue electrician's but-set can walk up to a house, pop open the telco terminal and listen/make phone calls on any line in the house. Same goes for corporate lines.
"Virtually no security" is an improvement over "_no_ security."
Granted, security should be implemented at each layer if possible, but wouldn't VoIP inherit the security of the IP network itself? So far, most VoIP installations I've seen/heard about are either within an office, connecting handsets to a PBX with traditional trunks, or between offices of the same company using their internal WAN. Granted you can still have attacks internally, but in neither of these scenarios is it very easy for the general public to snoop or intercept your phone calls.
That said, I really don't see VoIP on a large scale taking off for a while. Two things need to occur before that happens;
- Suitably fast data service has to be ubiquitous. Spotty DSL/Cable coverage won't do it.
- Said data service has to be less expensive than conventional phone service. This one's a no brainer.
- Wireless data on a large scale would help as well.
So far, I don't see these criteria being met in all but niche markets, and that's exactly where VoIP has found itself... for now.
Many of the current VoIP deployments today are not using the security features that you might expect to see. In large, this is because the standard itself is maturing and the manner in which security will be implemented is still under investigation. In the case of SIP, the article points out that although the payload (voice) might be encrypted, the signalling isn't. This is not entirely true. One thing that SIP permits is to tunnel SIP as a payload within SIP. The external session serves only as a routing mechanism for the fully encrypted 'real' signaling session contained within. These mechanisms are just completing peer review and implementors are just wrapping their heads around it all. One thing is for sure; unlike protocols that have preceeded them, SIP and it's designers are taking security very seriously. How else could they consider using SIP as an integral part of 3GPP and/or it's use for inter-carrier peering.
Sure, the protocol itself may have exposure issues, and problems with NAT/PAT devices, but there are companies on the market that are addressing these issues as they arise.
Only a couple of months ago, we finished a roll-out for IP phones. The client was a bank and security was the top consideration. In essence, whatever worked to secure data, worked to secure VoIP. The problem in general is not with the technology; it is with the "old school" PBX designers and engineers.
I have met quite a few people, extremely skilled with PBXs, who view data networks as a black box and have almost no knowledge or methodology to work with products that use them, much less secure them.
When these people grasp the realities of the new, converged, technology, we can expect to see quite a few changes both on VoIP systems' built-in security and fail-safe operation.
My university just recently overhauled the on-campus phone system. They replaced the old (working) system with IP phones. They did the whole job in a matter of months, despite very vocal opposition by the CS department faculty. These Cisco IP phones cost $700 a pop.
They hooked the central hub of the phone system up to generators in the event of a power failure. Unfortunately, all our phones depend on switches and routers scattered throughout campus, and the phones themselves have DC power adapters. In the event of a power outage, the central hub will stays on-line, but all the phones throughout campus go out!
When asked what students and faculty should do in the event of an emergency during a power outage, our IT services department responded, "Try to find someone with a cell phone!"
Worse yet, switches have a mean time to failure of 100,000 hours. With 2,000 switches throughout campus, sections of the phone system go out once every 50 hours. The current average time for IT services to replace a down switch is 2 weeks.
These phone have web servers, and a few other goodies. I'm just waiting until an IP phone worm takes out our entire campus's network and telecommunications infrastructure.
Finally, something I know about! This is what I do for a living.
The fact of the matter is that most of the large emerging packet telephony networks are not being deployed in enterprises, but in the carrier networks -- telephone companies around the world are replacing their old circuit-switched back-haul networks for packet-switched networks, either ATM or IP. These are private networks which are not open to the general public, and so do not have the same risks as, say running VoIP on the internet would. Sure, the telcos still need to watch out for attackers... it's just that you've raised the bar far enough that 'script kiddies' would have a tough time.
The article also has an over-simplified view of the effort needed to tap an IP phone call. Even if the user were able to mirror any port on the network onto his computer, he still has the extremely hard task of figuring out which port(s) he needs to monitor -- they typically change on a per-call basis, and the user would actually have to mirror two ports (one for each direction of speech) in order to get the entire call. Now, it can be done, but it's difficult. And, it's made even harder because the signalling path (the communication link that handles setting up calls) is usually encrypted, so it becomes impossible to distinguish among calls.