| Keeping your VoIP system secure is essential to maintain five nines of reliability, to have quick call setup, and to have consistently high call quality. You also must maintain the privacy of information related to users and their phone calls, and avoid corruption or damage to the overall system. Start with the physical security of the facilities and the computers and networks inside them. Next, make changes to your network and its core equipment. There will be numerous IP phones and softphones in your VoIP deployment; they need to be secured, because they are potential portals for attack. To keep conversations private, the VoIP traffic must be encrypted. Encryption must be implemented carefully so that delay and jitter don't increase unacceptably. Finally, VoIP is complex, and affects almost everything you know about data networking. Its success calls for the very best practices in management processes, skills, and tools. Secure Your Central Facilities When you think about securing your facilities you should think about three areas: 1) the physical aspects of security, 2) hardening the key servers, and 3) providing for authentication and authorization of users. Strong security begins with physical barriers to prevent easy access for hackers. Maintain Strong Physical Security Maintaining physical security means controlling the comings and goings of people and equipment and providing protection against the elements and natural disasters. Physical security is important for keeping your computers and data secure—if an experienced hacker can just walk up to a computer, it can be compromised in a matter of minutes. This section covers securing the datacenter, the network and VoIP equipment, and the environment around the equipment. Secure the Datacenter The crucial VoIP components—servers, gateways, IP PBXs, databases, and routers—should be confined to a locked room. Protect the room, as needed, with electronic card access, so that you can record who enters and leaves the room. Most enterprises maintain datacenters, where they keep their important servers, databases, network equipment, and management systems. They enforce strict control over who can enter the datacenters, using badges, cards, keys, or a keypad system, as well as log books and human security. Physical access to the datacenter or server room should be limited to a select set of trustworthy administrators. Maintenance people should not be allowed to enter unaccompanied. It may also make sense to install motion-sensor alarms or surveillance cameras in these rooms. If you don't have a datacenter, this might seem like overkill. Small organizations often tend to have their servers in hallways, reception areas, or other publicly accessible spaces. Not only does this expose them to malicious attacks, it increases the risk of accidents from spilled coffee, people tripping over cables, and curious children. Secure the Equipment Lock computer CPU cases and ensure that the keys are protected. Make copies of the case keys and keep them in a restricted location outside the datacenter. Most desktop and tower cases have locking lugs that you can use to keep an intruder from opening the case. The server room should be arranged in a way that people outside the room cannot see the keyboards, so that they can't see user or administrator passwords as they are typed. There should be no evidence of passwords near the systems or under the keyboards. Documentation concerning LAN settings or network equipment settings should not be visible. Avoid keeping confidential information on notes stuck to the edge of your displays. Keep important user IDs and passwords in a restricted location. Secure the Environment Around the Equipment Network cabling, hubs, switches, routers, and even the external WAN interface are vulnerable points in a network. An attacker who can attach to your network can steal data in transit or mount attacks against computers on your network, or on other networks! If at all possible, keep hubs and switches behind locked doors or in locked cabinets, run cabling through walls and ceilings to make it harder to tap, and ensure that your external data connection points are kept locked. Don't let security concerns override the environmental requirements of your hardware. For instance, locking a server in a closet prevents malicious users from accessing it, but if the closet is not adequately ventilated, the computer will overheat and fail, rendering your security concerns pointless. Provide temperature and humidity controls to avoid any equipment damage. Install uninterruptible power supplies on the servers, and connect them with the operating system. They can keep the servers alive or initiate a staged automatic server shutdown when there is a power outage. Any unused modem or NIC connection should be disabled or removed. Harden the Servers A computer's exposure to outside threats begins the moment it is booted up and hooked to a network. It is the job of the IT team to see that the computer is as clean, invulnerable, and manageable as possible from the first day. The sections that follow describe some methods that you can use to limit your server's vulnerability to attacks. Manage Your Storage Intelligently On crucial hard drives, employ RAID technology or disk mirroring. And, of course, make regular backups of the data and the configuration settings for each critical computer. Keep the backed up files in a restricted, offsite location, so that you are not wiped out by a storm or a fire. Create a Secure Build Image Use a secure build image to install the software on all computers related to your VoIP system: VoIP servers, DNS and DHCP servers, database servers, web servers, gateways, and so on. Never install a virgin operating system and its applications on a computer and boot it up in the network. Each computer should contain four security components: vulnerability-assessment software, antivirus software, a personal firewall, and HIDS software. Start with a computer with a hard disk that has been wiped clean. Install the latest version of the operating system that you support. Next, apply the latest patches to the operating system. These appear to change on a daily or weekly basis—consider using a service to keep up to date. Then, install your organization's applications and their latest patches. Next, run a vulnerability assessment against that system, set at the highest level of "pickiness." The assessment may report hundreds of potential holes in the system, usually ranked in importance from critical to low. Spend the time to research and close the vulnerabilities it finds. This may take several days, but it is a good investment—you will be replicating these fixes across many computers, with the intention of avoiding identifiable intrusions. Leave the vulnerability agent on the computer so that it can be updated and run remotely. NetIQ's Security Analyzer (http://www.netiq.com/products/sa/) is well suited for this job; it can analyze a variety of operating systems. Install a personal, or host-based, firewall on the server computer. Ensure that the firewall is initially set in its most secure position. One at a time, open any ports or change any other defaults you know will be needed. An IDS watches traffic patterns for known attack patterns, and stops them or creates an alert when they occur. A HIDS is recommended for critical servers. Given the high target value of a VoIP server and the lag time involved in validating an application or operating system security patch for production use, a HIDS provides early attack mitigation. Install a HIDS on the mail servers if they are being used to store voice mail, in addition to installing e-mail content filtering. Get the latest antivirus software for the operating system, and make sure it is up to date. Ensure that no viruses have been introduced during your build and, again, leave an antivirus agent on the computer so that it can be updated and run remotely by an authorized administrator. This is now the hardened "gold standard," the computer image to clone when creating VoIP servers, DNS servers, database servers, and so on. Replicate this base image with each new installation. Secure the System and Application Software After computers are placed into the production environment, protect them from undesirable booting. Modify the BIOS boot sequence in each computer. Set the hard drive to boot up first, with the floppy and CD/DVD drives thereafter. This makes it harder for an attacker to remove passwords and account data from system disks. On mission-critical servers, floppy and CD/DVD drives could be disabled or even removed to provide the highest level of physical security. Implement strong passwords for accessing the BIOS. If possible, modify the BIOS settings so that the combination of keys to press to access the BIOS is not displayed during the bootup sequence. Turn off all unneeded services, disable any features on the servers that are not in use, and do not run any applications that are not needed on the server, such as an e-mail client or a web server. NetIQ Security Manager has a useful function that enables you to specify exactly which processes and applications are allowed to run on a computer. It enforces those rules, and it ensures that no other applications can be started. VoIP servers may run multiple services that can be distributed across multiple devices to increase scalability and manageability. You can use the ability to run different applications on different computers to increase the level of security. For instance, call-processing managers typically support call control, web configuration, IP phone browsing services, conference calling, and device configuration services. By running these services on separate computers, you can harden each of them and avoid potential interaction among the applications. Also make sure that the services use user or service accounts with only the privileges that are absolutely necessary to run normally. A compromised service should not provide root or administrative access. Use Windows' Capabilities A fast-typing attacker might get to your computer and share its disk drives with no passwords in under 10 seconds, but not if the computer is locked. There is a simple security feature that is free on Windows computers: lock the computer as you walk away from it. To do this, press Ctrl-Alt-Delete and then press K (which is the shortcut for the Lock button). Get in the habit of locking your computer whenever you are away from it. Use the Encrypting File System (EFS) to encrypt sensitive folders on your computer. EFS is available for Windows 2000 and Windows XP Professional. The SYSKEY program is used to enable strong encryption of account password data. It uses a 128-bit key to encrypt the password data in the Registry Security Account Manager (SAM) database. Once enabled, this key is required by the computer every time it is started, so that the password data is accessible for authentication purposes. Use the Windows SYSKEY utility to secure the local accounts database, local copies of EFS encryption keys, and other valuables that you don't want attackers to have. Beware of Shared Drives Shared drives are convenient and easy—they are easy to set up and let you quickly copy files from one computer to another. However, a shared drive without proper access control gives a computer virus a mechanism for propagating itself to other computers. Human viruses are spread through the air and by physical contact. Computer viruses are spread through unsecured shared drives and by e-mail attachments. The best advice is to avoid using shared drives if at all possible. They may be necessary in some cases, but try to limit access to read-only or make sure that only authenticated users are granted full access. Authenticate and Authorize This section starts by defining three terms that many people find confusing: -
Authentication— Are you who you say you are? How do the communicating parties authenticate each other? Is the party who answered the call the intended destination? -
Authorization— Okay, you are authenticated, but what are you allowed to do? -
Non-repudiation— Once someone accepts a call, is there anything in place that prohibits that person from then denying receipt of the connection? If he or she says "I didn't get that call," can your systems prove that wrong? Insiders cause most security problems. Despite the obvious focus on external attacks, studies show that "about 70% of the security risk is internal—either by accident or maliciousness," says Marius Swart, GM of security solutions at Internet Solutions.[8] "However," Swart adds, "a thorough analysis of potential threats can substantially reduce risk of a security breach." Minding the users and administrators within the enterprise is an essential part of analyzing threats and developing a security plan. Creating a thorough plan means establishing or revising your security policies, and then putting processes in place to enforce those policies. Sophisticated software that is designed to coordinate and enforce security policies system-wide should be a part of any attempt to reduce internal security threats. For example, your security policies should describe how new users are handled as they join an organization: How are they identified and what can they access? When users change roles or jobs (or leave the area), are the access controls updated? How are contractors or temporary workers handled when their work and contracts end? Just as important are the policies that are applied to the members of the security team. For example, it does not make sense for a single team member to have full access to all the resources in an organization. Identify the administrators and the functions they are allowed to do. Each team member should have an appropriate range of control, with all actions subject to ongoing auditing. To secure your VoIP system is to know your users and administrators well, and to incorporate that knowledge into the way the system operates. Strong authentication of each user and administrator should be performed, to be certain that they really are who they say they are. Stringent access controls should be enforced, especially for the IT administrative team. Access policies must be clearly and consistently applied: What objects is each administrator allowed to read, write, modify, create, or delete? Is the data that they manipulate properly authenticated? Are the access controls consistent across all systems? Are changes to the validation, authentication, and access control audited? How is data integrity checked? Carefully monitored processes are needed to implement a thorough set of policies like these. For example, NetIQ's Directory Security Administrator (http://www.netiq.com/products/sm/) provides a central view of objects, such as files, folders, and printers, across an enterprise. It shows the objects in the directory structure and displays their associated permissions. Administrators can easily identify the assigned rights and privileges of each object, and make changes to access control lists (ACLs) as necessary. Limit administration access to IP PBXs among the IT staff. Allow only selected members to have access to the core operating system on a VoIP server, gateway, or database. Similarly, protect routers, switches, and gateways. Restrict Simple Network Management Protocol (SNMP) and Telnet access to these devices, so that they can only be used by authorized administrators. Strengthen Your Data Network Data network security is probably already part of your security plan. There are several ways that a data network can be further strengthened for VoIP. Consider keeping voice traffic separated from other types of network traffic, carefully deploying firewalls and NIDSs, and implementing solid policy management practices. Separate VoIP Traffic You want to avoid competition and disruption among different types of traffic wherever possible. In particular, you would like to keep the key VoIP components well isolated, and you would like to keep the VoIP traffic separate from the other data traffic. For increased strength, enforce the separations at multiple layers: -
At Layer 2, isolate IP PBXs and VoIP servers on their own virtual LAN (VLAN)— The core VoIP components interact frequently with one another and their databases, but they don't necessarily need to see the rest of the traffic on the same LAN. Putting them on a separate VLAN should isolate them from lots of other traffic on the enterprise LANs, especially chatty protocols, multicasts, broadcasts, and some level of DoS attack. -
Put chatty protocols on their own VLAN— Network protocols such as DECnet, IPX, and NetBIOS should have nothing to do with your VoIP protocols. Don't allow chatty protocols like these (and their vulnerabilities) on the same network with VoIP traffic, which is sensitive to delay and jitter. -
Isolate voice traffic onto a separate VLAN— Many IP phones contain a data port that allows for computers to be plugged into the phone. Switches can be configured so that the voice and data traffic are carried on separate VLANs. Be sure to put wireless LAN devices on their own VLAN, which helps ensure that users are not orphaned as they move from access point to access point. Don't depend entirely on VLANs for VoIP security, but consider them a good way to keep traffic separated without two physical networks.[9] -
Use switches instead of hubs— Switched networks are more secure than shared hubs and can help prevent hackers from just plugging in a device and capturing data. Again, if your organization is deploying VoIP, eliminate all of your hubs. -
Separate IP PBXs, VoIP servers, and gateways on the LAN by putting the devices in different Windows domains from other servers— The core VoIP components should have different permissions and different users (that is, authorized administrators) from all the other computers on your network. If they need to be in a Windows domain, give them their own. -
Use private IP addressing inside your enterprise: 10.0.0.0/8, 172.16.0.0/12–172.31.0.0/12, and 192.168.0.0/16— One way to reduce external DoS attacks is to use private IP addressing for the VoIP devices. Using IP addresses in the private address ranges 10.0.0.0/8, 172.16.0.0/12–172.31.0.0/12, and 192.168.0.0/16 prohibits Internet-based attacks, because private addresses are not routable on the Internet. Deploy Firewalls and NIDSs Firewalls block undesirable traffic. A firewall is analogous to a checkpoint on a highway—it looks at each car and decides whether it will let the car pass through or whether it will turn it back. It may reject green and yellow cars, but let cars of all other colors pass through. It may reject cars from North Carolina with fewer than two occupants, but let all others through. If there were plenty of time, inspectors could look deeply into each car, say, rejecting those that are not carrying a valid vehicle registration. Admittedly, this is a simple analogy, but it describes roughly how a firewall operates—it looks at frames one at a time and decides which ones it will allow through. The firewall does this based on policies that you have defined; the policies capture the reasoning behind the rules you are having the firewall enforce. Some firewalls can remember information they have seen in recent frames from the same source, to help them make smarter decisions. To continue the analogy, suppose there was a checkpoint that allowed only 10 cars per day to pass from North Carolina into Virginia. A count would have to be kept, allowing the first 10 cars to pass freely, but rejecting all others until the next day. Firewalls that can remember information about what they have seen, and dig deeply into frames for context, are said to do stateful inspection. Streaming voice traffic generally flows on dynamically assigned, even UDP port numbers greater than 16,384. The ports to be used in a phone conversation are specified in the call setup flows (that is, in the H.323 or SIP transactions). To tie a port number to a conversation, a firewall needs to look for the port numbers inside the call-setup frames. Without stateful inspection, a firewall would have to open a wide range of UDP ports (which does not help when it is trying to block undesirable traffic). Firewalls generally add some delay, because they hold each frame while they are looking at it, deciding what to do. In contrast, NIDSs usually don't add delay. Rather than looking a frame at a time, they look across a broad collection of frames flowing in either direction, looking for patterns that signify an attack. The pattern of packets and their flows for many network attacks have been identified; these are known as attack signatures. NIDSs generally reside in switches. They have a lot more to do than firewalls, so they are generally used to detect attacks, not prevent them. They raise events when they detect attack signatures. A technique known as NIDS shunning can block traffic from sources that have generated traffic that matches one of its attack signatures. Once an attack signature is detected on a LAN segment, shunning can be used to dynamically change the Layer 3 filtering configuration of a network device to drop all additional traffic from the source on that segment. Resets can be used to tear down a TCP session that triggers an attack signature. NIDS shunning could be used to block UDP flood attacks sourced from the data segment against the voice segment. Deploy this carefully, though; like any automatic detection system, you want to beware of false positives. You probably need both firewalls and NIDSs in the portions of the network under your control. Research their capabilities with respect to recognizing and protecting VoIP traffic, both the call setup and the actual call flows. Also, examine how much delay and jitter a firewall adds to the VoIP traffic that it passes. Firewalls and NIDSs are improving all the time, but, unfortunately, so is the sophistication of VoIP traffic attacks. Implement Policy Management Keeping a consistent, viable configuration of all the elements in a network can be tough. There are many protocols, many types of devices and software, many details to master, and too few hours in each day. In addition, static configuration is no longer adequate—network configuration may need to change throughout a day, week, or month. Some applications need specialized handling depending on when they are run. For example, the payroll department needs assured response time twice a month; the CEO's broadcast each Thursday afternoon should receive adequate bandwidth. Policy servers are designed to remove you from network configuration details. Consider them a tremendous usability improvement over manual configuration. Rather than mastering every device and its possible interactions, you describe the rules and criteria—for the devices, applications, and users of your network. You also can write policies that take effect at certain times of the day or days of the week, so that the policy server is essentially doing custom configuration on the fly. You create and change policies at a user-friendly GUI called a policy console—the exact look and feel will vary among different vendors. A policy console is connected to a policy server; they may reside together in the same computer. The policy server stores policies in a repository, a structured database for holding the information about each policy. Creating and changing policies should look like other administrative tasks you already have, such as creating and changing the user profiles for the users of a file server. Now the real work occurs. The policy server software converts its policies into actions to be taken at specified times or under certain conditions. Those actions must be conveyed as configuration instructions to real devices in the network, such as switches, routers, and firewalls. To do this, the policy server pushes instructions to policy agents, which translate these into local device-specific configuration commands. For new and up-to-date network devices, the policy client software may reside within the network devices themselves. For older devices, it will probably reside outboard, in a configuration proxy—a computer running policy client software, which knows how to issue device-specific configuration commands. The proxy may issue commands using SNMP, for example, rather than the new protocols designed specifically for policy management. Vulnerabilities often present themselves when equipment is not configured consistently. Figure 8-3 illustrates policy servers delivering configuration directions throughout a complex network. Figure 8-3. Policy Servers Can Deliver Consistent Network Configuration 
The policy console, the policy server, and policy clients communicate with one another by using a high-level protocol called Common Open Policy Service (COPS). COPS is an emerging IETF standard that uses TCP to communicate policy information. Although policy-based network management offers tremendous usability and productivity improvements, expect it to take several years before COPS is supported in all the network devices you use. Configuration proxies will be used in the interim to extend the useful life of the devices you are using today. The policy repository uses a standard directory structure to store its information. This is important for usability and security reasons. Suppose you were to define a policy that enables members of the sales team to get high-priority access to a certain application. You want to use your existing user access definition in the policy for "the members of the sales team." You don't want to re-enter the IP addresses for everyone on the team, or change the policy when someone new joins. You want your policy repository to tie to your existing enterprise directories, to improve the consistency of the administration. Recent policy repositories are compatible with the Directory-Enabled Networks (DEN) schema, so they interface well with the directory services of the major vendors, such as Microsoft Active Directory, Novell NDS, Siemens X.500 Directory, and Sun Directory Services. Because the policy server works from the same central administrative directory as the rest of your network management, you can maintain a uniform level of security. Software that remotely accesses the repository uses the Lightweight Directory Access Protocol (LDAP) for the communication. Secure the IP Phones Don't overlook the security of the IP phones. Incorrect phone configurations create vulnerabilities that can enable hackers to take control of the phone, redirect calls, or possibly overhear conversations. Set Up the Phones Securely The sections that follow describe some precautions that you can take to ensure that phones are set up securely. Manage Phone Passwords Carefully Some IP phones are shipped from their manufacturer with no administrative password—that is, their password is set to null. Null passwords allow easy access for attackers, who can then gain both remote and local administrative access to the phone. Find and change all default passwords. Change them again as soon as someone changes departments or leaves the organization. Follow good password procedures, as always, using complex strings that are not readily guessable or calculable. Where passwords are used, they should be aged and changed frequently. Pay Special Attention to Phones Containing Web, Telnet, or FTP Servers The march of miniaturization continues. Many IP phones and softphones now have web, Telnet, and FTP servers in them. The web server is there to let you use a web browser to update the phone's configuration information. These internal web servers can also be helpful for gathering diagnostic and debugging information. However, a web server is susceptible to every known web-based attack—and there are a lot of them. Some phones require no authentication to get to their web pages. Those who can get through can cause damage by, for example, manipulating the call-setup signaling, rebooting the phone, or getting information about calls made from the phone. Lock down the phone and its internal servers. Check with its manufacturer for details, and keep an eye on the ongoing network forums for information on vulnerabilities and their fixes. Maintain Vulnerability Assessment, Antivirus, and Firewall Software on Softphone Computers Softphones are not as resilient as their IP phone counterparts. Softphones run in regular computers, so they are more susceptible to attacks because of the wide variety of ways they can be attacked. These include operating system vulnerabilities, application vulnerabilities, service vulnerabilities, worms, viruses, and so on. IP phones often run custom operating systems with limited service support and are less likely to have vulnerabilities. Softphones are vulnerable to any attack against a network segment, not just an attack against its host computer. The Code-Red and Nimda invasions, for instance, bogged down softphone user systems and the segments they resided in to such a point that they were unusable. No amount of QoS will prioritize voice traffic over data traffic if the end-user computer that is placing the call is unusable. Limit the Functions Available in Pub |
