Re: Voice over IP applications vulnerabilities/attacks?

From: Chris Tobkin (
Date: 01/03/03

  • Next message: Randy Taylor: "Re: OSEC [WAS: Re: Intrusion Prevention]"
    Date: Thu, 2 Jan 2003 18:33:42 -0600 (CST)
    From: Chris Tobkin <>
    To: <>

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

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