Security Issues Involved in Moving Applications to a Network

With the availability of managed and hosted services deployment, more and more applications, including unified communications services and related applications, have moved into the network. Appropriate security measures need to be taken to protect application traffic and customers' endpoints, as well as service providers' infrastructure.

When a customer decides to use managed and hosted services, the customer’s application will move to a network. A good example is managed unified communications, in which the unified communications infrastructure is managed and hosted by a managed services provider (MSP). All data, voice and video packets traverse the MSP’s network or even the Internet, where threats such as the following can make services unavailable:

Eavesdropping: customer traffic should be protected using isolation and encryption to prevent unauthorized capture of traffic.

Malicious content: traffic should be filtered to prevent malicious traffic from damaging customer endpoints.

Threats to network resources: MSPs use systems such as Cisco Unified Communications Manager (CUCM), which provides IP telephony call processing. Call-processing servers and network infrastructure should be protected from malicious packets and denial-of-service (DoS) attacks, to ensure that the MSP can provide continuous service.

Service providers can offer several managed services, such as connectivity, security and unified communications. In this case, all services can collaborate and can be used in synergy at the same time. While the managed connectivity service offers connectivity from one customer site to another, and managed unified communications services offer unified communications infrastructure, managed security services could be used to protect packets transferred from one customer site to another over a service provider’s network. Customer traffic must be protected, regardless of whether the traffic consists of data, voice or video packets.

Security Issues for Customer Traffic

Just as with other types of TCP/IP traffic, it is easy to capture and sniff unencrypted voice packets and record conversations. This can be done by using popular sniffing tools such as Wireshark or Cain. Capturing wired IP traffic requires physical access to the wires, but it can be done in several ways. On your local network, on other networks with which you communicate, and all points between (including at the service provider), anyone can capture voice or video traffic. Capturing voice traffic in local networks is as easy as capturing any other kind of traffic. This can be done with Layer-2 attacks such as ARP spoofing, where an attacker can perform a man-in-the-middle attack and capture and/or replay all voice packets. To prevent such attacks, appropriate security measures should be taken for LAN switches on local networks. To protect traffic inside a customer’s LAN from internal threats (such as the previously mentioned ARP spoofing), the customer has to take care of security measures in his or her LAN environment. To ensure communications privacy and integrity, voice traffic has to be separated from data traffic. This can be done using the Voice VLAN feature on Cisco Catalyst switches. These switches offer also other security features, such as port security, DHCP snooping, dynamic ARP inspection and IP Source Guard.

Figure 1:

Capturing of voice traffic in local network

Capturing of voice packets over different IP networks is harder to perform, because an attacker has to introduce false routing information into a network to reroute traffic from one network to another, where it can be captured and replayed. To prevent the introduction of false routing information, routing protocol authentication and filtering of routing updates should be enabled for all known routing protocols.

Securing Customer Traffic by Using Isolation

The first layer of security that can be achieved by the service provider is isolating customer traffic, regardless whether this traffic consists of data, voice or video traffic. Customer traffic should be isolated from other traffic inside the MSP’s network. This can be done using one of the VPN technologies, such as Multiprotocol Label Switching (MPLS) VPN. MPLS VPN combines MPLS and Multiprotocol Border Gateway Protocol (MP-BGP) technologies to allow several sites to interconnect transparently through a service provider's network. One service provider network can support several different MPLS VPNs. Each of these networks appears to its users as a private network, separated from all other networks. However, isolation of customer traffic inside MPLS VPN relies solely on the lack of routing information inside one VPN on how to reach another one. Customer traffic is still sent over the network in unencrypted form, allowing attacker to capture and replay it.

The bottom line is that to achieve privacy, the customer must not rely only on traffic isolation. Traffic isolation should be combined with traffic encryption.

Figure 2:

Securing voice traffic using isolation with MPLS VPN

Securing Customer Traffic by Using Encryption and Authentication

The second layer of security that can be provided by MSPs is encryption and authentication of traffic. To encrypt and authenticate the signaling traffic used in voice applications, Cisco IP phones and CUCM support Transport Layer Security (TLS) encryption and authentication of Skinny Call Control Protocol (SCCP) and Session Initiation Protocol (SIP) signaling traffic. TLS is used to protect signaling messages by two-way certificate-based device authentication and Secure Hash Algorithm (SHA) Hash Message Authentication Code (HMAC) for packet authentication, as well as Advanced Encryption Standard (AES) for packet encryption.

To encrypt actual voice traffic between voice endpoints, Secure Real-time Transfer Protocol (SRTP) can be used. SRTP ensures the integrity of its RTP packets payload by providing authentication, integrity, and encryption of media packets between two voice endpoints. SRTP session keys (for authentication and media encryption) are generated by phones and exchanged in signaling messages via the CUCM. If the signaling messages are not protected, an attacker could easily learn the keys by sniffing the signaling messages. To ensure protection of the keys, CUCM requires signaling to be authenticated and encrypted with TLS.

Note:

SRTP cannot be used for packet authentication alone. It only supports simultaneous authentication and encryption.

Note:

CUCM supports two device security modes (and nonsecure device security mode):
- Authenticated: this mode provides authenticated signaling only (TLS SHA-1).
- Encrypted: this mode provides authenticated and encrypted signaling (TLS SHA-1 and TLS AES) and authenticated and encrypted voice data transfer (SRTP SHA-1 and SRTP AES).

If the MSP offers managed unified communications service, the MSP is responsible for enabling and configuring security features on call processing servers and voice endpoints.

Figure 3:

Securing voice traffic by using TLS and SRTP

Another solution for MSPs to protect customers’ signaling and voice traffic is by using IPsec VPN technology, which provides authentication, integrity and confidentiality of any IP traffic. However, IPsec cannot be established directly between endpoints, which are IP phones in the case of voice traffic. IPsec can be established between customer sites (between routers) to protect traffic over the service providers’ network. IPsec VPNs can be implemented in different ways:

GRE over IPsec: a limitation of IPsec is that you cannot run dynamic routing protocols over an IPsec tunnel. If you have more customer sites, and you want to use routing protocols to advertise routing information from one site to another over the service provider’s network, you have to use GRE over IPsec tunnels. In GRE over IPsec, customer traffic (including routing updates) is encapsulated inside the GRE header, and the GRE header is encrypted and encapsulated inside the ESP header. In this case, the customer uses overlay routing over the service provider’s network.

Figure 4:

Securing voice traffic using GRE over IPsec tunnels

Dynamic Multipoint VPN (DMVPN): when there are many customer sites in a hub-and-spoke topology, manual configuration and provisioning of manual GRE over IPsec tunnels can be overwhelming. In this case, DMVPN can be used, making the connection of multiple sites in a secure way relatively easy. In DMVPN, GRE over IPsec tunnels are manually configured only between spokes and hub. Spoke-to-spoke tunnels are built dynamically when one spoke has traffic to send to another spoke. In this case, as in GRE over IPSec, the customer uses overlay routing.

Figure 5:

Securing voice traffic using DMVPN

Note:

GRE over IPsec introduces up to 97 bytes of overhead when tunnel mode is used, and up to 77 bytes of overhead when transport mode is used. This additional overhead in IP packets increases the size of the original packet, resulting in higher bandwidth needs. The extra bandwidth can be critical for voice packets, which have high transmission rates and a small voice-packet size.

Group Encrypted Transport VPN (GET VPN): GET VPN is a next-generation WAN encryption technology that helps to ensure low latency and low jitter for voice, video and other latency-sensitive traffic, by enabling direct, “always on” communications between all customer sites. GET VPN introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members share a common security association, also known as a group security association. These security associations are created by the key server and are pushed down to all group members using the Group Domain of Interpretation (GDOI) protocol. This approach enables group members to decrypt traffic that was encrypted by any other group member. GET VPN usage is especially recommended on private WANs, such as MPLS VPNs, where overlay routing is not needed.

Figure 6:

Securing voice traffic using GET VPN

Note:

GET VPN uses IPsec in tunnel mode. However, GET VPN uses tunnel header preservation, which encapsulates data using the original source and destination addresses in the outer IP header to preserve original addresses. The biggest advantage of tunnel header preservation is the ability to route encrypted packets using the underlying network routing infrastructure.

Table 1:

Comparison of various IPsec solutions

As mentioned before, IPsec can be established between customer sites to protect data, voice and video traffic between the sites. If a customer uses managed unified communication services, IPsec can be established or maintained by the customer, or it can be outsourced to the same or another MSP that also offers managed security services; in this case, managed VPN.

Security Issues for MSP Network Resources

In the case where managed unified communications are also hosted, the MSP is responsible for taking care of its network devices as well as its call processing and application servers that are used by customers.

Securing Call Processing and Application Servers

Firewalls should be used in an MSP network and on customer sites to inspect packets and match them against configured rules. Cisco Adaptive Security Appliance (ASA) 5500 series firewalls can be used to protect all critical elements of unified communications, such as network infrastructure, call-control platforms, IP endpoints and unified communications applications, by using the following features:

Access control: this basic security function performed by the ASA appliance allows only authorized access to resources and services within a system. In a unified communications context, this control is often related to providing network layer access control to the Cisco Unified Communications Manager and other application servers as a first line of defense against attack. Restricting access to the Cisco Unified Communications Manager servers significantly reduces the risk of an attacker probing the system for vulnerabilities or exploiting access through unauthorized network channels.

Application inspection and control: protects unified communications network resources by stateful inspection of protocols used in unified communications, such as SIP, SCCP and RTP. These protocols are also checked for conformance to standards and are inspected to allow data sessions to flow from one network to another. Voice signaling traffic can be rate-limited to prevent DoS attacks, and maximum message lengths can be set to prevent buffer-overflow attacks on call processing servers.

Advanced TCP security engine: the advanced TCP security engine can protect call processing and applications servers from several attacks, including SYN flood attacks using SYNC cookies. This security engine delivers a smart TCP proxy feature that reassembles TCP packets to protect against segment attacks that use multiple TCP packets. The security engine offers TCP traffic-normalization services for additional techniques to detect attacks, including advanced flag and option checking, TCP packet checksum verification and detection of data tampering in retransmitted packets.

Intrusion prevention service: the optional Cisco ASA 5500 Series Advanced Intrusion Prevention Security Service Module (AIP SSM) applies intrusion prevention services to protect the unified communications infrastructure and call-control servers from IPS signature-based attacks. The module provides IPS services that are optimized for unified communications and that support specific unified communications engines such as the H.323 and H.225 inspection engines; it also helps to prevent OS attacks on call-control servers.

Limiting TCP and UDP connections: Cisco ASA can be configured to match specific traffic and then set to a maximum number of TCP, UDP and embryonic connections for all clients or for each client in the specified traffic class. This way, call processing and application servers can be protected from DoS attacks.

TLS proxy: addresses encrypted signaling and firewall integration concerns in situations in which encrypted signaling leaves unified communications firewalls unable to open ports or apply policies dynamically. As a trusted device within the CUCM system, the Cisco ASA appliance can intercept the encrypted signaling, mutually authenticate with the endpoint, and decrypt the signaling. After the signaling is decrypted, the appliance retrieves all the necessary signaling information and applies all the inspection and policy-enforcement actions. To maintain secure connectivity from end to end, the appliance then initiates a secondary TLS session back to CUCM. The signaling and communications between endpoint and CUCM remain functionally the same, and the firewall can deliver its unified communications security services. TLS proxy services support both SIP and SCCP endpoints.

To protect its endpoints and infrastructure, the customer can offload configuration and maintenance of firewalls to the MSP, which already offers managed unified communications and/or managed VPN services. In this case, the MSP also has to offer managed firewall services.

Figure 7:

Securing call processing server with firewall

Another important aspect of call processing server security is availability. The MSP can provide high availability by clustering several CUCM servers into a single entity. Cisco Unified Communications Manager clusters support load balancing and call-processing server redundancy. However, if the IP WAN connection goes down on one site, and CUCM is located at the other site, customers have to take care of intra-site call signaling. The Cisco Unified Survivable Remote Site Telephony (SRST) feature, available on Cisco IOS routers (voice gateways), provides call processing service to local IP phones during WAN outages. When the IP WAN is down, the IP phones register to the SRST router. The SRST router can then process calls between registered IP phones and send calls to other sites thorough the PSTN. If a customer uses managed unified communications services, the MSP is responsible for taking care of SRST-enabled routers.

Figure 8:

Call processing servers high availability

Note:

CUCM can be deployed using the following models: single-site, multisite with centralized call processing, multisite with distributed call processing and clustering over WAN.

Securing Network Devices

The service provider, which provides connectivity, unified communications and security services to customers, also has to take care of security issues that threaten network devices. To secure Cisco IOS routers, which are used in the service provider network and in customers’ networks to provide connectivity and other services (for example, the previously mentioned SRST), Cisco Network Foundation Protection (NFP) can be used. NFP protects infrastructure and provides continuous service delivery by securing the routers’ data, control and management plane.

The control plane can be protected by using the following features:

Control plane protection (CPPr): used to restrict and police traffic destined for the router’s control plane. CCPr provides a mechanism for early dropping of packets that are directed to a closed router’s TCP or UDP ports, and it provides QoS mechanisms for traffic destined for the router’s control plane.

Routing protocol protection: used to prevent introduction of false routing information into a network.

CPU and memory threshold notifications: the CPU threshold notification feature allows you to configure a CPU utilization threshold that, when crossed, triggers notifications. Memory threshold notifications can be configured to send notifications when available memory on a router falls below a configured threshold.

The management plane can also be protected:

Cisco Management Plane Protection (MPP): enables you to restrict the interface on which network management can enter the router. You can also specify allowed management protocols.

Securing Customer Endpoints

IP phones that reside at customer sites are targets for attacks, just like any other network components. Customers or providers (in the case of managed services) have to make sure that IP phones are hardened as well. There are several options for hardening IP phones and protecting them against various attacks and infiltration methods:

Enable signed phone loads: prevents falsification of phone images and configurations sent to phones from a TFTP server. Phone images are signed with the TFPT server’s private key, and the signature is appended to the image. The phones verify the signature by using the server’s public key, which has to be trusted by the phone.

Disable PC port: the PC port should be disabled when phones reside in special areas, such as a building lobby, where no additional PC access is allowed.

Disable settings access: restricts access to the IP phone settings, in order to avoid the risk of exposing details about the network infrastructure.

Disable gratuitous ARP (GARP): used to prevent man-in-the-middle attacks. With GARP disabled, phones ignore received GARP packets.

Disable PC voice VLAN access: by default, phones send all traffic (including voice traffic destined for the phone) to the PC over the PC port, where it can be sniffed. If you disable PC voice VLAN access, that phone will block voice VLAN on the PC port.

Disable Web Access: disable access to the IP phone from a web browser, to avoid the risk of exposing details about the network infrastructure.

Note:

The Private Key Infrastructure (PKI) topology in CUCM is not a single PKI system. Several certificate authorities (CAs) issue certificates, and phones may have to trust all of them. IP phones require a list of CAs that they should trust. The Cisco Certificate Trust List (CTL), which is downloaded to these phones, is used for that purpose.

Conclusion

As traffic leaves the trusted boundary of the customer site, security measures are necessary to protect that traffic. To secure unified communications traffic (which is just another type of IP traffic), use the same types of common security mechanisms that apply to any other IP traffic, as well as security measures that apply only to unified communications traffic. Remember that you also must protect the traffic inside the trusted boundary against the internal attacks. In this case, you can use security measures that apply to any IP traffic, or measures that specifically protect unified communications traffic.