Re: Voice over IP applications vulnerabilities/attacks?

[Chris Tobkin <tobkin () tobkin com>]

> 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.

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
*************************************************************************