Cisco Integrated Service Routers (ISRs) offer a scalable platform to address data and voice network requirements for a wide range of applications. Although the threat landscape of both private and Internet-connected networks is a very dynamic environment, Cisco IOS Firewall offers stateful inspection and Application Inspection and Control (AIC) capabilities to define and enforce a secure network posture, while enabling business capability and continuity.
This document describes design and configuration considerations for firewall security aspects of specific Cisco ISR-based data and voice application scenarios. Configuration for voice services and firewall are provided for each application scenario. Each scenario describes the VoIP and security configurations separately, followed by the entire router configuration. Your network may require other configuration for services such as QoS and VPN to maintain voice quality and confidentiality.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Cisco IOS Firewall is typically deployed in application scenarios that differ from appliance firewalls’ deployment models. Typical deployments include Teleworker applications, small- or branch-office sites, and retail applications, where low device count, integration of multiple services, and lower performance and security capability depth is desired.
While application of firewall inspection, along with other integrated services in the ISR products, might appear attractive from cost and operational perspective, specific considerations must be evaluated in order to determine if a router-based firewall is appropriate. Application of each additional feature incurs memory and processing costs and will likely contribute to reduced forwarding throughput rates, increased packet latency, and loss of feature capability during periods of peak load if an underpowered integrated router-based solution is deployed.
Follow these guidelines when you decide between a router and an appliance:
Routers with multiple integrated features enabled are best suited for branch-office or telecommuter sites where less devices offer a better solution.
High-bandwidth, high-performance applications are typically better addressed with appliances: Cisco ASA and Cisco Unified Call Manager Server should be applied to handle NAT and security policy application and call processing, while routers address QoS policy application, WAN termination, and site-to-site VPN connectivity requirements.
Prior to the introduction of Cisco IOS Software version 12.4(20)T, Classic Firewall and Zone-Based Policy Firewall (ZFW) was unable to fully support capabilities required for VoIP traffic and router-based voice services, requiring large openings in otherwise secure firewall policies to accommodate voice traffic, and offering limited support for evolving VoIP signaling and media protocols.
Cisco IOS Zone-Based Policy Firewall, similar to other firewalls, can only offer a secure firewall if the network’s security requirements are identified and described by security policy. There are two fundamental approaches to arrive at a security policy: the trusting perspective, as opposed to the suspicious perspective.
The trusting perspective assumes all traffic is trustworthy, except that which can be specifically identified as malicious or unwanted. A specific policy is implemented that denies only the unwanted traffic. This is typically accomplished through the use specific access-control entries, or signature- or behavior-based tools. This approach tends to interfere less with existing applications, but requires a comprehensive knowledge of the threat and vulnerability landscape, and requires constant vigilance to address new threats and exploits as they appear. Additionally, the user community must play a large part in maintaining adequate security. An environment that allows broad freedom with little control for the occupants offers substantial opportunity for problems caused by careless or malicious individuals. An additional problem of this approach is that it relies much more on effective management tools and application controls that offer sufficient flexibility and performance to be able to monitor and control suspect data in all network traffic. While technology is presently available to accommodate this, the operational burden frequently exceeds the limits of most organizations.
The suspicious perspective assumes all network traffic is undesired, except for specifically identified good traffic. A policy that is applied which denies all application traffic except that which is explicitly permitted. Additionally, application inspection and control (AIC) may be implemented to identify and deny malicious traffic that is specifically crafted to exploit ‘good’ applications, as well as unwanted traffic that is masquerading as good traffic. Again, application controls impose operational and performance burdens on the network, although most undesired traffic should be controlled by stateless filters such as access-control lists (ACLs) or Zone-Based Policy Firewall (ZFW) policy, so there should be substantially less traffic that must be handled by AIC, intrusion prevention system (IPS), or other signature-based controls such as flexible packet matching (FPM) or network-based application recognition (NBAR). Thus, if only desired application ports (and dynamic media-specific traffic arising from known control connections or sessions) are specifically permitted, the only unwanted traffic that should be present on the network should fall into a specific, more-easily-recognized subset, which reduces the engineering and operational burden imposed to maintain control over undesired traffic.
This document describes VoIP security configurations based on the suspicious perspective; thus, only traffic that is permissible in the voice-network segments is permitted. Data policies tend to be more permissive, as described by notes in each application scenario’s configuration.
All security policy deployments must follow a closed-loop feedback cycle; security deployments typically affect capability and functionality of existing applications and must be adjusted to minimize or resolve this impact.
For more information about how to configure the Zone-Based Policy Firewall, refer to Cisco IOS Firewall Zone-Based Policy Firewall Design and Application Guide.
The Cisco IOS Firewall Zone-Based Policy Firewall Design and Application Guide offers a brief discussion for securing the router with the use of security policies to and from the router’s self zone, as well as alternative capabilities that are provided through various Network Foundation Protection (NFP) features. Router-based VoIP capabilities are hosted within the router’s self zone, so security policies that protect the router must be aware of the requirements for voice traffic, in order to accommodate the voice signaling and media originated by and destined to Cisco Unified CallManager Express, Survivable Remote-Site Telephony, and Voice Gateway resources. Prior to Cisco IOS Software Version 12.4(20)T, Classic Firewall and Zone-Based Policy Firewall was unable to fully accommodate the requirements of VoIP traffic, so firewall policies were not optimized to fully protect resources. Self-zone security policies that protect router-based VoIP resources rely heavily on capabilities introduced in 12.4(20)T.
Cisco IOS Software Release 12.4(20)T introduced several enhancements to enable co-resident Zone Firewall and voice capabilities. Three main features apply directly to secure voice applications:
The router security configurations described in this document include capabilities offered by these enhancements, with explanation to describe the action applied by the policies. For complete details on the voice inspection features, refer to the individual feature documents listed in the Related Information