Securing VoIP: Keeping Your VoIP Networks Safe

BEFORE WE START

In the last chapter the analysis was on the RFC in that it describes what is really necessary to secure the VoIP systems and the actual VoIP conversations. Well, that is what the whole book is about so this should not be a surprise. Several suggestions have been made about how to secure the VoIP network such as using encryption on the media and the control channels. Additionally use firewalls that are VoIP enabled (aware), and use all the techniques possible to authenticate the users (such as certificates to authenticate the phone, and username/password combination to authenticate the person). Throughout the discussions, there were also suggestions for using DoS prevention using an application layer gateway (ALG). There are myriad capabilities if one takes the time to research and use them. Thus, this chapter will attempt to fold in all the topics to build upon and secure the network and the actual voice. It is not the intention of this chapter to recommend any one product, nor to recommend any specific vendor solution. In Chapter 1 it was mentioned that there is no Holy Grail out there (no one-stop shopping). Thus, the intent is to highlight best practices and recommendations to make security a reality.

BUILD IT IN LAYERS

If one could begin at the top of a ladder, then step down one rung at a time; it would become obvious that from the top-down approach there must be some steps that extend all the way to the ground. So too, if we look at a network using the reliable old OSI model, the need for security at different layers comes into play. For example, up at the higher level of the model resides the application layer; thus, if an ALG is used, it would protect the data at the highest levels of the model. But another application layer device, for example, might include the IP PBX.

1. Should the IP PBX be considered, then the following might be areas that come into play:

a. If the IP PBX is Windows Server based (such as Win2k, Win2008, Win7, etc.), then minimize the Windows services where possible. This is a particular point that many hackers are adept at attacking certain parts of a Windows Server. Thus, if the services are minimized to only the ones needed to drive the application (PBX), then other aspects are not accessible (e.g., Cisco CallManager, ADTRAN NetVanta BCS).

b. If the system is Unix/Linux based, then minimize the services there too. Many IP PBXs are Linux based (e.g., asterisk PBX, which is a high target for hackers, Ericsson MX-One, Avaya IP Office).

c. Whatever the operating system, if it is Windows based, then make sure that the NTFS file system is used (as opposed to FAT16 or FAT32).

d. Make sure that the RADIUS server (IAS) and IIS are secured.

e. Lock down access to SQL.

f. Use IDS/virus protection.

2. Assuming that the IP PBX is secure, next look at the firewalls and access control lists (ACLs). In this case the issue is to control the addressable devices on the network (LAN) such as to allow/deny access based on firewall ACLs, including:

a. Allow only call control information (such as SIP or whatever signaling protocol is used).

b. Allow lookup to an LDAP server.

c. Allow management protocols in both signaling and media access.

d. Control the source addresses (remember that SIP uses ports 5060 and 5061, H.323 uses TCP port 1720) to set up a call connection, and the source addresses for a user should fall within the scopes of the LAN.

3. One must not ignore the end points (phones, fax machines, servers, and PCs using a softphone). Much discussion has already been devoted to the actual end points, including the use of authentication (with certificates and username/password combinations) and encryption (using SRTP and ZRTP or any other encryption tool available). In addition to authentication at the endpoint level there should be a mechanism to control the ports at the local layer 2 or layer 3 switches. Some of the steps might include:

a. Make the phone authenticate to the network and the IP PBX/VoIP server.

b. Enforce the phone to also use 802.1X port authentication at the local port/switch level.

c. Ensure the RADIUS server authenticates and authorizes the end user (mutual certificate swap or server certificate and username with password).

d. Use separate VLANs for voice and data network devices. If a PC is using a softphone, then block the data port from crossing the VLANs to the voice ports.

e. Disable the voice VLAN on the PC.

f. Do not allow GARP on the voice VLAN; use GARP protection.

A word about GARP is probably needed here as this is the first time it is being mentioned. GARP stands for Gratuitous Address Resolution/Registration Protocol. It is a tool that was meant to be used as a helpful tool on a LAN, like so many other tools and protocols. However, the use of GARP for malicious purposes has become a risk. For example, most IP-based phones have the capability to use or disable GARP. By disabling GARP, protection is added to prevent the IP phone from replying to GARP requests. Normally when a phone wants to resolve an address for another device on the LAN (i.e., resolve the IP to a MAC address) the phone (or any other device for that matter) will send out an Address Resolution Protocol (ARP) request.

The IP stack provides a protocol for resolving addresses. The ARP is used to take care of the translation of IP addresses to physical addresses and hide these physical addresses from the upper layers. Generally, ARP works with mapping tables (referred to as the ARP cache). The table provides the mapping between an IP address and a physical address. In a LAN (like Ethernet or an IEEE 802 network), ARP takes the target IP address and searches for a corresponding physical address in a mapping table. If it finds the address, it returns the 48-bit address back to the requester, such as a device driver or server on a LAN. However, if the needed address is not found in the ARP cache, the ARP module sends a broadcast onto the network, as shown in Figure 8.1.

A device that owns the IP address replies with an ARP reply back to the requesting device. The reply contains the MAC address of the device sending the reply, so that the ARP table can now be updated with the mapping of the IP to MAC addresses. See Figure 8.2.

Another protocol, called proxy ARP or promiscuous ARP, allows an organization to use only one IP address (network portion of address) for multiple networks. In essence, proxy ARP maps a single IP network address into multiple physical addresses.

The ARP protocol is a useful technique for determining physical addresses from network addresses. However, some workstations do not know their own IP address. For example, diskless workstations do not have any IP address knowledge when they are booted to a system. They know only their hardware address. The reverse address resolution protocol (RARP) works in a manner similar to ARP except, as the name suggests, it works in reverse order: it provides an IP address when given a MAC address. So an end device sends out a RARP request with its MAC address and the ARP server returns an IP address to the device. RARP is often used on LANs for booting the machines to the network. See Figure 8.3.

Now suppose an IP device (phone) receives a gratuitous (unrequested) ARP response providing a MAC address to IP address mapping that differs from the one it already had. So the end device (phone, PC, etc.) will update its ARP table. This is good when using some IP protocols [such as Virtual Routing Redundancy Protocol (VRRP)] and the tables need to be updated; when the router wants to update all the end devices on gateway addresses, the router will send out a GARP request to all devices so that they can update their tables. Conversely, when a GARP request (unsolicited) is sent for malicious purposes it is designed around a man-in-the-middle attack or a hijack attack; then the acceptance of the GARP request is not good. Thus, disabling GARP makes the phone ignore the

GARP requests and adds some level of security. Remember too, the statistics still point to the fact that 80% of the reported intrusions were from internal users who have access to the LAN and could easily generate GARP requests. So as seen in Figure 8.4 the phone device will not listen to the GARP messages from a malicious device announcing itself and therefore prevents the malicious device from assuming the identity of a different device (default router possibly) to become a man in the middle. This effectively blocks a tool called Ettercap. (Ettercap works by putting the network interface into promiscuous mode and by ARP poisoning the target machines. Thereby it can act as a "man in the middle" and unleash various attacks on the victims. Ettercap has plug-in support so that the features can be extended by adding new plug-ins.)

4. Once the LAN and the end devices are considered, the next area is the distribution network. As mentioned already, 802.1X should be used to secure unused (spare) ports in a layer 2 or layer 3 switch. This prevents anyone from just plugging in a phone or PC with softphone into the network. By using this function, a legitimately registered phone cannot be arbitrarily unplugged and moved to a hidden place. Moreover, on the entire LAN or campus network there are some things that can be done:

a. Make sure that the campus or local area network uses secure access using tools such as Microsoft IAS, or SSH secure shell, RADIUS servers, AAA, or TACACS/TACACS+.

b. Keep separate the VLANs between the voice network and the data network. For this IP filters can be used to isolate the VLANs. As already mentioned block the voice VLANs from any PC data ports.

c. Make sure that IPS/IDS systems are up to date and fully operational.

d. Limit the number of protocols/ports being opened in the firewall. The more pinholes opened in a firewall, the greater the risk of penetration. A pinhole is a path through a firewall, through which a flow passes.

e. Can be used to masquerade as someone else.

f. Attack performed by reconfiguring a phone to have the same SIP user ID as another phone.

g. Could be massively applied to redirect all calls for entire enterprise to a different entity.

5. The next area to tighten down is the access to the outside world.

a. Eliminate the use of NAT across the Internet. When dealing with VoIP aware firewalls and VoIP aware NAT devices it is important to limit what will go outside the campus. Other protocols can be used such as Traversal Using Relay NAT (TURN) and STUN.

b. At the external access, install intrusion detection tools that can effectively mitigate the damages and the DoS attacks, such as an ALG. Many tools are now available from the vendors. An intrusion detection system monitors a host or a network for suspicious activity patterns such as those that match some preprogrammed or possibly learned rules about what constitutes normal or abnormal behavior.

c. Also at the entry point, make sure that sensors are installed to sense when a DoS or DDoS attack is being launched. Sensor networks destined for harsh environments should already be designed to continue functioning in the event of a failure. This robustness and disaster recovery program against physical challenges may prevent various types of DoS attacks. Sensors are particularly important in wireless LAN environments where a number of similar and yet different attacks can occur.

SOME BEST PRACTICES FOR INFRASTRUCTURE SECURITY

Given some of the infrastructure issues listed above, a summary of some best practices can address the points made by stating:

1. Manage switches and routers with SSH, HTTPS, and out-of-band (OOB) and permit lists.

2. Separate the voice and data VLANS.

a. Use private addresses, which helps to isolate the addresses from the public Internet; avoid NAT wherever possible.

b. Use dedicated VLAN IDs for trunks in the network.

c. Never use VLAN 1. That is the single most common mistake that people make. When they do not change the default VLAN 1, it is the target of the attackers where they can find and penetrate the networks. Preferably disable VLAN 1.

d. Disable unused ports as already stated. Put all the unused ports in an unused VLAN to keep them off the voice and data networks.

e. Use 802.1X authentication for all ports on the switches.

3. Actively use ACLs.

a. Group assets along a bitwise boundary.

b. Restrict and/or control ARP, GARP, ICMP redirect, and TCP Intercept.

c. Only allow sources from known scopes in the address pools. Limit the scopes to those in use.

d. Protect the QoS of all the packets and any VLAN tagging.

4. With firewalls and NAT use a voice ALG.

a. They perform stateful inspection of voice signaling protocols.

b. They support all of the VoIP protocols now (including SIP, SCCP, H.323, and MGCP).

c. They can be implemented and are available in both firewalls and NAT devices.

d. Firewall ALG inspects signaling packets to discover the UDP port that the RTP stream uses; then it dynamically opens a pinhole for the UDP port and watches for an end-of-call signaling to close the pinhole.

e. NAT ALGs modify the private originating source IP address and port number (the socket) in the signaling packet to a publicly addressable NAT'ed IP address and port.

5. Layer 2/layer 3 caveats:

a. Port security and private VLANs are not supported on trunk ports, including auxiliary VLAN ports for phones. Both can be used on servers.

b. Firewall and NAT ALGs presume that both the signaling path and the media path pass through the firewall and/or the NAT. If this does not happen, then it unnecessarily opens up a pinhole in the firewall and it turns the NAT device into a media termination point (MTP).

c. It should be understood that ALGs are not as efficient in complex firewall implementations.

6. Physical security is important too!

a. Remember the physical plant in all network designs; all too often this is overlooked.

b. Access to equipment and equipment rooms must be controlled. This means that when there is a special room that houses the IP PBX and/or the added equipment such as media gateways, proxy servers, DNS and DHCP servers, etc., this room must be secured from public access. A caveat here is that most organizations try to squeeze out just enough room for the equipment at hand. Sometimes this room is shared with other types of equipment such as switching systems or maybe even a janitorial closet. Regardless of the conditions, it is imperative that the equipment room be locked and access controlled. The servers could be exposed to anyone who may walk by if the room is not locked and secured. This allows anyone to access and possibly reconfigure the system, which is highly undesirable.

c. Pay particular attention also to the rest of the room; for example, are there any containers, or water pipes, etc.? It is all too easy to overlook the fact that these facilities are not conducive to a secure and safe operating procedure. The security plan should include such and audit to make sure that things like this won't happen. One quick point here is that security includes the following items: confidentiality, integrity, and availability. If the room presents the wrong access methods, or the wrong environmental conditions, the equipment is likely to fail. Thus, availability cannot be assured. It should also be noted that the availability of the telephone systems in the past has always been considered a 99.999% requirement because of the lifeline responsibility.

d. In all equipment rooms pay particular attention to maintain the environment within the limits specified by the manufacturer. In many instances equipment rooms were designed for air conditioning (cooling) and power (battery backup and commercial) based on the switching racks. Now that VoIP is being used, these rooms are also used to provide backup power and Power over Ethernet (PoE) to every telephone end point. This creates a huge demand for cooling and added power in the rooms. However, many of these rooms are not sized suitably to handle the added demand. Keep this in mind when laying out the network.

e. Although there is some benefit for security purposes to centralize resources in a secure room, many of the critical resources may require that they are dispersed for a redundancy and recovery plan. Do not lose sight of what must and can be consolidated and what equipment should be dispersed.

f. Make sure that the access panels for the power and air conditioning are secured. It should be understood that killing power can be a very effective DoS attack, especially in line with item number 3 above.

g. Dealing with a mixed-use situation, such as using the PC switch ports on an IP phone, may create more difficult security practices. Think if the use of the extra port is necessary. If it is not necessary and not in use, disable it.

7. Use dynamic ARP inspection.

a. Dynamically binds IP address to MAC address to prevent fraudulent addresses.

b. Automatically creates a VLAN ACL (VACL) to provide access control on all traffic. The VACL is used as a packet filter and packet redirect to enhance security.

c. In the event of a loss of link, it will automatically reset.

d. All hosts using dynamic ARP inspection must support DHCP.

e. It is possible to configure and provide a manual IP to MAC address binding, but it is too tedious.

8. At the VoIP gateways do the following:

a. All VoIP gateways only allow VoIP call control from the IP PBX Manager (or Call Control Manager Cluster).

b. All VoIP gateways should deny any H.323, MGCP, Skinny, or SIP connection attempts originating from the data network.

• • There is no way to enforce a centralized plan if any PC can arbitrarily use the VoIP gateway for initiating calls.
  • Not doing this creates a DoS vulnerability on the VoIP network.
  • Also opens the door for a session hijacking situation.

9. Consider phone hardening – many of the phone systems out there today have a phone load that introduces the phone hardening. This helps raise the bar against security vulnerabilities.

a. Use 802.1q packets tagged with the voice VLAN tag blocked on the PC port.

b. This helps to block malicious sniffing of voice streams from the PC port on the phone.

c. Blocks intentional sniffing in troubleshooting and monitoring situations.

d. Stops the use of VOMIT.7

e. Allows the phone to be configured to ignore the GARP messages.

f. Both features are typically configurable options on the phone administration page.

10. Application hardening in the IP PBX:

a. Disable the autoregistration feature in the IP PBX. Although this is useful for a bulk deployment, such as the initial deployment of hundreds of phones, it should only be a temporary use.

b. Harden the operating system, such as Win2k (2000, 2003, 2008, and now 2012). Typically the OS is shipped in a default Win state, but there are fixes that are downloadable from the vendors and from Microsoft.

c. Make sure that virus protection is installed on the OS.

d. Use dedicated servers for the functions that an IP PBX may be used for such as TFTP/FTP, Syslog, XML transport of data, music on hold, and voice processing/mail. On dedicated servers these features can be offloaded and protected separately.

e. Where possible disable services in the OS that are not needed, for example, DHCP, IIS, IAS, and TFTP for subscribers.

f. Use various levels of administration for the system. For example, help desk functions may be able to display only, whereas superuser can configure security and features.

g. Limit extension mobility so that persons cannot pick up a phone and move it to a hidden place where it can be abused for tolls, fraud, interception, etc.

h. Wherever possible, limit the area codes as already described to prevent toll fraud.

i. Limit the Call Forward All calls that will prevent an authenticated user from using the system for toll fraud.

• • Forward a phone call from a work phone to a home phone, have relatives call toll-free office number, and then transfer that call from office to employee home.
  • A second example is forwarding a work phone number to a hotel or resort in a foreign country while on vacation, and then having friends from home call the resort for free.
  • When an employee needs to make international calls from home (personal), they can use the web to forward their work phone to a desired international number; then employee calls the work number (from home) that has been forwarded.
  • Turning off the forward all feature can stop this, but sometimes it may be legitimate. Therefore, it must be done on a case-by-case basis.

11. Block call forwarding from voice mail ports.

a. Also be careful that no access to the voice mail ports (admin) is available through remote access (modem or web-based access). This way the VM system cannot be used to forward calls similar to the discussion in item number 10 above.

b. Only allow access to maintenance personnel from remote when scheduled and absolutely needed. If a technician needs access, turn it on only for the duration of work and turn it off after completed.

12. Social engineering – Be careful that the operators are trained on social exploits such as when a caller connects and asks to be transferred to extension "9011," which is usually the code for gaining outside access "9" and the code for international dialing "011." This exploit comes from a hacker calling and saying something like "Hello this is the Telephone Company testing your circuits. Please transfer me to extension 9011." Of course, once the transfer is done (if done), the caller has access to call any international number in the world and run up a monstrous telephone bill.

INTEGRATING NETWORK SECURITY

Having stated all of the best practices above, there should be some form of hierarchy to network security. This means that somewhere, as described earlier, a decision should be made to link the security policies and procedures for VoIP with the security policies and procedures in place for the network. For example, looking at Figure 8.5, one could apply rules that state:

1. If a user is demonstrating any form of malicious behavior, such as attempting to gain access to network resources that are not authorized, then the system policy should be that the user will not gain access to the network. If the device cannot authenticate to the port level switching system, then, again, no access shall be given.

2. Above the malicious behavior on the chart, if the user or device is creating any policy violations such as using an unauthorized device, a wrong procedure, or even an application that has not been approved for the network, then it is likely that an alarm indication will be sent and the user may or may not gain access. This really boils down to a "flip of the coin" as some violations may be minor (e.g., trying to use a different soft phone than approved, or using a video application that is not authorized). Conversely if the user appears to be attempting to break into a system of service, then the violation is considered major and no access will be allowed. Additionally if a signature of a virus or a sniffing tool is detected (e.g., Ettercap), then service will be denied to that user.

3. At the top of the chart is a strict enforcement policy that states the user will use user-based authentication to the RADIUS server, and if the user fails authentication, then he/she will be denied access no matter what. Additionally, the encryption policies such as IPSec or SRTP protocols will be used, but if the user does not enable these required protocols, then, again, no access will be allowed. At this level on the pyramid, there will be no exceptions. The user either adheres to the security policies or gains no access to the VoIP network.

So the IP telephony service dictates that new security initiatives be added to the existing IT security plan and enforcement must be equal to or greater than the existing IT policies. For example, the new initiatives may include the following as a minimum:

1. New infrastructure capabilities – These include the fact that PoE to every phone should be a requirement. The reason for this decision is that voice has always been considered a lifeline service. The "always available" dial tone is a requirement for this service. If a person takes ill or becomes threatened, that person needs the assurance that when they pick up the phone to dial "911" or any other assigned number, the dial tone will always be there. When the phones are plugged into a local outlet (using the provided power brick) and power goes down, the phones will typically not work. That is unless PoE is provided to every phone. Now in order to provide PoE to every phone, more backup power (UPS) is needed in every closet in order to power all the phones. As mentioned, the closets are normally small and will be tight, so trying to add power in these rooms may be a challenge. Also, with the added heat that will be generated in the closets, more air conditioning will be needed, stressing the already tight spaces. In some cases, there may be a need for more closets to house all this equipment. Thus, the infrastructure for the phones is a must. In addition to the requirements for the phones, there will be the IP PBX, SBC, media gateways, and myriad other devices that will also have to be backup powered in order for the phone system to work.

However, data access has rarely been considered a lifeline service. If power is down, then the access to the computer screen and data must wait until the power is restored and the systems reinitialized. One cannot power all the PCs and printing services in a building at a reasonable cost. Therefore, the infrastructure for the data side is unchanged. Think however if the use of a softphone is employed. This may require the PCs to be backed up if no hard phones are in place and all the phones are powered by softphones. This is a consideration that must be taken into account. One possibility now with the proliferation of tablets and laptops is to eliminate the desktop devices and run on batteries in the laptops/tablets to power the softphones. Each of these considerations must be considered.

2. Another security initiative is to include the hardening of the IP PBX server as already described. Regardless of the operating system (Windows Server based or some form of Unix/Linux based) look at minimizing the services on the servers so that access is limited and services are moved to dedicated servers (such as DHCP, DNS, IAS, RADIUS, etc.).

While looking at the server hardening, consider the hardening of the phones as discussed above such as turning off the autoregistration, locking down the admin screen for configurations, turning off replies to GARP, and using certificates to register.

Look also at hardening the MTPs with virus protection, firewalls that are VoIP aware, and the limited access methods.

Also add to the security of the media gateways. Make sure there are no back doors to access these devices. If there are, close them. Use ALGs that will assist in intrusion detection systems/intrusion prevention systems and allow only certain access methods through the ALG. Add to the gateways an ALG that will prevent DoS attacks.

3. Next be very specific to have the vendors install systems that require device authentication. Already discussed in previous chapters is the use of a certificate of some sort to authenticate and authorize the devices (phones, GWs, MTPs, etc.); preferably a mutual certificate swap is recommended, but if not a mutual certificate, then at least a single certificate (and possibly a dongle or single access key such as a Secure ID) should be used. Also use the 802.1X standard for port authentication for the devices. Only authenticated devices will connect to a port on the local Ethernet switch and others that cannot authenticate will be denied access to the network.

4. Beyond having all devices authenticated and authorized, ensure that human authentication and authorization is enforced. This means that beyond the device gaining access to the network, no privileges or phone access is available unless the user authenticates. Once again this can be with the certificates, a username/password combination, or a token (like a CAC card in military systems or a Secure ID dongle). By ensuring both device and person authentication, the risks are minimized considerably.

5. Ensure that when installing the VoIP system the integrity and privacy of call signaling and media channels can be preserved. Of course, this means using the encryption methods discussed (i.e., SRTP, ZRTP) and where possible using VPN or IPSec to secure the channels. Probably the single largest effort that will surface is the integrity of these channels. Once the system is connected to the Internet especially, there is little that can be done to control the crossweb connections. Thus, using strong encryption, make sure that the AES 256 encryption standard is applied in the network works. But, what of the call that is going to a random off-net user? That is where the risks build. You cannot encrypt the media channel, for example, unless the opposite end can decrypt. So perhaps you are using a VoIP ISP (called ITSP) to provide the transport of encrypted traffic and signaling channels to an end point (tail-end hop off) where the call is carried on a secure channel until the end of the ITSP's network, and then decrypted and sent to the far end on a very short PSTN link. Consider asking what the ITSP can provide and to what areas this can be provided.

6. While discussing the integrity and security of the traffic, consider also the integrity and security of control channels, provisioning access methods and any other signaling necessary. Whenever a call is being initiated in either H.323 or SIP, we know that there are session description parameters exchanged. So when an "invite" from SIP is sent out from Bob to Alice, we know that Bob will send the SDP message first along with the invite. See Figure 8.6 where Bob sends a SIP Invite to Alice. Note the first line includes the parameters.

The parameters are described in RFC 2327 in which session descriptions are explained as follows:

An SDP session description consists of a number of lines of text of the form <type> = <value>. <type> is always exactly one character and is case-significant. <value> is a structured text string whose format depends on <type>. It also will be case-significant unless a specific field defines otherwise. Whitespace is not permitted either side of the '=' sign. In general <value> is either a number of fields delimited by a single space character or a free format string.

A session description consists of a session-level description (details that apply to the whole session and all media streams) and optionally several media-level descriptions (details that apply onto to a single media stream).

An example SDP description is shown in Figure 8.7.

Note that the SDP example conveys information that has the IP address and port numbers of the sender and the receiver. It also has e-mail contact information and it describes the media channels (both audio and video with an application also being described). This is a lot of information in the signaling channel that will aid a hacker in interception, man in the middle, hijacking, and/ or bandwidth stealing. By changing any of these parameters the hacker could either disrupt or hijack the session.

In Figure 8.8 H.323 parameter description is shown. What this means is the SDP information is exchanged in the negotiation stages of the call setup (in the H.245 protocol) regardless of the VoIP protocols being used.

7. The next area to consider in the security initiatives is to be sure that configuration tools are locked down so that a hacker cannot gain access to the system components and reconfigure them; for example, a redirection or a forwarding element should not be available to anyone for the taking. Along with this thought, an area that should also be protected is the management of the system. Particularly, the reports and alarms should not be available to others; these tools should be locked down and secured. Preferably the management tools should be offloaded from the VoIP server and maintained on a dedicated server that is well secured. A Syslog server may serve as a home for the management and reports.

When looking at the above initiatives, the building in layers concept comes back as a means of implementation. Shown in Figure 8.9 is a pyramid to look at working from the bottom up.

At the bottom of the pyramid is the title Secure Network Infrastructure. This is where layer 2 and layer 3 security can be implemented. In this portion is where the 802.1X architecture controls the access to the port-based security. As already addressed, it is at this layer 2 position that no access will be granted unless the device can authenticate. Moreover, at this bottom rung of the pyramid, intrusion detection and intrusion prevention will come into play. Firewalling with VoIP aware firewalls and VoIP aware NAT devices can be implemented. Monitoring all activities for any form of malicious behavior will shut down the ports that display this form of malfeasance. Note this is the secure network access.

Looking at the second rung on this pyramid is the phone authentication. Once again with a mutual certificate-based system or a certificate and a dongle architecture, the phone will not authenticate and be authorized to the network or to the IP PBX unless this portion of the security management is met. At the network level (layer 2 or 3) the phone will be granted access to the LAN on successful authentication to the network devices (layer 2 or layer 3 switches using the 802.1X protocol and a MAC level authentication). At the IP PBX the phone will also have to authenticate to the server. This is that second step of authentication in which the mutual certificate swap or a server certificate and dongle authentication takes place. This is what is used for most system-based access methods in a data network, and should be used similarly in a VoIP environment.

At the next level up on the pyramid is the security stage for securing the media and the control channels. Here encryption and VPN/IPSec will come into play. The encryption should be between the signaling devices, such as media gateways, ALGs, firewalls and NAT devices, and SBCs along with any MTP devices. VPN end-to-end is a prime example of what to use for these devices (e.g., gateway to gateway); using an IPSec tunnel would be perfect for this connection. The gist of this layer is to handle trusted device connections; it would not be appropriate to attempt a VPN or IPSec tunnel with an unknown device that is not under our control. That could be a problem as a false tunnel could be built to a nonsupported device.

At the top of the pyramid is the user and specifically user authentication. As the human interface between the two end points (phone to phone) a user should authenticate to the server using what has already been discussed such as username and password, or a token device or a mutual certificate swap. Regardless of the methodology, the goal is to allow only authorized and authenticated users to make and receive a call. If this part is neglected, then the possible resultant toll fraud could be extremely high. Moreover, if an unauthenticated user can get on the network, the risks of sniffing, eavesdropping, and hijacking all exist. One cannot be too careful in this event. Additionally if the data port on a phone is not locked down, a potential hacker could use the data port as an access means to try to usurp the basic phone security by running a sniffer (VOMIT, Wireshark, Ettercap) and try to breach between the voice and data VLANs (basically jumping the wall between the VLANs). The least amount of access given reduces the amount of attempted cracking and hacking tools that can be used with any effect.

Notice on the sides of the pyramid are two distinct labels. On the left side is an integrated approach. This is what is meant by integrated security, taken as a system-wide approach. Any of these pieces on the pyramid can be implemented individually but total system security is not achieved. In fact, a false sense of security would be present if only pieces were attempted rather than a holistic approach. On the right side of the pyramid is what must be brought together. Security policies must be integrated with both the data and the VoIP side of the network, as well as a single set of management tools that can monitor the entire system. Admittedly, there may be some unique tools that pertain only to the voice (because of the media and signaling channels) but they would still be integrated into a homogenous system to monitor, prevent, and react whenever something happens. The goals of this holistic approach would be to increase end user productivity such that once authenticated and authorized, they should not have to worry about security breaches that will affect them. Another clear and present goal is the asset management and protection. As VoIP managers, it is incumbent on our security awareness and propagation. Any breach is an embarrassment; repeated breaches will cost our organizations money, confidence, risk of lawsuits, and loss of job security. If all plays out appropriately, the final result will be a secure network, secure voice, and reduced overall operating expenses.

ADDITIONAL THOUGHTS AND ITEMS

In this section are given some additional thoughts that should be addressed when protecting and integrating the VoIP system into the data network. It is extremely important to use a multilayered approach on the VoIP network.

• No matter what, the goal is to preserve the QoS of the VoIP while at the same time providing the necessary security of the control, signaling, and media channels.
• If the configuration menu on the phone relies on FTP, make sure to use nondefault username/password for the FTP account.
• If the configuration menu on the phone relies on TFTP, you must implement an auditing process of the configuration files. Additionally, make sure that the default username and password are changed to a unique one.
• When looking at social engineering issues understand that for a hacker, spoofing Caller ID and called party information with VoIP is very easy. End users must be made aware of this possibility and trained not to trust the Caller ID being displayed. One such spoofed call displayed that a call was coming from a very high-ranking executive in an organization whereby the help desk personnel gave out the username and password to the caller allowing the caller access to the senior executive's account.
• Audits on the VoIP systems should be done often to ensure a malicious attacker has not compromised the system. If a malicious user does compromise the system, they can redirect outbound calls.
• When integrating the VoIP system, be careful not to allow access to customer information or employee information from the PSTN. This holds true with the data network.
• Wherever possible all access to the in/out PSTN should be protected with a PIN or an access code/password combination that is unique.
• Whatever happens, do use a VPN for the traffic and control information that traverses the Internet or the PSTN.
• When implementing VoIP on the corporate LAN be sure to use SRTP if it is available. If SRTP cannot be used, then segregate VoIP traffic data traffic with the separate VLANs. If that cannot be done, consider installing a completely separate physical network.
• Be careful with SRTP on the Internet, as the headers could be exposed, compromising the encryption techniques and keys.
• If possible, use separate DHCP servers for the voice and data networks. Also make sure that the DNS servers are secure.
• Whenever possible do not allow remote management, but if it must be used, then use SSH or IPSec to secure the management.
• Do not assume that the vendor(s) will automatically secure all the components and protocols used in the VoIP network.

REGISTRATION SPOOFING

Already discussed is the trick that hackers attempt to spoof the registrar server into thinking that they are someone else. This spoofing technique manipulates the register message to the server. Any spoofing is bad, but when a hacker can use a spoofed registration, it leads to some of the following issues:

• It can either be a precursor to a DoS attack or be effectively used as a DoS attack itself.
• Spoofing allows the hacker to masquerade as someone else and preferably a high-ranking member of the organization with sufficient permissions to gain access to any part of the system.
• It is performed by reconfiguring a phone to have the same SIP user ID as another phone. Capturing a register message on the LAN and then manually replicating that register information is relatively simple with many of the tools (e.g., SiVus).
• Once spoofed the spoofed device could redirect all calls for entire enterprise to a different entity. Although this would be recognizable fairly soon and then shut down, if a portion of the enterprise traffic is redirected, the results could be worse.

SUMMARY

Integrating VoIP onto a network can pose significant risks to the already existing data network. It can also open many opportunities for hackers to launch attacks against the voice side of the network because they do function differently. As a result the above lists (although not all inclusive) should provide enough thought-provoking areas that will make the system administrator dig even further to prevent any opening of holes in an existing network. The integrated VoIP system also opens the entire network to a new public access mechanism called the PSTN. This means that two different exposure points exist: the Internet and the PSTN. Whenever creating an integration plan strong encryption is a must (prefer AES-256). Passwords for the system must be strong and unique. However, do not store the password files on the VoIP server; instead use a separate server for that role.

For an IP PBX a best practices guide should be used that provides:

• Internal control and audit:
  • Develop policy and perform assessments.
  • Eliminate unnecessary modems.
  • Centralize architecture.
• When vendors use modems for support:
  • Turn them off when not needed.
  • Use centralized remote access.
  • Audit usage.
• Authentication:
  • Make passwords strong and unique.
  • Use two-factor authentication, where possible: tokens (e.g., SecurPBX Agent or RSA SecurID8).
• Filter traffic between PSTN/gateways and PBX/IP network:
  • Telephony firewall
• Build separate DHCP servers:
  • One for voice (IP phones)
  • One for data (PCs)
• Disable automated phone registration:
  • Prevents rogue IP phones from grabbing a directory number from the IP PBX
• Monitor MAC addresses within voice segment.
• Filtering in all segments should limit devices in unknown segments from connecting to IP PBX.

The bottom line is:

• VoIP security is the users' responsibility.
• Vulnerabilities of voice and data systems carry over to the VoIP services.
• Risks as already shown are far too big to ignore.
• There are no single turnkey solutions.
• Your best approach is to implement security best practices with unique VoIP security measures.