Network Computing is part of the Informa Tech Division of Informa PLC
Is Your IP PBX Secure?
The current crop of VoIP PBX systems provides an IP-based alternative to traditional circuit-switched phone systems, delivering savings and flexibility for enterprises of all sizes. Like any IP-based system, however, a VoIP PBX brings with it risks that can't be ignored--among them, denial-of-service attacks, privacy breaches, and theft of services.
Securing a VoIP PBX presents some unique challenges, but the alternative--loss of service and, possibly, loss of customers--may be more costly in the long run.
Fortunately, safeguarding an IP PBX doesn't require an army of experts or Big Brother-style intrusions. You can get off to a good start by applying the same basic principles you'd use with any IP-based system: Adopt a defense-in-depth strategy to protect components of your PBX from as many threats as possible. Consider your network infrastructure as well as your phones. How many VoIP phones have you deployed? How big is your network? These calculations will help determine what steps to take next.
Isolating components on virtual LANs is a popular approach for securing the corporate network. Many VoIP phones, including those from Polycom and Grandstream Networks, have built-in switches that set up an 802.1p/Q trunk over the link to the local switch in the wiring closet. 802.1p/Q allows VLANs to share a physical network without leaking information. The trunk separates voice traffic from data traffic, from the phone all the way to the IP PBX.
Isolating VoIP traffic will boost security, but it won't stop all intruders. Software that mimics the VoIP VLAN could let an attacker tap in from a data jack. You can limit the UDP and TCP ports that can access the IP PBX from the VLAN by using the access control lists on switches or routers, or by installing a firewall to limit the TCP and UDP ports that are vulnerable. You can also lock down the Ethernet addresses that access the network.
Defining separate VLANs for phones also makes it possible to better control bandwidth allocation--in other words, raise quality of service--to protect the IP PBX from denial-of-service worms that originate on the network. VoIP doesn't require much bandwidth, but it's sensitive to packet loss and delays, so boosting quality of service can be very effective in keeping conversations going during such an attack.
You also need to be careful with autoconfiguration protocols, such as the LLDP-MED standard or Cisco's proprietary CDP. These protocols ease the administrative burden of VoIP phones and VLAN configuration, but they aren't hard to spoof.
VoIP phones' use of encryption today provides better privacy protection than most legacy phones. However, protection only lasts until a call leaves your network. The public switched telephone network doesn't provide encryption.
The signaling protocol for outgoing calls can be encrypted, as can the Real-Time Transport protocol that transports the actual conversation. Encrypting the signaling protocol will prevent eavesdroppers from gleaning phone numbers within your organization.
Firewall rules should deny all Internet access to your IP PBX servers, gateways, and phones, and should limit access between the phone VLAN and IP PBX. Vendors such as Check Point say they can do this via Session Initiation Protocol filtering, but there may be compatibility issues. Test this feature carefully with your equipment.
You may also want to consider a Session Border Controller. Offered by vendors such as Ingate, SBCs analyze traffic patterns to protect networks from SIP-based denial-of-service attacks.
Using VPNs for Internet access is a logical way to accommodate telecommuters, but if you're using softphones and the VPN becomes compromised, that could compromise your phone system as well. Also, if there's already high latency on the connection, a VPN could put it over the edge.
Peter Morrissey is manager of network design and development at Syracuse University and an adjunct professor at Syracuse's School of Information Studies. Write to him at [email protected].