Downloads |
Table Of Contents
Prerequisites for VRF Aware Cisco IOS Firewall
Restrictions for VRF Aware Cisco IOS Firewall
Information About VRF Aware Cisco IOS Firewall
VRF Aware Cisco IOS Firewall Deployment
Distributed Network Inclusion of VRF Aware Cisco IOS Firewall
Hub-and-Spoke Network Inclusion of VRF Aware Cisco IOS Firewall
How to Configure VRF Aware Cisco IOS Firewall
Creating and Naming Firewall Rules and Applying the Rules to the Interface
Identifying and Setting Firewall Attributes
Verifying the VRF Aware Cisco IOS Firewall Configuration and Functioning
Configuration Examples for VRF Aware Cisco IOS Firewall
ip inspect max-incomplete high
ip inspect tcp max-incomplete host
VRF Aware Cisco IOS Firewall
VRF Aware Cisco IOS Firewall applies Cisco IOS Firewall functionality to VRF (Virtual Routing and Forwarding) interfaces when the firewall is configured on a service provider (SP) or large enterprise edge router. SPs can provide managed services to small and medium business markets.
The VRF Aware Cisco IOS Firewall supports VRF-aware URL filtering and VRF-lite (also known as Multi-VRF CE).
Feature History for VRF Aware Cisco IOS Firewall
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for VRF Aware Cisco IOS Firewall
•
•
•
•
Prerequisites for VRF Aware Cisco IOS Firewall
•
•
•
Restrictions for VRF Aware Cisco IOS Firewall
•
•
•
Information About VRF Aware Cisco IOS Firewall
To configure VRF Aware Cisco IOS Firewall, you need to understand the following concepts:
•
•
Cisco IOS Firewall
The Cisco IOS Firewall provides robust, integrated firewall and intrusion detection functionality for every perimeter of the network. Available for a wide range of Cisco IOS software-based routers, the Cisco IOS Firewall offers sophisticated security and policy enforcement for connections within an organization (intranet) and between partner networks (extranets), as well as for securing Internet connectivity for remote and branch offices.
The Cisco IOS Firewall enhances existing Cisco IOS security capabilities such as authentication, encryption, and failover, with state-of-the-art security features such as stateful, application-based filtering (context-based access control), defense against network attacks, per-user authentication and authorization, and real-time alerts.
The Cisco IOS Firewall is configurable via Cisco ConfigMaker software, an easy-to-use Microsoft Windows 95, Windows 98, NT 4.0 based software tool.
The Cisco IOS Firewall provides great value in addition to these benefits:
•
•
•
•
The VRF Aware Cisco IOS Firewall is different from the non-VRF Aware Firewall because it does the following:
•
•
•
•
•
•
Both VFR Aware and non-VFR Aware Firewalls now allow you to limit the number of firewall sessions. Otherwise, it would be difficult for VRFs to share router resources because one VRF may consume a maximum amount of resources, leaving few resources for other VRFs. That would cause the denial of service to other VRFs. To limit the number of sessions, enter the ip inspect name command.
VRF
VPN Routing and Forwarding (VRF) is an IOS route table instance for connecting a set of sites to a VPN service. A VRF contains a template of a VPN Routing/Forwarding table in a PE router.
The overlapping addresses, usually resulting from the use of private IP addresses in customer networks, are one of the major obstacles to successful deployment of peer-to-peer VPN implementation. The MPLS VPN technology provides a solution to this dilemma.
Each VPN has its own routing and forwarding table in the router, so any customer or site that belongs to a VPN is provided access only to the set of routes contained within that table. Any PE router in the MPLS VPN network therefore contains a number of per-VPN routing tables and a global routing table that is used to reach other routers in the service provider network. Effectively, a number of virtual routers are created in a single physical router.
VRF-lite
VRF-lite is a feature that enables a service provider to support two or more VPNs, where IP addresses can be overlapped among the VPNs. VRF-lite uses input interfaces to distinguish routes for different VPNs and forms virtual packet-forwarding tables by associating one or more Layer 3 interfaces with each VRF. Interfaces in a VRF can be physical, such as Ethernet ports, or logical, such as VLAN switched virtual interfaces (SVIs). However, a Layer 3 interface cannot belong to more than one VRF at a time.
Note
VRF-lite includes these devices:
•
•
•
•
With VRF-lite, multiple customers can share one CE, and only one physical link is used between the CE and the PE. The shared CE maintains separate VRF tables for each customer, and switches or routes packets for each customer based on its own routing table. VRF-lite extends limited PE functionality to a CE device, giving it the ability to maintain separate VRF tables to extend the privacy and security of a VPN to the branch office.
In a VRF-to-VRF situation, if firewall policies are applied on both inbound and outbound interfaces as shown in Figure 1, the firewall on the inbound interface takes precedence over the firewall on the outbound interface. If the incoming packets do not match against the firewall rules (that is, the inspection protocols) configured on the inbound interface, the firewall rule on the outbound interface is applied to the packet.
Figure 1 Firewall in a VRF-to-VRF Scenario
Per-VRF URL Filtering
The VRF Aware firewall supports per-VRF URL filtering. Each VPN can have its own URL filter server. The URL filter server typically is placed in the Shared Service segment of the corresponding VPN. (Each VPN has a VLAN segment in the Shared Service network.) It can also be placed at the customer's site.
Alerts and Audit Trails
CBAC generates real-time alerts and audit trails based on events tracked by the firewall. Enhanced audit trail features use SYSLOG to track all network transactions; recording time stamps, the source host, the destination host, ports used, and the total number of transmitted bytes, for advanced, session-based reporting. Real-time alerts send SYSLOG error messages to central management consoles upon detecting suspicious activity. Using CBAC inspection rules, you can configure alerts and audit trail information on a per-application protocol basis. For example, if you want to generate audit trail information for HTTP traffic, you can specify that in the CBAC rule covering HTTP inspection.
MPLS VPN
When used with MPLS, the VPN feature allows several sites to interconnect transparently through a service provider's network. One service provider network can support several IP VPNs. Each VPN appears to its users as a private network, separate from all other networks. Within a VPN, each site can send IP packets to any other site in the same VPN.
Each VPN is associated with one or more VPN VRF instances. A VRF consists of an IP routing table, a derived Cisco express forwarding (CEF) table, and a set of interfaces that use the forwarding table.
The router maintains a separate routing and CEF table for each VRF. This prevents information from being sent outside the VPN and allows the same subnet to be used in several VPNs without causing duplicate IP address problems.
The router using Multiprotocol BGP (MP-BGP) distributes the VPN routing information using the MP-BGP extended communities.
VRF-aware NAT
Network Address Translation (NAT) allows a single device, such as a router, to act as an agent between the Internet (or public network) and a local (or private) network. Although NAT systems can provide broad levels of security advantages, their main objective is to economize on address space.
NAT allows organizations to resolve the problem of IP address depletion when they have existing networks and need to access the Internet. Sites that do not yet possess NIC-registered IP addresses must acquire them. Cisco IOS NAT eliminates concern and bureaucratic delay by dynamically mapping thousands of hidden internal addresses to a range of easy-to-get addresses.
In general, a NAT system makes it more difficult for an attacker to determine the following:
•
•
•
NAT integration with MPLS VPNs allows multiple MPLS VPNs to be configured on a single device to work together. NAT can differentiate which MPLS VPN it receives IP traffic from even if the MPLS VPNS are all using the same IP addressing scheme. This enables multiple MPLS VPN customers to share services while ensuring that each MPLS VPN is completely separate from the other.
MPLS service providers would like to provide value-added services such as Internet connectivity, domain name servers (DNS), and VoIP service to their customers. This requires that their customers IP addresses be different when reaching the services. Because MPLS VPN allows customers to use overlapped IP addresses in their networks, NAT must be implemented to make the services possible.
There are two approaches to implementing NAT in the MPLS VPN network. NAT can be implemented on the CE router, which is already supported by NAT, or it can be implemented on a PE router. The NAT Integration with MPLS VPNs feature enables the implementation of NAT on a PE router in an MPLS cloud.
VRF-aware IPSec
The VRF-aware IPSec feature maps an IP Security (IPSec) tunnel to an MPLS VPN. Using the VRF-aware IPSec feature, you can map IPSec tunnels to VRF instances using a single public-facing address.
Each IPSec tunnel is associated with two VRF domains. The outer encapsulated packet belongs to a VRF domain called the Front Door VRF (FVRF). The inner, protected IP packet belongs to a domain called the Inside VRF (IVRF). In other words, the local endpoint of the IPSec tunnel belongs to the FVRF, whereas the source and destination addresses of the inside packet belong to the IVRF.
One or more IPSec tunnels can terminate on a single interface. The FVRF of all these tunnels is the same and is set to the VRF that is configured on that interface. The IVRF of these tunnels can be different and depends on the VRF that is defined in the Internet Security Association and Key Management Protocol (ISAKMP) profile that is attached to a crypto map entry.
Figure 2 illustrates a scenario showing IPSec to MPLS and Layer 2 VPNs.
Figure 2 IPSec-to-MPLS and Layer 2 VPNs
VRF Aware Cisco IOS Firewall Deployment
A firewall can be deployed at many points within the network to protect VPN sites from Shared Service (or the Internet) and vice versa. The following firewall deployments are described:
•
•
Distributed Network Inclusion of VRF Aware Cisco IOS Firewall
A VRF Aware Cisco IOS Firewall in a distributed network has the following advantages:
•
•
•
However, the following disadvantages exist:
•
•
•
Figure 3 illustrates a typical situation in which an SP offers firewall services to VPN customers VPN1 and VPN2, thereby protecting VPN sites from the external network (for example, Shared Services and the Internet) and vice versa.
Figure 3 Distributed Network
In this example, VPN1 has two sites, Site A and Site B, that span across the MPLS core. Site A is connected to PE1, and Site B is connected to PE2. VPN2 has only one site that is connected to PE2.
Each VPN (VPN1 and VPN2) has the following:
•
•
A distributed network requires the following firewall policies:
•
•
•
•
Hub-and-Spoke Network Inclusion of VRF Aware Cisco IOS Firewall
Figure 4 illustrates a hub-and-spoke network where the firewalls for all VPN sites are applied on the egress PE router PE3 that is connected to the Shared Service.
Figure 4 Hub-and-Spoke Network
Typically each VPN has a VLAN and/or VRF subinterface connected to the Shared Service. When a packet arrives from an MPLS interface, the inner tag represents the VPN-ID. MPLS routes the packet to the corresponding subinterface that is connected to Shared Service.
A Hub-and-Spoke network requires the following firewall policies:
•
•
•
•
How to Configure VRF Aware Cisco IOS Firewall
This section contains the following procedures:
•
•
Configuring and Checking ACLs to Ensure that Only Inspected Traffic Can Pass Through the Firewall and that Non-Firewall Traffic is Blocked
To configure ACLs and verify that only inspected traffic can pass through the firewall, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Creating and Naming Firewall Rules and Applying the Rules to the Interface
To create and name firewall rules and apply the rules to the interface, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Identifying and Setting Firewall Attributes
To identify and set firewall attributes, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Verifying the VRF Aware Cisco IOS Firewall Configuration and Functioning
Verify the configuration and functioning of the firewall by entering the commands shown below. For detailed descriptions of these commands and other verification commands, see the "Command Reference" section.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Step 1
Use this command to view the firewall configurations, sessions, statistics, and so forth, pertaining to a specified VRF. For example, to view the firewall sessions pertaining to the VRF bank, enter the following command:
Router# show ip inspect interfaces vrf bankStep 2
Use this command to view the configurations, cache entries, statistics, and so forth, pertaining to a specified VRF. For example, to view the URL filtering statistics pertaining to the VRF bank, enter the following command:
Router# show ip urlfilter statistics vrf bank
Configuration Examples for VRF Aware Cisco IOS Firewall
In the example illustrated in Figure 5, a service provider offers firewall service to VPN customers Bank and Shop. The Bank VPN has the following two sites in an MPLS network:
•
•
The Bank VPN also has a VLAN network segment in Shared Service that is connected to PE3.
The Shop VPN has only one site, which is connected to PE4. The network address 10.10.1.0/24 is the same network address to which the Bank VPN site is connected.
Figure 5 VPN with Two Sites Across MPLS Network
Each VPN needs the following two firewalls:
•
•
In addition, the following two firewalls are required:
•
•
In this example, the security policies for Bank and Shop VPNs are as follows:
•
•
•
•
The security policies for the Internet firewall and generic VPN firewall are as follows:
•
•
DISTRIBUTED NETWORK
PE1:
! VRF instance for the Bank VPNip vrf bankrd 100:10route-target export 100:10route-target import 100:10!! VPN Firewall for Bank VPN protects Bank VPN from Shared Serviceip inspect name bank_vpn_fw ftpip inspect name bank_vpn_fw httpip inspect name bank_vpn_fw esmtp!! Shared Service firewall for Bank VPN protects Shared Service from Bank VPNip inspect name bank_ss_fw esmtp!! VRF interface for the Bank VPNinterface ethernet0/1.10!! description of VPN site Bank to PE1encapsulation dot1Q 10ip vrf forwarding bankip address 10.10.1.2 255.255.255.0ip access-group bank_ss_acl inip access-group bank_vpn_acl outip inspect bank_vpn_fw inip inspect bank_ss_fw out!! MPLS interfaceinterface Serial3/0ip unnumbered Loopback0tag-switching ipserial restart-delay 0!! ACL that protects the VPN site Bank from Shared Serviceip access-list extended bank_vpn_aclpermit ip 10.10.2.0 0.0.0.255 10.10.1.0 0.0.0.255permit tcp any any eq smtpdeny ip any any log!! ACL that protects Shared Service from VPN site Bankip access-list extended bank_ss_aclpermit ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255permit tcp any any eq ftppermit tcp any any eq httppermit tcp any any eq smtpdeny ip any any logPE2:
! VRF instance for the Bank VPNip vrf bankrd 100:10route-target export 100:10route-target import 100:10!! VRF instance for the Shop VPNip vrf shoprd 200:20route-target export 200:20route-target import 200:20!! VPN firewall for Bank BPN protects Bank VPN from Shared Serviceip inspect name bank_vpn_fw ftpip inspect name bank_vpn_fw httpip inspect name bank_vpn_fw esmtp!! Shared Service firewall for Bank VPN protects Shared Service from Bank VPNip inspect name bank_ss_fw esmtp!! VPN firewall for Shop VPN protects Shop VPN from Shared Serviceip inspect name shop_vpn_fw httpip inspect name shop_vpn_fw rtsp!! Shared Service firewall for Shop VPN protects Shared Service from Shop VPNip inspect name shop_ss_fw h323!! VRF interface for the Bank VPNinterface Ethernet3/1.10!! description of VPN site Bank to PE2encapsulation dot1Q 10ip vrf forwarding bankip address 10.10.2.2 255.255.255.0ip access-group bank_ss_acl inip access-group bank_vpn_acl outip inspect bank_vpn_fw inip inspect bank_ss_fw out!interface Ethernet3/1.20!! description of VPN site Shop to PE2encapsulation dot1Q 20ip vrf forwarding shopip address 10.10.1.2 255.255.255.0ip access-group shop_ss_acl inip access-group shop_vpn_acl outip inspect shop_vpn_fw inip inspect shop_ss_fw out!interface Serial4/0ip unnumbered Loopback0tag-switching ipserial restart-delay 0!! ACL that protects the VPN site Bank from Shared Serviceip access-list extended bank_vpn_aclpermit ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255permit tcp any any eq smtpdeny ip any any log!! ACL that protects Shared Service from VPN site Bankip access-list extended bank_ss_aclpermit ip 10.10.2.0 0.0.0.255 10.10.1.0 0.0.0.255permit tcp any any eq ftppermit tcp any any eq httppermit tcp any any eq smtpdeny ip any any log!! ACL that protects VPN site Shop from Shared Serviceip access-list extended shop_vpn_aclpermit tcp any any eq h323deny ip any any log!ip access-list extended shop_ss_aclpermit tcp any any eq httppermit tcp any any eq rtspdeny ip any any logPE3:
! VRF instance for the Bank VPNip vrf bankrd 100:10route-target export 100:10route-target import 100:10!! VRF instance for the Shop VPNip vrf shoprd 200:20route-target export 200:20route-target import 200:20!! Generic VPN firewall to protect Shop and Bank VPNs from internetip inspect name gen_vpn_fw esmtpip inspect name gen_vpn_fw ftpip inspect name gen_vpn_fw httpip inspect name gen_vpn_fw rtsp!! Internet firewall to prevent malicious traffic from being passed! to internet from Bank and Shop VPNsip inspect name inet_fw esmtpip inspect name inet_fw http!! VRF interface for the Bank VPNinterface Ethernet1/1.10!! Description of Shared Service to PE3encapsulation dot1Q 10ip vrf forwarding bankip address 10.10.1.50 255.255.255.0!! VRF interface for the Shop VPNinterface Ethernet1/1.20!! Description of Shared Service to PE3encapsulation dot1Q 20ip vrf forwarding shopip address 10.10.1.50 255.255.255.0!interface Serial2/0ip unnumbered Loopback0tag-switching ipserial restart-delay 0!! VRF interface for the Bank VPNinterface Serial3/0!! Description of Internet-facing interfaceip address 192.168.10.2 255.255.255.0ip access-group inet_acl outip access-group gen_vpn_acl inip inspect gen_vpn_fw outip inspect inet_fw in!! ACL that protects the Bank and Shop VPNs from internetip access-list extended gen_vpn_aclpermit tcp any any eq smtppermit tcp any any eq wwwdeny ip any any log!! ACL that protects internet from Bank and Shop VPNsip access-list extended inet_aclpermit tcp any any eq ftppermit tcp any any eq httppermit tcp any any eq smtppermit tcp any any eq rtspdeny ip any any logHUB-AND-SPOKE NETWORK
PE3:
! VRF instance for the VPN Bankip vrf bankrd 100:10route-target export 100:10route-target import 100:10!! VRF instance for the VPN Shopip vrf shoprd 200:20route-target export 200:20route-target import 200:20!! VPN firewall for Bank BPN protects Bank VPN from Shared Serviceip inspect name bank_vpn_fw ftpip inspect name bank_vpn_fw httpip inspect name bank_vpn_fw esmtp!! Shared Service firewall for Bank VPN protects Shared Service from Bank VPNip inspect name bank_ss_fw esmtp!! VPN firewall for Shop VPN protects Shop VPN from Shared Serviceip inspect name shop_vpn_fw httpip inspect name shop_vpn_fw rtsp!! Shared Service firewall for Shop VPN protects Shared Service from Shop VPNip inspect name shop_ss_fw h323!! Generic VPN firewall protects Shop and Bank VPNs from internetip inspect name gen_vpn_fw esmtpip inspect name gen_vpn_fw ftpip inspect name gen_vpn_fw httpip inspect name gen_vpn_fw rtsp!! Internet firewall prevents malicious traffic from being passed! to internet from Bank and Shop VPNsip inspect name inet_fw esmtpip inspect name inet_fw http!! VRF interface for the Bank VPNinterface Ethernet1/1.10!! description of Shared Service to PE3encapsulation dot1Q 10ip vrf forwarding bankip address 10.10.1.50 255.255.255.0ip access-group bank_ss_acl outip access-group bank_vpn_acl inip inspect bank_vpn_fw outip inspect bank_ss_fw in!! VRF interface for the Shop VPNinterface Ethernet1/1.20!! description of Shared Service to PE3encapsulation dot1Q 20ip vrf forwarding shopip address 10.10.1.50 255.255.255.0ip access-group shop_ss_acl outip access-group shop_vpn_acl inip inspect shop_vpn_fw outip inspect shop_ss_fw in!interface Serial2/0ip unnumbered Loopback0tag-switching ipserial restart-delay 0!! VRF interface for the Bank VPNinterface Serial3/0!! description of Internet-facing interfaceip address 192.168.10.2 255.255.255.0ip access-group inet_acl outip access-group gen_vpn_acl inip inspect gen_vpn_fw outip inspect inet_fw in!! ACL that protects the VPN site Bank from Shared Serviceip access-list extended bank_vpn_aclpermit tcp any any eq smtpdeny ip any any log!! ACL that protects Shared Service from VPN site Bankip access-list extended bank_ss_aclpermit tcp any any eq ftppermit tcp any any eq httppermit tcp any any eq smtpdeny ip any any log!! ACL that protects VPN site Shop from Shared Serviceip access-list extended shop_vpn_aclpermit tcp any any eq h323deny ip any any log!ip access-list extended shop_ss_aclpermit tcp any any eq httppermit tcp any any eq rtspdeny ip any any log!! ACL that protects the Bank and Shop VPNs from internetip access-list extended gen_vpn_aclpermit tcp any any eq smtppermit tcp any any eq wwwdeny ip any any log!! ACL that protects internet from Bank and Shop VPNsip access-list extended inet_aclpermit tcp any any eq ftppermit tcp any any eq httppermit tcp any any eq smtppermit tcp any any eq rtspdeny ip any any logIn the example illustrated in Figure 6, the Cisco IOS Firewall is configured on PE1 on the VRF interface E3/1. The host on NET1 wants to reach the server on NET2.
Figure 6 Sample VRF Aware Cisco IOS Firewall Network
The configuration steps are followed by a sample configuration and log messages.
1.
2.
3.
4.
a.
b.
5.
VRF Configuration on PE1
! configure VRF for host1ip cefip vrf vrf1rd 100:1route-target export 100:1route-target import 100:1exitend!! apply VRF to the interface facing CEinterface ethernet3/1ip vrf forwarding vrf1ip address 190.1.1.2 255.255.0.0!! make the interface facing the MPLS network an MPLS interfaceinterface serial2/0mpls ipip address 191.171.151.1 255.255.0.0!! configure BGP protocol for MPLS networkrouter bgp 100no synchronizationbgp log-neighbor-changesneighbor 191.171.151.2 remote-as 100neighbor 191.171.151.2 update-source serial2/0no auto-summaryaddress-family vpnv4neighbor 191.171.151.2 activateneighbor 191.171.151.2 send-community bothexit-address-familyaddress-family ipv4 vrf vrf1redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-family!! configure VRF static route to reach CE networkip route vrf vrf1 192.168.4.0 255.255.255.0 190.1.1.1VRF Configuration on PE2
! configure VRF for host2ip cefip vrf vrf1rd 100:1route-target export 100:1route-target import 100:1!! apply VRF on CE-facing interfaceinterface fastethernet0/0ip vrf forwarding vrf1ip address 193.1.1.2 255.255.255.0!! make MPLS network-facing interface an MPLS interfaceinterface serial1/0mpls ipip address 191.171.151.2 255.255.0.0!! configure BGP protocol for MPLS networkrouter bgp 100no synchronizationbgp log-neighbor-changesneighbor 191.171.151.1 remote-as 100neighbor 191.171.151.1 update-source serial1/0no auto-summaryaddress-family vpnv4neighbor 191.171.151.1 activateneighbor 191.171.151.1 send-community bothexit-address-familyaddress-family ipv4 vrf vrf1redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-family!configure VRF static route to reach CE networkip route vrf vrf1 192.168.4.0 255.255.255.0 193.1.1.1Configuration on CE1
interface e0/1ip address 190.1.1.1 255.255.255.0interface e0/0ip address 192.168.4.2 255.255.255.0ip route 192.168.104.0 255.255.255.0 190.1.1.2Configuration on CE2
interface e0/1ip address 190.1.1.1 255.255.255.0interface e0/0ip address 192.168.4.2 255.255.255.0ip route 192.168.4.0 255.255.255.0 193.1.1.2Configure Firewall on PE1 and Apply on the VRF Interface
! configure ACL so that NET2 cannot access NET1ip access-list extended 105permit tcp any any fragmentpermit udp any any fragmentdeny tcp any anydeny udp any anypermit ip any any!! apply ACL to VRF interface on PE1interface ethernet3/1ip access-group 105 out!! configure firewall ruleip inspect name test tcp!! apply firewall rule on VRF interfaceinterface ethernet3/1ip inspect test inCheck for VRF Firewall Sessions When Host on NET1 Tries to Telnet to Server on NET2
show ip inspect session vrf vrf1Established SessionsSession 659CE534 (192.168.4.1:38772)=>(192.168.104.1:23) tcp SIS_OPEN!! checking for ACLsshow ip inspect session detail vrf vrf1 | include ACL 105Out SID 192.168.104.1[23:23]=>192.168.4.1[38772:38772] on ACL 105(34 matches)Additional References
The following sections provide references related to VRF Aware Cisco IOS Firewall.
Related Documents
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Command Reference
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.3 command reference publications.
•
•
•
•
•
clear ip urlfilter cache
To clear the cache table, use the clear ip urlfilter cache command in user EXEC mode.
clear ip urlfilter cache {ip-address | all} [vrf vrf-name]
Syntax Description
Command Modes
User EXEC
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
The cache table consists of the most recently requested IP addresses and the respective authorization status for each IP address.
Examples
The following example shows how to clear the cache table of IP address 172.18.139.21:
clear ip urlfilter cache 172.18.139.21The following example shows how to clear the cache table of all IP addresses:
clear ip urlfilter cache allThe following example shows how to clear the cache table of all IP addresses in the vrf named bank.
clear ip urlfilter cache all vrf bankRelated Commands
ip urlfilter cache
Configures cache parameters.
show ip urlfilter cache
Displays the destination IP addresses that are cached into the cache table.
ip inspect alert-off
To disable Context-based Access Control (CBAC) alert messages, which are displayed on the console, use the ip inspect alert-off command in global configuration mode. To enable CBAC alert messages, use the no form of this command.
ip inspect alert-off [vrf vrf-name]
no ip inspect alert-off [vrf vrf-name]
Syntax Description
vrf vrf-name
(Optional) Disables CBAC alert messages only for the specified Virtual Routing and Forwarding (VRF) interface.
Defaults
Alert messages are displayed.
Command Modes
Global configuration
Command History
12.0(5)T
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Examples
The following example turns on CBAC alert messages:
ip inspect alert-offip inspect audit trail
To turn on Context-based Access Control (CBAC) audit trail messages, which will be displayed on the console after each CBAC session closes, use the ip inspect audit trail command in global configuration mode. To turn off CBAC audit trail messages, use the no form of this command.
ip inspect audit trail [vrf vrf-name]
no ip inspect audit trail [vrf vrf-name]
Syntax Description
vrf vrf-name
(Optional) Turns on CBAC audit trail messages only for the specified Virtual Routing and Forwarding (VRF) interface.
Defaults
Audit trail messages are not displayed.
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
Use this command to turn on CBAC audit trail messages.
Examples
The following example turns on CBAC audit trail messages:
ip inspect audit trailAfterward, audit trail messages such as the following are displayed. These messages are examples of audit trail messages. To determine which protocol was inspected, refer to the responder's port number. The port number follows the responder's IP address.
%FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.1.13:33192) sent 22 bytes -- responder (192.168.129.11:25) sent 208 bytes%FW-6-SESS_AUDIT_TRAIL: ftp session initiator 192.168.1.13:33194) sent 336 bytes -- responder (192.168.129.11:21) sent 325 bytesThe following example disables CBAC alert messages for VRF interface vrf1:
ip inspect audit-trail vrf vrf1Following are examples of audit trail messages:
00:10:15: %FW-6-SESS_AUDIT_TRAIL: VRF-vrf1:Stop udp session: initiator (192.168.14.1:40801) sent 54 bytes -- responder (192.168.114.1:7) sent 54 bytes 00:10:47: %FW-6-SESS_AUDIT_TRAIL: VRF-vrf1:Stop ftp-data session: initiator (192.168.114.1:20) sent 80000 bytes -- responder (192.168.14.1:38766) sent 0 bytes 00:10:47: %FW-6-SESS_AUDIT_TRAIL: VRF-vrf1:Stop ftp session: initiator (192.168.14.1:38765) sent 80 bytes -- responder (192.168.114.1:21) sent 265 bytes 00:10:57: %FW-6-SESS_AUDIT_TRAIL: VRF-vrf1:Stop rcmd session: initiator (192.168.14.1:531) sent 31 bytes -- responder (192.168.114.1:514) sent 12 bytes 00:10:57: %FW-6-SESS_AUDIT_TRAIL: VRF-vrf1:Stop rcmd-data session: initiator (192.168.114.1:594) sent 0 bytes -- responder (192.168.14.1:530) sent 0 bytesip inspect dns-timeout
To specify the Domain Name System (DNS) idle timeout (the length of time during which a DNS name lookup session will still be managed while there is no activity), use the ip inspect dns-timeout command in global configuration mode. To reset the timeout to the default of 5 seconds, use the no form of this command.
ip inspect dns-timeout seconds [vrf vrf-name]
no ip inspect dns-timeout seconds [vrf vrf-name]
Syntax Description
Defaults
5 seconds
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
When the software detects a valid User Datagram Protocol (UDP) packet for a new DNS name lookup session, if Context-based Access Control (CBAC) inspection is configured for UDP, the software establishes state information for the new DNS session.
If the software detects no packets for the DNS session for a time period defined by the DNS idle timeout, the software will not continue to manage state information for the session.
The DNS idle timeout applies to all DNS name lookup sessions inspected by CBAC.
The DNS idle timeout value overrides the global UDP timeout. The DNS idle timeout value also enters aggressive mode and overrides any timeouts specified for specific interfaces when you define a set of inspection rules with the ip inspect name command.
Examples
The following example sets the DNS idle timeout to 30 seconds:
ip inspect dns-timeout 30The following example sets the DNS idle timeout back to the default (5 seconds):
no ip inspect dns-timeoutip inspect max-incomplete high
To define the number of existing half-open sessions that will cause the software to start deleting half-open sessions, use the ip inspect max-incomplete high command in global configuration mode. To reset the threshold to the default of 500 half-open sessions, use the no form of this command.
ip inspect max-incomplete high number [vrf vrf-name]
no ip inspect max-incomplete high
Syntax Description
Defaults
500 half-open sessions
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
An unusually high number of half-open sessions (either absolute or measured as the arrival rate) could indicate that a denial-of-service attack is occurring. For TCP, "half-open" means that the session has not reached the established state. For User Datagram Protocol, "half-open" means that the firewall has detected traffic from one direction only.
Context-based Access Control (CBAC) measures both the total number of existing half-open sessions and the rate of session establishment attempts. Both TCP and UDP half-open sessions are counted in the total number and rate measurements. Measurements are made once a minute.
When the number of existing half-open sessions rises above a threshold (the max-incomplete high number), the software will delete half-open sessions as required to accommodate new connection requests. The software will continue to delete half-open requests as necessary, until the number of existing half-open sessions drops below another threshold (the max-incomplete low number).
The global value specified for this threshold applies to all TCP and UDP connections inspected by CBAC.
Examples
The following example causes the software to start deleting half-open sessions when the number of existing half-open sessions rises above 900, and to stop deleting half-open sessions when the number drops below 800:
ip inspect max-incomplete high 900ip inspect max-incomplete low 800The following example shows an ALERT_ON message generated for the ip inspect max-incomplete high command:
ip inspect max-incomplete high 20 vrf vrf1show log / include ALERT_ON00:59:00:%FW-4-ALERT_ON: VRF-vrf1:getting aggressive, count (21/20) current 1-min rate: 21Related Commands
ip inspect max-incomplete low
To define the number of existing half-open sessions that will cause the software to stop deleting half-open sessions, use the ip inspect max-incomplete low command in global configuration mode. To reset the threshold to the default of 400 half-open sessions, use the no form of this command.
ip inspect max-incomplete low number [vrf vrf-name]
no ip inspect max-incomplete low
Syntax Description
Defaults
400 half-open sessions
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
An unusually high number of half-open sessions (either absolute or measured as the arrival rate) could indicate that a denial-of-service attack is occurring. For TCP, "half-open" means that the session has not reached the established state. For User Datagram Protocol (UDP), "half-open" means that the firewall has detected traffic from one direction only.
Context-based Access Control (CBAC) measures both the total number of existing half-open sessions and the rate of session establishment attempts. Both TCP and UDP half-open sessions are counted in the total number and rate measurements. Measurements are made once a minute.
When the number of existing half-open sessions rises above a threshold (the max-incomplete high number), the software will delete half-open sessions as required to accommodate new connection requests. The software will continue to delete half-open requests as necessary, until the number of existing half-open sessions drops below another threshold (the max-incomplete low number).
The global value specified for this threshold applies to all TCP and UDP connections inspected by CBAC.
Examples
The following example causes the software to start deleting half-open sessions when the number of existing half-open sessions rises above 900, and to stop deleting half-open sessions when the number drops below 800:
ip inspect max-incomplete high 900ip inspect max-incomplete low 800The following example shows an ALERT_OFF message generated for the ip inspect max-incomplete low command:
ip inspect max-incomplete low 10 vrf vrf1show log / include ALERT_OFF00:59:31: %FW-4-ALERT_OFF: VRF-vrf1:calming down, count (9/10) current 1-min rate: 100Related Commands
ip inspect name
To define a set of inspection rules, use the ip inspect name command in global configuration mode. To remove the inspection rule for a protocol or to remove the entire set of inspection rules, use the no form of this command.
ip inspect name inspection-name [parameter max-sessions number] protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
no ip inspect name inspection-name [parameter max-sessions number] protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
HTTP Inspection Syntax
ip inspect name inspection-name http [urlfilter] [java-list access-list] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
no ip inspect name inspection-name protocol
SMTP and ESMTP Inspection Syntax
ip inspect name inspection-name {smtp | esmtp} [alert {on | off}] [audit-trail {on | off}] [max-data number] [timeout seconds]
remote-procedure call (RPC) Inspection Syntax
ip inspect name inspection-name [parameter max-sessions number] rpc program-number number [wait-time minutes] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
no ip inspect name inspection-name protocol
POP3/IMAP Inspection Syntax
ip inspect name inspection-name imap [alert {on | off}] [audit-trail {on | off}] [reset] [secure-login] [timeout number]
ip inspect name inspection-name pop3 [alert {on | off}] [audit-trail {on | off}] [reset] [secure-login] [timeout number]
Fragment Inspection Syntax
ip inspect name inspection-name [parameter max-sessions number] fragment [max number timeout seconds]
no ip inspect name inspection-name [parameter max-sessions number] fragment [max number timeout seconds]
Application Firewall Provisioning Syntax
ip inspect name inspection-name [parameter max-sessions number] appfw policy-name
no ip inspect name inspection-name [parameter max-sessions number] appfw policy-name
User-Defined Application Syntax
ip inspect name inspection-name user-10 [alert {on | off}] [audit-trail {on | off}] [timeout seconds}
no ip inspect name inspection-name user-10 [alert {on | off}] [audit-trail {on | off}] [timeout seconds}
Session Limiting Syntax
no ip inspect name inspection-name [parameter max-sessions number]
Syntax Description
inspection-name
Names the set of inspection rules. If you want to add a protocol to an existing set of rules, use the same inspection-name as the existing set of rules.
Note
parameter
max-sessions number(Optional) Limits the number of established firewall sessions that a firewall rule creates. The default is that there is no limit to the number of firewall sessions.
protocol
alert {on | off}
(Optional) For each inspected protocol, the generation of alert messages can be set be on or off. If no option is selected, alerts are generated on the basis of the setting of the ip inspect alert-off command.
audit-trail {on | off}
(Optional) For each inspected protocol, audit trail can be set on or off. If no option is selected, an audit trail message are generated on the basis of the setting of the ip inspect audit-trail command.
timeout seconds
(Optional) To override the global TCP or User Datagram Protocol (UDP), or Internet Control Message Protocol (ICMP) idle timeouts for the specified protocol, specify the number of seconds for a different idle timeout.
This timeout overrides the global TCP, UDP, or ICMP timeouts but will not override the global Domain Name System (DNS) timeout.
http
Specifies the HTTP protocol for Java applet blocking.
urlfilter
(Optional) Associates URL filtering with HTTP inspection.
java-list access-list
(Optional) Specifies the numbered standard access list to use to determine "friendly" sites. This keyword is available only for the HTTP protocol, for Java applet blocking. Java blocking only works with numbered standard access lists.
smtp | esmtp
Specifies the protocol being used to inspect the traffic.
max-data number
(Optional) Specifies the maximum number of bytes (data) that can be transferred in a single Simple Mail Transport Protocol (SMTP) session. After the maximum value is exceeded, the firewall logs an alert message and closes the session. Default value: 20 MB
rpc program-number number
Specifies the program number to permit. This keyword is available only for the remote-procedure call protocol.
wait-time minutes
(Optional) Specifies the number of minutes to keep a small hole in the firewall to allow subsequent connections from the same source address and to the same destination address and port. The default wait-time is zero minutes. This keyword is available only for the remote-procedure call (RPC) protocol.
reset
(Optional) Resets the TCP connection if the client enters a non-protocol command before authentication is complete.
secure-login
(Optional) Causes a user at a non-secure location to use encryption for authentication.
imap
Specifies that the Internet Message Access Protocol (IMAP) is being used.
pop3
Specifies that the Post Office Protocol, Version 3 (POP3) is being used.
fragment
Specifies fragment inspection for the named rule.
max number
(Optional) Specifies the maximum number of unassembled packets for which state information (structures) is allocated by Cisco IOS software. Unassembled packets are packets that arrive at the router interface before the initial packet for a session. The acceptable range is 50 through 10000. The default is 256 state entries.
Memory is allocated for the state structures, and setting this value to a larger number may cause memory resources to be exhausted.
timeout seconds
(fragmentation)(Optional) Configures the number of seconds that a packet state structure remains active. When the timeout value expires, the router drops the unassembled packet, freeing that structure for use by another packet. The default timeout value is 1 second.
If this number is set to a value greater that 1 second, it is automatically adjusted by the Cisco IOS software when the number of free state structures goes below certain thresholds: when the number of free states is fewer than 32, the timeout is divided by 2. When the number of free states is fewer than 16, the timeout is set to 1 second.
appfw
Specifies application firewall provisioning.
policy-name
Application firewall policy name.
Note
appname
Specifies a user- or a system-defined application; for example, user-payroll-sap and user-sametime. Application names can contain hyphens and underscores; however, a user-defined application must have the prefix user- in its title.
port
Specifies the port range for an application.
tcp | udp
Specifies the protocol being used to inspect the traffic.
from begin_port_num to end_port_num | port_num1 ...
Specifies the starting and ending port numbers or a range of ports from 1 to 5. You must use the from and to keywords together.
list acl_list_num
(Optional) Specifies an access control list number. Only standard ACLs are supported.
description description_string
(Optional) Specifies a description of up to 40 characters.
user-10
Represents a user-defined application in the port-to-application mapping (PAM) table of the ip port-map command.
router-traffic
(Optional) Enables inspection of traffic destined to or originated from a router. Applicable only for H.323, TCP, and UDP protocols. For the command format, see the Note after Table 1.
Defaults
No inspection rules are defined until you define them using this command.
no ip inspect-name protocol removes the inspection rule for the specified protocol.
no ip inspect name removes the entire set of inspection rules.
Command Modes
Global configuration
Command History
Usage Guidelines
To define a set of inspection rules, enter this command for each protocol that you want the Cisco IOS firewall to inspect, using the same inspection-name. Give each set of inspection rules a unique inspection-name, which should not exceed the 16-character limit. Define either one or two sets of rules per interface—you can define one set to examine both inbound and outbound traffic, or you can define two sets: one for outbound traffic and one for inbound traffic.
To define a single set of inspection rules, configure inspection for all the desired application-layer protocols, and for ICMP, TCP, and UDP, or as desired. This combination of TCP, UDP, and application-layer protocols join together to form a single set of inspection rules with a unique name. (There are no application-layer protocols associated with ICMP.)
To remove the inspection rule for a protocol, use the no form of this command with the specified inspection name and protocol; to remove the entire set of inspection rules, use the no form of this command only; that is, do not list any inspection names or protocols.
In general, when inspection is configured for a protocol, return traffic entering the internal network will be permitted only if the packets are part of a valid, existing session for which state information is being maintained.
Table 1 Protocol Keywords—Transport-Layer and Network-Layer Protocols
ICMP
icmp
TCP
tcp
UDP
udp
Note
ip inspect name inspection-name {TCP | UDP | H323} [alert {on | off}] [audit-trail {on | off}][router-traffic][timeout seconds]TCP and UDP Inspection
You can configure TCP and UDP inspection to permit TCP and UDP packets to enter the internal network through the firewall, even if the application-layer protocol is not configured to be inspected. However, TCP and UDP inspection do not recognize application-specific commands, and therefore might not permit all return packets for an application, particularly if the return packets have a different port number from the previous exiting packet.
Any application-layer protocol that is inspected will take precedence over the TCP or UDP packet inspection. For example, if inspection is configured for FTP, all control channel information will be recorded in the state table, and all FTP traffic will be permitted back through the firewall if the control channel information is valid for the state of the FTP session. The fact that TCP inspection is configured is irrelevant.
With TCP and UDP inspection, packets entering the network must exactly match an existing session: the entering packets must have the same source or destination addresses and source or destination port numbers as the exiting packet (but reversed). Otherwise, the entering packets will be blocked at the interface.
Granular protocol inspection allows you to specify TCP or UDP ports by using the PAM table. This eliminates having to inspect all applications running under TCP or UDP and the need for multiple access control lists (ACLs) to filter the traffic.
Using the PAM table, you simply pick an existing application or define a new one for inspection thereby simplifying ACL configuration.
ICMP Inspection
An ICMP inspection session is on the basis of the source address of the inside host that originates the ICMP packet. Dynamic access control lists (ACLs) are created for return ICMP packets of the allowed types (echo-reply, time-exceeded, destination unreachable, and timestamp reply) for each session. There are no port numbers associated with an ICMP session, and the permitted IP address of the return packet is wild-carded in the ACL. The wildcard address is because the IP address of the return packet cannot be known in advance for time-exceeded and destination-unreachable replies. These replies can come from intermediate devices rather than the intended destination.
Application-Layer Protocol Inspection
In general, if you configure inspection for an application-layer protocol, packets for that protocol should be permitted to exit the firewall (by configuring the correct access control list), and packets for that protocol will only be allowed back in through the firewall if they belong to a valid existing session. Each protocol packet is inspected to maintain information about the session state.
Java, H.323, RPC, SIP, and SMTP inspection have additional information, described in the next five sections. Table 2 lists the supported application-layer protocols.
Java Inspection
Java inspection enables Java applet filtering at the firewall. Java applet filtering distinguishes between trusted and untrusted applets by relying on a list of external sites that you designate as "friendly." If an applet is from a friendly site, the firewall allows the applet through. If the applet is not from a friendly site, the applet will be blocked. Alternately, you could permit applets from all sites except sites specifically designated as "hostile."
Note
Note
Caution
H.323 Inspection
If you want CBAC inspection to work with NetMeeting 2.0 traffic (an H.323 application-layer protocol), you must also configure inspection for TCP, as described in the chapter "Configuring Context-Based Access Control" in the Cisco IOS Security Configuration Guide. This requirement exists because NetMeeting 2.0 uses an additional TCP channel not defined in the H.323 specification.
RPC Inspection
RPC inspection allows the specification of various program numbers. You can define multiple program numbers by creating multiple entries for RPC inspection, each with a different program number. If a program number is specified, all traffic for that program number will be permitted. If a program number is not specified, all traffic for that program number will be blocked. For example, if you created an RPC entry with the NFS program number, all NFS traffic will be allowed through the firewall.
SIP Inspection
You can configure SIP inspection to permit media sessions associated with SIP-signaled calls to traverse the firewall. Because SIP is frequently used to signal both incoming and outgoing calls, it is often necessary to configure SIP inspection in both directions on a firewall (both from the protected internal network and from the external network). Because inspection of traffic from the external network is not done with most protocols, it may be necessary to create an additional inspection rule to cause only SIP inspection to be performed on traffic coming from the external network.
SMTP Inspection
SMTP inspection causes SMTP commands to be inspected for illegal commands. Packets with illegal commands are modified to a "xxxx" pattern and forwarded to the server. This process causes the server to send a negative reply, forcing the client to issue a valid command. An illegal SMTP command is any command except the following:
•
•
•
•
•
•
•
•
•
•
•
•
ESMTP Inspection
Like SMTP, ESMTP inspection also causes the commands to be inspected for illegal commands. Packets with illegal commands are modified to a "xxxx" pattern and forwarded to the server. This process causes the server to send a negative reply, forcing the client to issue a valid command. An illegal ESMTP command is any command except the following:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
In addition to inspecting commands, the ESMTP firewall also inspects the following extensions via deeper command inspection:
•
•
•
•
•
•
•
•
Note
Use of the urlfilter Keyword
If you specify the urlfilter keyword, the Cisco IOS Firewall will interact with a URL filtering software to control web traffic for a given host or user on the basis of a specified security policy.
Note
Use of the timeout Keyword
If you specify a timeout for any of the transport-layer or application-layer protocols, the timeout will override the global idle timeout for the interface to which the set of inspection rules is applied.
If the protocol is TCP or a TCP application-layer protocol, the timeout will override the global TCP idle timeout. If the protocol is UDP or a UDP application-layer protocol, the timeout will override the global UDP idle timeout.
If you do not specify a timeout for a protocol, the timeout value applied to a new session of that protocol will be taken from the corresponding TCP or UDP global timeout value valid at the time of session creation.
The default ICMP timeout is deliberately short (10 seconds) due to the security hole that is opened by allowing ICMP packets with a wild-carded source address back into the inside network. The timeout will occur 10 seconds after the last outgoing packet from the originating host. For example, if you send a set of 10 ping packets spaced one second apart, the timeout will expire in 20 seconds or 10 seconds after the last outgoing packet. However, the timeout is not extended for return packets. If a return packet is not seen within the timeout window, the hole will be closed and the return packet will not be allowed in. Although the default timeout can be made longer if desired, it is recommended that this value be kept relatively short.
IP Fragmentation Inspection
CBAC inspection rules can help protect hosts against certain denial-of-service attacks involving fragmented IP packets. Even though the firewall keeps an attacker from making actual connections to a given host, the attacker may still be able to disrupt services provided by that host. This is done by sending many noninitial IP fragments or by sending complete fragmented packets through a router with an ACL that filters the first fragment of a fragmented packet. These fragments can tie up resources on the target host as it tries to reassemble the incomplete packets.
Using fragmentation inspection, the firewall maintains an interfragment state (structure) for IP traffic. Noninitial fragments are discarded unless the corresponding initial fragment was permitted to pass through the firewall. Noninitial fragments received before the corresponding initial fragments are discarded.
Note
Because routers running Cisco IOS software are used in a very large variety of networks, and because the CBAC feature is often used to isolate parts of internal networks from one another, the fragmentation inspection feature is not enabled by default. Fragmentation detection must be explicitly enabled for an inspection rule using the ip inspect name command. Unfragmented traffic is never discarded because it lacks a fragment state. Even when the system is under heavy attack with fragmented packets, legitimate fragmented traffic, if any, will still get some fraction of the firewall's fragment state resources, and legitimate, unfragmented traffic can flow through the firewall unimpeded.
Application Firewall Provisioning
Application firewall provisioning allows you to configure your Cisco IOS Firewall to detect and prohibit a specific protocol type of traffic.
Most firewalls provide only packet filtering capabilities that simply permit or deny traffic without inspecting the data stream; the Cisco IOS application firewall can detect whether or not a packet is in compliance with given HTTP protocol. If the packet is determined to be unauthorized, it will be dropped, the connection will be reset, and a syslog message will be generated, as appropriate.
User-Defined Applications
You can define your own applications and enter them into the port-to-application mapping (PAM) table using the ip port-map command. Then you set up your inspection rules by inserting your user-defined application as a value for the protocol argument in the ip inspect name command.
Session Limiting
Users can limit the number of established firewall sessions that a firewall rule creates by setting the "max-sessions" threshold. A session counter is maintained for each firewall interface. When a session count exceeds the specified threshold, an alert FW-4-SESSION_THRESHOLD_EXCEEDED message is logged to the syslog server and no new sessions can be created.
Examples
The following example causes the software to inspect TCP sessions and UDP sessions, and to specifically allow CU-SeeMe, FTP, and RPC traffic back through the firewall for existing sessions only. For UDP traffic, audit-trail is on. For FTP traffic, the idle timeout is set to override the global TCP idle timeout. For RPC traffic, program numbers 100003, 100005, and 100021 are permitted.
ip inspect name myrules tcpip inspect name myrules udp audit-trail onip inspect name myrules cuseemeip inspect name myrules ftp timeout 120ip inspect name myrules rpc program-number 100003ip inspect name myrules rpc program-number 100005ip inspect name myrules rpc program-number 100021The following example adds fragment checking to software inspection of TCP and UDP sessions for the rule named "myrules." In this example, the firewall software will allocate 100 state structures, and the timeout value for dropping unassembled packets is set to 4 seconds. If 100 initial fragments for 100 different packets are sent through the router, all of the state structures will be used up. The initial fragment for packet 101 will be dropped. Additionally, if the number of free state structures (structures available for use by unassembled packets) drops below the threshold values, 32 or 16, the timeout value is automatically reduced to 2 or 1, respectively. Changing the timeout value frees up packet state structures more quickly.
ip inspect name myrules tcpip inspect name myrules udp audit-trail onip inspect name myrules cuseemeip inspect name myrules ftp timeout 120ip inspect name myrules rpc program-number 100003ip inspect name myrules rpc program-number 100005ip inspect name myrules rpc program-number 100021ip inspect name myrules fragment max 100 timeout 4The following firewall and SIP example shows how to allow outside-initiated calls and internal calls. For outside-initiated calls, an ACL needs to be punched to allow for the traffic from the initial signaling packet from outside. Subsequent signaling and media channels will be allowed by the inspection module.
ip inspect name voip sipinterface FastEthernet0/0ip inspect voip in!!interface FastEthernet0/1ip inspect voip inip access-group 100 in!!access-list 100 permit udp host <gw ip> any eq 5060access-list 100 permit udp host <proxy ip> any eq 5060access-list deny ip any anyThe following example shows two configured inspections named fw_only and fw_urlf; URL filtering will work only on the traffic that is inspected by fw_urlf. Note that the java-list access-list option has been enabled, which disables java scanning.
ip inspect name fw_only http java-list 51 timeout 30interface e0ip inspect fw_only in!ip inspect name fw_urlf http urlfilter java-list 51 timeout 30interface e1ip inspect fw_urlf inThe following example shows how to define the HTTP application firewall policy mypolicy. This policy includes all supported HTTP policy rules. This example also includes sample output from the show appfw configuration and show ip inspect config commands, which allow you to verify the configured setting for the application policy.
! Define the HTTP policy.appfw policy-name mypolicyapplication httpstrict-http action allow alarmcontent-length maximum 1 action allow alarmcontent-type-verification match-req-rsp action allow alarmmax-header-length request 1 response 1 action allow alarmmax-uri-length 1 action allow alarmport-misuse default action allow alarmrequest-method rfc default action allow alarmrequest-method extension default action allow alarmtransfer-encoding type default action allow alarm!!! Apply the policy to an inspection rule.ip inspect name firewall appfw mypolicyip inspect name firewall http!!! Apply the inspection rule to all HTTP traffic entering the FastEthernet0/0 interface.interface FastEthernet0/0ip inspect firewall in!!! Issue the show appfw configuration command and the show ip inspect config command after the inspection rule "mypolicy" is applied to all incoming HTTP traffic on the FastEthernet0/0 interface.!Router# show appfw configurationApplication Firewall Rule configurationApplication Policy name mypolicyApplication httpstrict-http action allow alarmcontent-length minimum 0 maximum 1 action allow alarmcontent-type-verification match-req-rsp action allow alarmmax-header-length request length 1 response length 1 action allow alarmmax-uri-length 1 action allow alarmport-misuse default action allow alarmrequest-method rfc default action allow alarmrequest-method extension default action allow alarmtransfer-encoding default action allow alarmRouter# show ip inspect configSession audit trail is disabledSession alert is enabledone-minute (sampling period) thresholds are [400:500] connectionsmax-incomplete sessions thresholds are [400:500]max-incomplete tcp connections per host is 50. Block-time 0 minute.tcp synwait-time is 30 sec -- tcp finwait-time is 5 sectcp idle-time is 3600 sec -- udp idle-time is 30 secdns-timeout is 5 secInspection Rule ConfigurationInspection name firewallhttp alert is on audit-trail is off timeout 3600Related Commands
ip inspect one-minute high
To define the rate of new unestablished sessions that will cause the software to start deleting half-open sessions, use the ip inspect one-minute high command in global configuration mode. To reset the threshold to the default of 500 half-open sessions, use the no form of this command.
ip inspect one-minute high number [vrf vrf-name]
no ip inspect one-minute high
Syntax Description
Defaults
500 half-open sessions
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
An unusually high number of half-open sessions (either absolute or measured as the arrival rate) could indicate that a denial-of-service attack is occurring. For TCP, "half-open" means that the session has not reached the established state. For User Datagram Protocol (UDP), "half-open" means that the firewall has detected traffic from one direction only.
Context-based Access Control (CBAC) measures both the total number of existing half-open sessions and the rate of session establishment attempts. Both TCP and UDP half-open sessions are included in the total number and rate measurements. Measurements are made once a minute.
When the rate of new connection attempts rises above a threshold (the one-minute high number), the software will delete half-open sessions as required to accommodate new connection attempts. The software will continue to delete half-open sessions as necessary, until the rate of new connection attempts drops below another threshold (the one-minute low number). The rate thresholds are measured as the number of new session connection attempts detected in the last one-minute sample period. (The rate is calculated as an exponentially decayed rate.)
The global value specified for this threshold applies to all TCP and UDP connections inspected by CBAC.
Examples
The following example causes the software to start deleting half-open sessions when more than 1000 session establishment attempts have been detected in the last minute, and to stop deleting half-open sessions when fewer than 950 session establishment attempts have been detected in the last minute:
ip inspect one-minute high 1000ip inspect one-minute low 950Related Commands
ip inspect one-minute low
To define the rate of new unestablished TCP sessions that will cause the software to stop deleting half-open sessions, use the ip inspect one-minute low command in global configuration mode. To reset the threshold to the default of 400 half-open sessions, use the no form of this command.
ip inspect one-minute low number [vrf vrf-name]
no ip inspect one-minute low
Syntax Description
Defaults
400 half-open sessions
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
An unusually high number of half-open sessions (either absolute or measured as the arrival rate) could indicate that a denial-of-service attack is occurring. For TCP, "half-open" means that the session has not reached the established state. For User Datagram Protocol (UDP), "half-open" means that the firewall has detected traffic from one direction only.
Context-based Access Control (CBAC) measures both the total number of existing half-open sessions and the rate of session establishment attempts. Both TCP and UDP half-open sessions are included in the total number and rate measurements. Measurements are made once a minute.
When the rate of new connection attempts rises above a threshold (the one-minute high number), the software will delete half-open sessions as required to accommodate new connection attempts. The software will continue to delete half-open sessions as necessary, until the rate of new connection attempts drops below another threshold (the one-minute low number). The rate thresholds are measured as the number of new session connection attempts detected in the last one-minute sample period. (The rate is calculated as an exponentially decayed rate.)
The global value specified for this threshold applies to all TCP and UDP connections inspected by CBAC.
Examples
The following example causes the software to start deleting half-open sessions when more than 1000 session establishment attempts have been detected in the last minute, and to stop deleting half-open sessions when fewer than 950 session establishment attempts have been detected in the last minute:
ip inspect one-minute high 1000ip inspect one-minute low 950Related Commands
ip inspect tcp finwait-time
To define how long a TCP session will still be managed after the firewall detects a FIN-exchange, use the ip inspect tcp finwait-time command in global configuration mode. To reset the timeout to the default of 5 seconds, use the no form of this command.
ip inspect tcp finwait-time seconds [vrf vrf-name]
no ip inspect tcp finwait-time
Syntax Description
Defaults
5 seconds
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
When the software detects a valid TCP packet that is the first in a session, and if Context-based Access Control (CBAC) inspection is configured for the packet's protocol, the software establishes state information for the new session.
Use this command to define how long TCP session state information will be maintained after the firewall detects a FIN-exchange for the session. The FIN-exchange occurs when the TCP session is ready to close.
The global value specified for this timeout applies to all TCP sessions inspected by CBAC.
The timeout set with this command is referred to as the "finwait" timeout.
Note
Examples
The following example changes the finwait timeout to 10 seconds:
ip inspect tcp finwait-time 10The following example changes the finwait timeout back to the default (5 seconds):
no ip inspect tcp finwait-timeip inspect tcp idle-time
To specify the TCP idle timeout (the length of time a TCP session will still be managed while there is no activity), use the ip inspect tcp idle-time command in global configuration mode. To reset the timeout to the default of 3600 seconds (1 hour), use the no form of this command.
ip inspect tcp idle-time seconds [vrf vrf-name]
no ip inspect tcp idle-time
Syntax Description
Defaults
3600 seconds (1 hour)
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
When the software detects a valid TCP packet that is the first in a session, and if Context-based Access Control (CBAC) inspection is configured for the packet's protocol, the software establishes state information for the new session.
If the software detects no packets for the session for a time period defined by the TCP idle timeout, the software will not continue to manage state information for the session.
The global value specified for this timeout applies to all TCP sessions inspected by CBAC. This global value can be overridden for specific interfaces when you define a set of inspection rules with the
ip inspect name (global configuration) command.
Note
Examples
The following example sets the global TCP idle timeout to 1800 seconds (30 minutes):
ip inspect tcp idle-time 1800The following example sets the global TCP idle timeout back to the default of 3600 seconds (one hour):
no ip inspect tcp idle-timeip inspect tcp max-incomplete host
To specify threshold and blocking time values for TCP host-specific denial-of-service detection and prevention, use the ip inspect tcp max-incomplete host command in global configuration mode. To reset the threshold and blocking time to the default values, use the no form of this command.
ip inspect tcp max-incomplete host number block-time minutes [vrf vrf-name]
no ip inspect tcp max-incomplete host
Syntax Description
Defaults
50 half-open sessions and 0 minutes
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
An unusually high number of half-open sessions with the same destination host address could indicate that a denial-of-service attack is being launched against the host. For TCP, "half-open" means that the session has not reached the established state.
Whenever the number of half-open sessions with the same destination host address rises above a threshold (the max-incomplete host number), the software will delete half-open sessions according to one of the following methods:
•
The software will delete the oldest existing half-open session for the host for every new connection request to the host. This ensures that the number of half-open sessions to a given host will never exceed the threshold.
•
The software will delete all existing half-open sessions for the host, and then block all new connection requests to the host. The software will continue to block all new connection requests until the block-time expires.
The software also sends syslog messages whenever the max-incomplete host number is exceeded and when blocking of connection initiations to a host starts or ends.
The global values specified for the threshold and blocking time apply to all TCP connections inspected by Context-based Access Control (CBAC).
Examples
The following example changes the max-incomplete host number to 40 half-open sessions, and changes the block-time timeout to 2 minutes:
ip inspect tcp max-incomplete host 40 block-time 2The following example resets the defaults (50 half-open sessions and 0 minutes):
no ip inspect tcp max-incomplete hostRelated Commands
ip inspect tcp synwait-time
To define how long the software will wait for a TCP session to reach the established state before dropping the session, use the ip inspect tcp synwait-time command in global configuration mode. To reset the timeout to the default of 30 seconds, use the no form of this command.
ip inspect tcp synwait-time seconds [vrf vrf-name]
no ip inspect tcp synwait-time
Syntax Description
Defaults
30 seconds
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
Use this command to define how long Cisco IOS software will wait for a TCP session to reach the established state before dropping the session. The session is considered to have reached the established state after the session's first SYN bit is detected.
The global value specified for this timeout applies to all TCP sessions inspected by Context-based Access Control (CBAC).
Examples
The following example changes the synwait timeout to 20 seconds:
ip inspect tcp synwait-time 20The following example changes the synwait timeout back to the default (30 seconds):
no ip inspect tcp synwait-timeip inspect udp idle-time
To specify the User Datagram Protocol idle timeout (the length of time for which a UDP "session" will still be managed while there is no activity), use the ip inspect udp idle-time command in global configuration mode. To reset the timeout to the default of 30 seconds, use the no form of this command.
ip inspect udp idle-time seconds [vrf vrf-name]
no ip inspect udp idle-time
Syntax Description
Defaults
30 seconds
Command Modes
Global configuration
Command History
11.2 P
This command was introduced.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
When the software detects a valid UDP packet, if Context-based Access Control (CBAC) inspection is configured for the packet's protocol, the software establishes state information for a new UDP "session." Because UDP is a connectionless service, there are no actual sessions, so the software approximates sessions by examining the information in the packet and determining if the packet is similar to other UDP packets (for example, it has similar source or destination addresses) and if the packet was detected soon after another similar UDP packet.
If the software detects no UDP packets for the UDP session for the a period of time defined by the UDP idle timeout, the software will not continue to manage state information for the session.
The global value specified for this timeout applies to all UDP sessions inspected by CBAC. This global value can be overridden for specific interfaces when you define a set of inspection rules with the
ip inspect name command.
Note
Examples
The following example sets the global UDP idle timeout to 120 seconds (2 minutes):
ip inspect udp idle-time 120The following example sets the global UDP idle timeout back to the default of 30 seconds:
no ip inspect udp idle-timeip urlfilter alert
To enable URL filtering system alert messages, use the ip urlfilter alert command in global configuration mode. To disable the system alert, use the no form of this command.
ip urlfilter alert [vrf vrf-name]
no ip urlfilter alert
Syntax Description
vrf vrf-name
(Optional) Enables URL filtering system alert messages only for the specified Virtual Routing and Forwarding (VRF) interface.
Defaults
URL filtering messages are enabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
Use the ip urlfilter alert command to display system messages, such as a server entering allow mode, a server going down, or a URL that is too long for the lookup request.
Examples
The following example shows how to enable URL filtering alert messages:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 192.168.3.1Afterward, system alert messages such as the following are displayed:
%URLF-3-SERVER_DOWN:Connection to the URL filter server 10.92.0.9 is downThis level three LOG_ERR-type message is displayed when a configured URL filter server (UFS) goes down. When this happens, the firewall will mark the configured server as secondary and try to bring up one of the other secondary servers and mark that server as the primary server. If there is no other server configured, the firewall will enter into allow mode and display the URLF-3-ALLOW_MODE message described.
%URLF-3-ALLOW_MODE:Connection to all URL filter servers are down and ALLOW MODE is OFFThis LOG_ERR type message is displayed when all UFSs are down and the system enters into allow mode.
Note
%URLF-5-SERVER_UP:Connection to an URL filter server 10.92.0.9 is made, the system is returning from ALLOW MODEThis LOG_NOTICE-type message is displayed when the UFSs are detected as being up and the system is returning from allow mode.
%URLF-4-URL_TOO_LONG:URL too long (more than 3072 bytes), possibly a fake packet?This LOG_WARNING-type message is displayed when the URL in a lookup request is too long; any URL longer than 3K will be dropped.
%URLF-4-MAX_REQ:The number of pending request exceeds the maximum limit <1000>This LOG_WARNING-type message is displayed when the number of pending requests in the system exceeds the maximum limit and all further requests are dropped.
ip urlfilter allowmode
To turn on the default mode (allow mode) of the filtering algorithm, use the ip urlfilter allowmode command in global configuration mode. To disable the default mode, use the no form of this command.
ip urlfilter allowmode [on | off] [vrf vrf-name]
no ip urlfilter allowmode [on | off]
Syntax Description
Defaults
Allow mode is off.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
The system will go into allow mode when connections to all vendor servers (Websense or N2H2) are down. The system will return to normal mode when a connection to at least one web vendor server is up. Allow mode directs your system to forward or drop all packets on the basis of the configurable allow mode setting: if allow mode is on and the vendor servers are down, the HTTP requests will be allowed to pass; if allow mode is off and the vendor servers are down, the HTTP requests will be forbidden.
Examples
The following example shows how to enable allow mode on your system:
ip urlfilter allowmode onAfterward, the following alert message will be displayed when the system goes into allow mode:
%URLF-3-ALLOW_MODE: Connection to all URL filter servers are down and ALLOW MODE if OFFThe following alert message will be displayed when the system returns from allow mode:
%URLF-5-SERVER_UP: Connection to an URL filter server 12.0.0.3 is made, the system is returning from allow modeip urlfilter audit-trail
To log messages into the syslog server or router, use the ip urlfilter audit-trail command in global configuration mode. To disable this functionality, use the no form of this command.
ip urlfilter audit-trail [vrf vrf-name]
no ip urlfilter audit-trail
Syntax Description
vrf vrf-name
(Optional) Logs messages into the syslog server or router only for the specified Virtual Routing and Forwarding (VRF) interface.
Defaults
This command is disabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
Use the ip urlfilter audit-trail command to log messages such as URL request status (allow or deny) into your syslog server.
Examples
The following example shows how to enable syslog message logging:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 209.165.202.130Afterward, audit trail messages such as the following are displayed and logged into the log server:
%URLF-6-SITE_ALLOWED:Client 209.165.201.15:12543 accessed server 10.76.82.21:8080This message is logged for each request whose destination IP address is found in the cache. It includes the source IP address, source port number, destination IP address, and destination port number. The URL is not logged in this case because the IP address of the request is found in the cache; thus, parsing the request and extracting the URL is a waste of time.
%URLF-4-SITE-BLOCKED: Access denied for the site `www.sports.com'; client 209.165.200.230:34557 server 209.165.201.2:80This message is logged when a request finds a match against one of the blocked domains in the exclusive-domain list or the corresponding entry in the IP cache.
%URLF-6-URL_ALLOWED:Access allowed for URL http://www.N2H2.com/; client 209.165.200.230:54123 server 192.168.0.1:80This message is logged for each URL request that is allowed by the vendor server (Websense or N2H2). It includes the allowed URL, source IP address, source port number, destination IP address, and destination port number. Longer URLs will be truncated to 300 bytes and then logged.
%URLF-6-URL_BLOCKED:Access denied URL http://www.google.com; client 209.165.200.230:54678 server 209.165.201.2:80This message is logged for each URL request that is blocked by the vendor server. It includes the blocked URL, source IP address, source port number, destination IP address, and destination port number. Longer URLs will be truncated to 300 bytes and then logged.
ip urlfilter cache
To configure cache parameters, use the ip urlfilter cache command in global configuration mode. To clear the configuration, use the no form of this command.
ip urlfilter cache number [vrf vrf-name]
no ip urlfilter cache number
Syntax Description
Defaults
Maximum number of destination IP addresses is 5000.
The cache table is cleared out every 12 hours.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
The cache table consists of the most recently requested IP addresses and respective authorization status for each IP address.
The caching algorithm involves three parameters—the maximum number of IP addresses that can be cached, an idle time, and an absolute time. The algorithm also involves two timers—idle timer and absolute timer. The idle timer is a small periodic timer (1 minute) that checks to see whether the number of cached IP addresses in the cache table exceeds 80 percent of the maximum limit. If the cached IP addresses have exceeded 80 percent, it will start removing idle entries; if it has not exceeded 80 percent, it will quit and wait for the next cycle. The absolute timer is a large periodic timer (1 hour) that is used to remove all of the elapsed entries. (The age of an elapsed entry is greater than the absolute time.) An elapsed entry will also be removed during cache lookup.
The idle time value is fixed at 10 minutes. The absolute time value is taken from the vendor server look-up response, which is often greater than 15 hours. The absolute value for cache entries made out of exclusive-domains is 12 hours. The maximum number of cache entries is configurable by enabling the ip urlfilter cache command.
Note
Examples
The following example shows how to configure the cache table to hold a maximum of five destination IP addresses:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 192.168.3.1Related Commands
clear ip urlfilter cache
Clears the cache table.
show ip urlfilter cache
Displays the destination IP addresses that are cached into the cache table.
ip urlfilter exclusive-domain
To add or remove a domain name to or from the exclusive domain list so that the firewall does not have to send lookup requests to the vendor server, use the ip urlfilter exclusive-domain command in global configuration mode. To remove a domain name from the exclusive domain name list, use the no form of this command.
ip urlfilter exclusive-domain {permit | deny} domain-name [vrf vrf-name]
no ip urlfilter exclusive-domain {permit | deny} domain-name
Syntax Description
Defaults
This command is not enabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
The ip urlfilter exclusive-domain command allows you to specify a list of domain names (exclusive domains) so that the firewall will not create a lookup request for the HTTP traffic that is destined for one of the domains in the exclusive list. Thus, you can avoid sending look-up requests to the web server for HTTP traffic that is destined for a host that is completely allowed to all users.
Flexibility when entering domain names is also provided; that is, the user can enter the complete domain name or a partial domain name.
Complete Domain Name
If the user adds a complete domain name, such as "www.cisco.com," to the exclusive domain list, all HTTP traffic whose URLs are destined for this domain (such as www.cisco.com/news and www.cisco.com/index) will be excluded from the URL filtering policies of the vendor server (Websense or N2H2), and on the basis of the configuration, the URLs will be permitted or blocked (denied).
Partial Domain Name
If the user adds only a partial domain name to the exclusive domain list, such as ".cisco.com," all URLs whose domain names end with this partial domain name (such as www.cisco.com/products and www.cisco.com/eng) will be excluded from the URL filtering policies of the vendor server (Websense or N2H2), and on the basis of the configuration, the URLs will be permitted or blocked (denied).
Examples
The following example shows how to add the complete domain name "www.cisco.com" to the exclusive domain name list. This configuration will block all traffic destined to the www.cisco.com domain.
ip urlfilter exclusive-domain deny www.cisco.comThe following example shows how to add the partial domain name ".cisco.com" to the exclusive domain name list. This configuration will permit all traffic destined to domains that end with .cisco.com.
ip urlfilter exclusive-domain permit .cisco.comip urlfilter max-request
To set the maximum number of outstanding requests that can exist at any given time, use the ip urlfilter max-request command in global configuration mode. To disable this function, use the no form of this command.
ip urlfilter max-request number [vrf vrf-name]
no ip urlfilter max-request number
Syntax Description
Defaults
Maximum number of requests is 1000.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
If the specified maximum number of outstanding requests is exceeded, new requests will be dropped.
Note
Examples
The following example shows how to configure the maximum number of outstanding requests to 950:
ip inspect name url_filter httpip urlfilter max-request 950Related Commands
ip inspect name
Defines a set of inspection rules.
ip urlfilter server vendor
Configures a vendor server for URL filtering.
ip urlfilter max-resp-pak
To configure the maximum number of HTTP responses that the firewall can keep in its packet buffer, use the ip urlfilter max-resp-pak command in global configuration mode. To return to the default, use the no form of this command.
ip urlfilter max-resp-pak number [vrf vrf-name]
no ip urlfilter max-resp-pak number
Syntax Description
Defaults
200 HTTP responses
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
When an HTTP request arrives at a Cisco IOS firewall, the firewall forwards the request to the web server while simultaneously sending a URL look-up request to the vendor server (Websense or N2H2). If the vendor server reply arrives before the HTTP response, the firewall will know whether to permit or block the HTTP response; if the HTTP response arrives before the vendor server reply, the firewall will not know whether to allow or block the response, so the firewall will drop the response until it hears from the vendor server. The ip urlfilter max-resp-pak command allows you to configure your firewall to store the HTTP responses in a buffer, which allows your firewall to store a maximum of 200 HTTP responses. Each response will remain in the buffer until an allow or deny message is received from the vendor server. If the vendor server reply allows the URL, the firewall will release the HTTP response from the buffer to the end user; if the vendor server reply denies the URL, the firewall will discard the HTTP response from the buffer and close the connection to both ends.
Examples
The following example shows how to configure your firewall to hold 150 HTTP responses:
ip urlfilter max-resp-pak 150ip urlfilter server vendor
To configure a vendor server for URL filtering, use the ip urlfilter server vendor command in global configuration mode. To remove a server from your configuration, use the no form of this command.
ip urlfilter server vendor {websense | n2h2} ip-address [port port-number] [timeout seconds] [retransmit number] [outside] [vrf vrf-name]
no ip urlfilter server vendor {websense | n2h2} ip-address [port port-number] [timeout seconds] [retransmit number] [outside]
Syntax Description
Defaults
A vendor server is not configured.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the ip urlfilter server vendor command to configure a Websense or N2H2 server, which will interact with the Cisco IOS Firewall to filter HTTP requests on the basis of a specified policy—global filtering, user- or group-based filtering, keyword-based filtering, category-based filtering, or customized filtering.
If the firewall has not received a response from the vendor server within the time specified in the timeout seconds keyword and argument, the firewall will check the retransmit number keyword and argument configured for the vendor server. If the firewall has not exceeded the maximum retransmit tries allowed, it will resend the HTTP lookup request. If the firewall has exceeded the maximum retransmit tries allowed, it will delete the outstanding request from the queue and check the status of the allow mode value. The firewall will forward the request if the allow mode is on; otherwise, it will drop the request.
By default, URL lookup requests that are made to the vendor server contain non-natted client IP addresses because the vendor server is deployed on the inside network. The outside keyword allows the vendor server to be deployed on the outside network, thereby, allowing Cisco IOS software to send the natted IP address of the client in the URL lookup request.
Primary and Secondary Servers
When users configure multiple vendor servers, the firewall will use only one server at a time—the primary server; all other servers are called secondary servers. When the primary server becomes unavailable for any reason, it becomes a secondary server and one of the secondary servers becomes the primary server.
A firewall marks a primary server as down when sending a request to or receiving a response from the server fails. When a primary server goes down, the system will go to the beginning of the configured servers list and try to activate the first server on the list. If the first server on the list is unavailable, it will try the second server on the list; the system will keep trying to activate a server until it is successful or until it reaches the end of the server list. If the system reaches the end of the server list, it will set a flag indicating that all of the servers are down, and it will enter allow mode.
Examples
The following example shows how to configure the Websense server for URL filtering:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 192.168.3.1Related Commands
ip urlfilter urlf-server-log
To enable the logging of system messages on the URL filtering server, use the ip urlfilter urlf-server-log command in global configuration mode. To disable the logging of system messages, use the no form of this command.
ip urlfilter urlf-server-log [vrf vrf-name]
no ip urlfilter urlf-server-log
Syntax Description
vrf vrf-name
(Optional) Enables the logging of system messages on the URL filtering server only for the specified Virtual Routing and Forwarding (VRF) interface.
Defaults
This command is disabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
Use the ip urlfilter urlf-server-log command to enable Cisco IOS to send a log request immediately after the URL lookup request. The firewall will not make a URL lookup request if the destination IP address is in the cache, but it will still make a log request to the server. (The log request contains the URL, host name, source IP address, and the destination IP address.) The server records the log request into its own log server so your can view this information as necessary.
Examples
The following example shows how to enable system message logging on the URL filter server:
ip urlfilter urlf-server-logshow ip inspect
To display Context-Based Access Control (CBAC) configuration and session information, use the show ip inspect command in privileged EXEC mode.
show ip inspect {name inspection-name | config | interfaces | session [detail] | statistics | all} [vrf vrf-name]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to view the CBAC configuration and session information.
ACL Bypass Functionality
ACL bypass allows a packet to avoid redundant ACL checks by allowing the firewall to permit the packet on the basis of existing inspection sessions instead of dynamic ACLs. Because input and output dynamic ACLs have been eliminated from the firewall configuration, the show ip inspect session detail command output no longer shows dynamic ACLs. Instead, the output displays the matching inspection session for each packet that is permitted through the firewall.
Examples
The following example shows sample output for the show ip inspect name myinspectionrule command, where the inspection rule "myinspectionrule" is configured. In this example, the output shows the protocols that should be inspected by CBAC and the corresponding idle timeouts for each protocol.
Router# show ip inspect name myinspectionruleInspection Rule ConfigurationInspection name myinspectionruletcp timeout 3600udp timeout 30ftp timeout 3600The following is sample output for the show ip inspect config command. In this example, the output shows CBAC configuration, including global timeouts, thresholds, and inspection rules.
Session audit trail is disabledone-minute (sampling period) thresholds are [400:500] connectionsmax-incomplete sessions thresholds are [400:500]max-incomplete tcp connections per host is 50. Block-time 0 minute.tcp synwait-time is 30 sec -- tcp finwait-time is 5 sectcp idle-time is 3600 sec -- udp idle-time is 30 secdns-timeout is 5 secInspection Rule ConfigurationInspection name myinspectionruletcp timeout 3600udp timeout 30ftp timeout 3600The following is sample output for the show ip inspect interfaces command:
Interface ConfigurationInterface Ethernet0Inbound inspection rule is myinspectionruletcp timeout 3600udp timeout 30ftp timeout 3600Outgoing inspection rule is not setInbound access list is not setOutgoing access list is not setThe following is sample output for the show ip inspect session command. In this example, the output shows the source and destination addresses and port numbers (separated by colons), and it indicates that the session is an FTP session.
Router# show ip inspect sessionEstablished SessionsSession 25A3318 (10.0.0.1:20)=>(10.1.0.1:46068) ftp-data SIS_OPENSession 25A6E1C (10.1.0.1:46065)=>(10.0.0.1:21) ftp SIS_OPENThe following is sample output for the show ip inspect all command:
Router# show ip inspect allSession audit trail is disabledone-minute (sampling period) thresholds are [400:500] connectionsmax-incomplete sessions thresholds are [400:500]max-incomplete tcp connections per host is 50. Block-time 0 minute.tcp synwait-time is 30 sec -- tcp finwait-time is 5 sectcp idle-time is 3600 sec -- udp idle-time is 30 secdns-timeout is 5 secInspection Rule ConfigurationInspection name alltcp timeout 3600udp timeout 30ftp timeout 3600Interface ConfigurationInterface Ethernet0Inbound inspection rule is alltcp timeout 3600udp timeout 30ftp timeout 3600Outgoing inspection rule is not setInbound access list is not setOutgoing access list is not setEstablished SessionsSession 25A6E1C (30.0.0.1:46065)=>(40.0.0.1:21) ftp SIS_OPENSession 25A34A0 (40.0.0.1:20)=>(30.0.0.1:46072) ftp-data SIS_OPENThe following is sample output from the show ip inspect session detail command, which shows that an outgoing ACL and an inbound ACL (dynamic ACLs) have been created to allow return traffic:
Router# show ip inspect session detailEstablished SessionsSession 80E87274 (192.168.1.116:32956)=>(192.168.101.115:23) tcp SIS_OPENCreated 00:00:08, Last heard 00:00:04Bytes sent (initiator:responder) [140:298] acl created 2Outgoing access-list 102 applied to interface FastEthernet0/0Inbound access-list 101 applied to interface FastEthernet0/1The following is sample output from the show ip inspect session detail command, which shows related ACL information (such as session identifiers [SID]), but does not show dynamic ACLs, which are no longer created:
Router# show ip inspect session detailEstablished SessionsSession 814063CC (192.168.1.116:32955)=>(192.168.101.115:23) tcp SIS_OPENCreated 00:00:10, Last heard 00:00:06Bytes sent (initiator:responder) [140:298]In SID 192.168.101.115[23:23]=>192.168.1.117[32955:32955] on ACL 101 (15 matches)Out SID 192.168.101.115[23:23]=>192.168.1.116[32955:32955] on ACL 102
The following is sample output from the show ip inspect statistics command:
Router# show ip inspect statisticsPacket inspection statistics [process switch:fast switch]tcp packets: [616668:0]http packets: [178912:0]Interfaces configured for inspection 1Session creations since subsystem startup or last reset 42940Current session counts (estab/half-open/terminating) [0:0:0]Maxever session counts (estab/half-open/terminating) [98:68:50]Last session created 5d21hLast statistic reset neverLast session creation rate 0Last half-open session total 0Router#show ip urlfilter cache
To display the maximum number of entries that can be cached into the cache table and the number of entries and the destination IP addresses that are cached into the cache table, use the show ip urlfilter cache command in EXEC mode.
show ip urlfilter cache [vrf vrf-name]
Syntax Description
vrf vrf-name
(Optional) Displays the information only for the specified Virtual Routing and Forwarding (VRF) interface.
Command Modes
EXEC
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Examples
The following example is sample output from the show ip urlfilter cache command:
Router# show ip urlfilter cacheMaximum number of entries allowed: 5000Number of entries cached: 5IP addresses cached ....10.64.128.54172.28.139.2110.76.82.25192.168.0.110.0.1.2Table 3 describes the significant fields shown in the display.
Related Commands
clear ip urlfilter cache
Clears the cache table.
ip urlfilter cache
Configures cache parameters.
show ip urlfilter config
To display the size of the cache, the maximum number of outstanding requests, the allow mode state, and the list of configured vendor servers, use the show ip urlfilter config command in EXEC mode.
show ip urlfilter config [vrf vrf-name]
Syntax Description
vrf vrf-name
(Optional) Displays the information only for the specified Virtual Routing and Forwarding (VRF) interface.
Command Modes
EXEC
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Examples
The following example is sample output from the show ip urlfilter config command:
Router# show ip urlfilter configURL filter is ENABLEDPrimary Websense server configurations===========================Websense server IP address: 10.0.0.3Websense server port: 15868Websense retransmit time out: 5 (seconds)Websense number of retransmit:2Secondary Websense server configurations:==============================None.Other configurations===============Allow mode: OFFSystem Alert: ONLog message on the router: OFFLog message on URL filter server:ONMaximum number of cache entries :5000Cache timeout :12 (hours)Maximum number of packet buffers:200Maximum outstanding requests:1000Related Commands
show ip urlfilter statistics
To display URL filtering statistics, use the show ip urlfilter statistics command in EXEC mode.
show ip urlfilter statistics [vrf vrf-name]
Syntax Description
vrf vrf-name
(Optional) Displays the information only for the specified Virtual Routing and Forwarding (VRF) interface.
Command Modes
EXEC
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
12.3(14)T
The vrf vrf-name keyword/argument pair was added.
Usage Guidelines
This command shows information, such as the number of requests that are sent to the vendor server (Websense or N2H2), the number of responses received from the vendor server, the numberof pending requests in the system, the number of failed requests, and the number of blocked URLs.
Examples
The following example is sample output from the show ip urlfilter statistics command:
Router# show ip urlfilter statisticsURL filtering statistics================Current requests count:25Current packet buffer count(in use):40Current cache entry count:3100Maxever request count:526Maxever packet buffer count:120Maxever cache entry count:5000Total requests sent to URL Filter Server: 44765Total responses received from URL Filter Server: 44550Total requests allowed: 44320Total requests blocked: 224Table 4 describes the significant fields shown in the display.
Table 4 show ip urlfilter statistics Field Descriptions
Current requests count1
Number of requests that have been sent to the vendor server.
Current packet buffer count (in use)2
Number of HTTP responses that are currently in the packet buffer of the firewall.
Current cache entry count3
Number of destination IP addresses that have been cached into the cache table.
Maxever request count1
Maximum number of requests that have been sent to the vendor server since power on.
Maxever packet buffer count2
Maximum number of HTTP responses that have been stored in the packet buffer of the firewall since power on.
Maxever cache entry count3
Maximum number of destination IP addresses that have been cached into the cache table since power on.
1 This value can be specified via the ip urlfilter max-request command.
2 This value can be specified via the ip urlfilter max-resp-pak command.
3 This value can be specified via the ip urlfilter cache command.
Related Commands
Glossary
CE router—customer edge router. A router that is part of a customer network and that interfaces to a provider edge (PE) router.
CBAC—Context-Based Access Control. A protocol that provides internal users with secure access control for each application and for all traffic across network perimeters. CBAC enhances security by scrutinizing both source and destination addresses and by tracking each application's connection status.
data authentication—Refers to one or both of the following: data integrity, which verifies that data has not been altered, or data origin authentication, which verifies that the data was actually sent by the claimed sender.
data confidentiality—A security service where the protected data cannot be observed.
edge router—A router that turns unlabeled packets into labeled packets, and vice versa.
firewall—A router or access server, or several routers or access servers, designated as a buffer between any connected public networks and a private network. A firewall router uses access lists and other methods to ensure the security of the private network.
inspection rule—A rule that specifies what IP traffic (which application-layer protocols) will be inspected by CBAC at an interface.
intrusion detection—The Cisco IOS Firewall's Intrusion Detection System (Cisco IOS IDS) identifies the most common attacks, using signatures to detect patterns of misuse in network traffic.
IPSec—IP Security Protocol. A framework of open standards developed by the Internet Engineering Task Force (IETF). IPSec provides security for transmission of sensitive data over unprotected networks such as the Internet.
managed security services—A comprehensive set of programs that enhance service providers' abilities to meet the growing demands of their enterprise customers. Services based on Cisco solutions include managed firewall, managed VPN (network based and premises based), and managed intrusion detection.
NAT—Network Address Translation. Translates a private IP address used inside the corporation to a public, routable address for use outside of the corporation, such as the Internet. NAT is considered a one-to-one mapping of addresses from private to public.
PE router—provider edge router. A router that is part of a service provider's network and is connected to a customer edge (CE) router.
skinny—Skinny Client Control Protocol (SCCP). A protocol that enables CBAC to inspect Skinny control packets that are exchanged between a Skinny client and the Call Manager (CM); CBAC then configures the router (also known as the Cisco IOS Firewall) to enable the Skinny data channels to traverse through the router.
traffic filtering—A capability that allows you to configure CBAC to permit specified TCP and UDP traffic through a firewall only when the connection is initiated from within the network you want to protect. CBAC can inspect traffic for sessions that originate from either side of the firewall.
traffic inspection—CBAC inspection of traffic that travels through the firewall to discover and manage state information for TCP and UDP sessions. This state information is used to create temporary openings in the firewall's access lists to allow return traffic and additional data connections for permissible sessions (sessions that originated from within the protected internal network).
UDP— User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols.
VPN—Virtual Private Network. Enables IP traffic to travel securely over a public TCP/IP network by encrypting all traffic from one network to another. A VPN uses "tunneling" to encrypt all information at the IP level.
vrf—A VPN routing/forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a provider edge (PE) router.
VRF table—A table that stores routing data for each VPN. The VRF table defines the VPN membership of a customer site attached to the network access server (NAS). Each VRF table comprises an IP routing table, a derived Cisco Express Forwarding (CEF) table, and guidelines and routing protocol parameters that control the information that is included in the routing table.
Note
Copyright © 2005 Cisco Systems, Inc. All rights reserved.
