Re: Voice over IP applications vulnerabilities/attacks?

>Is anyone familiar with Voice over IP vulnerabilities/Intrusions,
>floods etc ?
>
>I heard Checkpoint has some new protection capabilities concerning the
>issue.

I agree with Paul and Keith that you need to have a sound security infrastructure before you start on VoIP, but I'd like to ellaborate on the "best practice" of deploying VoIP when it reaches outside the bounds of the local enterprise to your employees homes...

I've seen a number of companies caught up in the hype of VoIP and wanting to deploy them to their employees homes and make them part-time (if not full-time) telecommuters. This raises some serious security issues since the devices are communicating across the completely untrused internet instead of the more-trused corporate network. Unfortunately most companies are satisfied with it just working at all and don't understand the underlying protocols deeply enough to know how to secure them. (Below I'm speaking of a larger implementation... usually smaller implementations are restricted to what they can do by smaller budgets and this probably isn't feasible for them.)

Compared to normal home PCs that need access to internal corporate resources, VoIP has some unique considerations when coupled with remote access:
1) A VoIP phone shouldn't need access to the Internet in general, just back to its call manager and the other phones 2) You probably don't want the phones to have access to your normal data network and vice versa (a virus outbreak on the data side could possibly contaminate and DoS the phone network--can you imaging having the same issues with these phones we had with Cisco 675 DSL modems??) 3) VoIP devices have no built-in protection (i.e. firewall) 4) Because phones talk directly to each other for the conversation, how does a phone at an employee's home call a phone on the corporate LAN which has an RFC1918 address?
5) VoIP calls traversing the Internet must be enrypted very highly if discussions of a sensitive nature are conducted over them to avoid 3rd party interception. (Calls on the Local LAN typically bypass this requirement at companies)

What these considerations led to at one company was the following requirements (I'm boiling a lot down into 3 major bullet points): 1) Calls from the outside must be encrypted like a VPN (to head off MITM attacks) because of the potentially sensitive nature of phone calls. 2) Phones remotely must be protected by a firewall which denies all unencrypted traffic to it from the Internet and denies it to everything except other phones and the call-manager. 3) The remote-access telephony infrastructure would stay separate from the internal data network and internal VoIP network. This was due to the risk of a virus inadvertently causing a DoS of the phones because of the web servers and other services they run.

They achieved the third bullet-point by connecting all remote-access phones to a PBX via an IP interface and through that PBX it was able to access all analog and VoIP phones at the headquarters.

(Sorry to be vendor-specific here, but this is what worked and they were an existing Check Point shop... Others may work as well, but this gives an idea of what class of product is deployed where. Keith, since we already have his attention, could probably tell you which products would be ideal from a Cisco standpoint.)

To make numbers 1 and 2 possible they used Check Point's S-boxes to protect the phones and handle VPNs back to the corporate FW. (This also served as a dual-purpose as it replaced the need for a software solution for protecting the PC at the home and allowing it to VPN back to the corporate data network. It also provided some nice control of the policies installed on all of the firewalls centrally.) The calls are decrypted and inspected by a corporate Check Point firewall which because of its granular filtering of VoIP protocols like Avi asked about (in this case H.323 because they liked the aesthetics of a certain type of phone, but SIP could have been used as well and was also considered) enforced rigid restrictions on what data was allowed to go to or come from a phone--it's only a matter of time until a worm comes out attacking VoIP phones... This also logs all the calls going to/from the phones for auditing purposes and protects the PBX from attacks from the Internet at large since they are not encrypted.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

When deployed at your local campus there are a number of things that are sometimes not feasible, like having your VoIP network separate from your data network (maybe using VLANs) or putting a firewall in front of each phone to protect it from attack (heck, most don't even do that for the desktop computers or servers). However, Corporate Security 101 is all about minimizing risk. Once we start taking VoIP outside the Headquarters to other places we don't control, we open ourselves to lots of new risks. We too often look at something that travels over IP and classify it as all the same, but in the case or remote phones, segregating the VoIP data from your normal data can really mitigate a lot of risk.

Just my $0.02,
// Chris

Chris Tobkin                                            tobkin@tobkin.com
 -----------------------------------------------------------------------
 "Those who trade liberty for security have neither." - Thomas Jefferson
                  ~~~   ~~~   ~~~  ~~~   ~~~   ~~~   ~~~
           "Those who give up liberty for the sake of security
          deserve neither liberty nor security. -- Ben Franklin
*************************************************************************