Hold the IP Phone
Would you keep your main server in the lobby with an open terminal for anyone to access? No way. But some companies are being nearly as careless by not securing
July 22, 2002
Many fundamentals of securing your IP PBX parallel the basics common to safeguarding your data networks:
• Password-protect everything. A password should be required for users to access their phones every morning, regardless of whether those phones are physical devices on desks or a software package on computers. Open access to an account could allow tampering with the user database. Some vendors, such as AltiGen Communications and Siemens, are looking to help here. AltiGen's IP PBX systems won't let common strings, like 123456, be used, and they don't accept extension numbers as part of passwords. With its HiPath line, Siemens goes a step beyond passwords for authentication, enabling the use of biometrics and smartcards (see w4.siemens.de/networks/hipath/index.htm). While biometric devices aren't invulnerable to attack, the technology is improving, whereas a password will always be a password.
• Make sure users log off when they leave. Getting employees to comply is tough, but they must log off their desktop IP phones. For software-based IP phones, that's as simple as making sure computers are turned off every night. Remind users that if they don't log off and a member of the cleaning crew decides to make a long-distance call to South America, that call will be billed to the employee's departmental account. If, despite your best efforts, your users forget to log off their phones, outgoing call blocks can be set up from the PBX during evening hours or on weekends. Most vendors don't build systems to automatically log users out because, beyond being seen as a nuisance by workers, in case of an emergency you want employees to have easy access to outside assistance.
• Guard against DoS attacks. The denial-of-service attacks that have hit corporate data networks over the past few years can also affect your IP PBX. The first line of defense should be your corporate firewall, but you should also stay on top of vendor patches for the IP PBX's underlying OS.
• Virus protection is not just for the desktop. Any IP PBX that runs an off-the-shelf OS, such as Microsoft Windows NT and 2000, should be loaded with the virus protection software of your choice. Although some PBX vendors, such as AltiGen, ship complete turnkey systems, they often leave virus protection software to the users' discretion.A key area to consider when choosing a PBX is the underlying OS. IP-based PBXs come in two basic flavors, closed and open. Those built around proprietary architectures are considered closed, while systems built on off-the-shelf PCs and OSs are open. For example, Alcatel's systems use Unix or Linux; AltiGen, Avaya and Cisco Systems use Windows; 3Com Corp. and Mitel Networks Corp. use Wind River Systems' VxWorks; and NEC Corp. and Siemens run proprietary OSs (for in-depth reviews of telephony products, see www.commweb.com).
Each type has pros and cons. First, with closed PBX architectures, everything comes from one vendor, meaning you'll have only one company to contact when you encounter problems. Combining components from multiple vendors can make for complex, hard-to-maintain systems and possible security breaches caused by interoperability troubles. Because closed systems don't use off-the-shelf OSs, someone trying to hack into a closed PBX will have to spend time learning about the OS and how it operates. As always, applying any and all security patches for your PBX OS, whether open or closed, is important. On the plus side for open systems, security patches may become available quicker than they will for closed architectures, lessening the time you may be vulnerable.
Keep Your Eyes Open
Monitoring is a must for you to maintain the security of your IP PBX. Get accustomed to examining reports on a regular basis--don't become complacent. Reports are the early warning system that alerts you to possible problems. They can flag not only suspicious IP traffic, but also calls that shouldn't be going through the system.
Scrutinize the reports every day, seeking not only blatantly suspicious calls, such as those to foreign countries and those that occur when people should not be in the office, but also subtler anomalies, such as an excessive number of calls from one extension. Look for calls to locations beyond the normal calling area, as well as those that last longer than usual. And consider using IP PBXs, like 3Com's NBX, available through the Network Supervisor add on, that include a real-time alarm-forwarding feature that can alert you to calls outside the expected norm for length and destination.
On the management side, any access to change configuration of the IP PBX should be carried out on specific TCP/UDP ports that can be encrypted. Limiting administrative access to a particular IP address can also thwart would-be intruders. To avoid IP spoofing, the MAC (Media Access Control) and IP addresses of authentic administrative terminals should be bound together.
Make a New Plan, Stan
The best defense is to be aware of possible holes in your networks, including those in your voice systems. Endeavor to create a risk assessment to pinpoint vulnerable areas in your IP PBX. A comprehensive guide to conducting a PBX vulnerability analysis is available in PDF form from the National Institute of Standards and Technology (Special Publication 800-24). Any assessment should start with defining which PBX services your employees will need, then determining how open those services may be to security attacks. In your assessment, realize that attacks on the IP PBX could come from behind the firewall--a disgruntled user might try to take down your phone system.
VPNs should be used for any external access to the IP PBX, including access by telecommuters or branch office employees who use the corporate voice network. A little latency is a small price to pay for the security this setup provides.
Whatever services you deploy from your IP PBX, constantly testing for security breaches is paramount. Scheduled scanning should be part of your regular regimen. And when breaches occur, it is important to have a plan of action ready. Don't wait until your IP PBX goes down before you think about how to get it back into service.Features That Can Cause Headaches
• DISA: Traveling users make for a host of security concerns, such as how to secure DISA (Direct Inward System Access) services, which enable employees to access the corporate PBX without being directly connected to it--to retrieve voicemail, for example. While the vulnerability pertaining to DISA exists in non-IP-based PBXs, the problem is expanded when gaining access to the PBX can also give an intruder the run of the corporate data network; at the very least, intruders could have the IP PBX place long-distance calls or even crank or obscene calls that would be hard to trace.
Clearly, DISA can be a big security hole if it's not properly managed and should be used only with caller ID and, if possible, RSA Security's SecurID, or smartcard technology. Restricting DISA to only those calling from phone numbers that the system accepts, like a salesman's cell phone, means hackers will have a harder time breaking in, but the trade-off is that legitimate users will be limited in the locations from which they can access voicemail.
• Substitution: While call forwarding moves only calls from one phone to another, substitution moves all the features, including address book, access abilities and personalized speed dial. The danger is that most PBXs let administrators block certain calls to specific extensions and dictate just what calls can be made from an extension. Substitution can bypass all these safeguards by letting employees move the functions they're permitted to use to different phones. Your CEO could be walking out of the building and need to make a quick call. Instead of walking back, using substitution he could transfer the functions of his phone down to a lobby phone and get all the access he would have from his office.
This is great--unless the CEO forgets to log off the lobby phone and transfer the features back to his office. If that's not done, anyone picking up that lobby phone could have access to the CEO's call database and features. Substitution should be kept at one call and then automatically transferred back, or not used at all. At the very least, the IP PBX should be configured to reset itself once a day to put everything back where it was. Note that substitution is a temporary convenience feature and is not designed to be used when an employee moves from one office to another. That's a management area where unified messaging holds promise (see InternetWeek's "A Unified View," and "CallPilot Aces UM Challenge"). But that's another workshop.Darrin Woods is a Network Computing contributing editor. He has worked as a WAN engineer for a telecom carrier. Send your comments on this article to him at [email protected].
• H.323: This granddaddy of convergence standards was approved by the ITU back in 1996 and is still going strong. See www.packetizer.com/iptel/h323/.
• H.248: Aka MGCP (Media Gateway Control Protocol) and Megaco, this IETF and ITU standard goes beyond H.323 by specifying control of multiple gateways. See www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-01.txt.
• SIP: RFC 2543 Session Initiation Protocol is an IETF standard that enables communication of multimedia elements, such as voice, chat and video. See www.ietf.org/rfc/rfc2543.txt?number=2543.
• 802.1p: An IEEE standard. Provides QoS on Layer 2 by assigning user priority values.• 802.1q: An IEEE standard governing VLANs. See www.ieee802.org/1/pages/802.1Q.html.
For more details, see InternetWeek's VoIP glossary and InformationWeek's "Settling On Standards."
If you don't have an IP PBX but wish you did, here are some points to consider when presenting your case:
• An IP PBX simplifies adds, moves and changes.
• You can add new features more easily to software than to a traditional PBX.• You can consolidate voice and data into a single line and save money.
• Many IP PBXs run on open systems, reducing management complexity. Proprietary systems may not confer this benefit.
You May Also Like