Context-Based Access Control

Feature Overview

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

Monitoring and Maintaining CBAC

Configuration Examples

Command Reference

Debug Commands

Without CBAC, traffic filtering is limited to access list implementations that examine packets at the network layer, or at most, the transport layer. However, CBAC examines not only network layer and transport layer information but also examines the application-layer protocol information (such as FTP connection information) to learn about the state of the TCP or UDP session. This allows support of protocols that involve multiple channels created as a result of negotiations in the control channel. Most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) involve multiple channels.

CBAC does not protect against attacks originating from within the protected network unless that traffic travels through a router that has the Cisco IOS Firewall deployed on it. CBAC only detects and protects against attacks that travel through the firewall. This is a scenario in which you might want to deploy CBAC on an intranet-based router.

CBAC protects against certain types of attacks, but not every type of attack. CBAC should not be considered a perfect, impenetrable defense. Determined, skilled attackers might be able to launch effective attacks. While there is no such thing as a perfect defense, CBAC detects and prevents most of the popular attacks on your network.

Packets entering the firewall are inspected by CBAC only if they first pass the inbound access list at the interface. If a packet is denied by the access list, the packet is simply dropped and not inspected by CBAC.

CBAC inspects and monitors only the control channels of connections; the data channels are not inspected. For example, during FTP sessions both the control and data channels (which are created when a data file is transferred) are monitored for state changes, but only the control channel is inspected (that is, the CBAC software parses the FTP commands and responses).

CBAC inspection recognizes application-specific commands in the control channel, and detects and prevents certain application-level attacks.

CBAC inspection tracks sequence numbers in all TCP packets, and drops those packets with sequence numbers that are not within expected ranges.

CBAC inspection recognizes application-specific commands (such as illegal SMTP commands) in the control channel, and detects and prevents certain application-level attacks.

When CBAC suspects an attack, the DoS feature can take several actions:

• Generate alert messages

• Protect system resources that could impede performance

• Block packets from suspected attackers

CBAC uses timeout and threshold values to manage session state information, helping to determine when to drop sessions that do not become fully established. Setting timeout values for network sessions helps prevent DoS attacks by freeing up system resources, dropping sessions after a specified amount of time. Setting threshold values for network sessions helps prevent DoS attacks by controlling the number of half-open sessions, which limits the amount of system resources applied to half-open sessions. When a session is dropped, CBAC sends a reset message to the devices at both end points (source and destination) of the session. When the system under DoS attack receives a reset command, it releases, or frees up, processes and resources related to that incomplete session.

CBAC provides three thresholds against DoS attacks:

• the total number of half-open TCP or UDP sessions

• the number of half-open sessions based upon time

• the number of half-open TCP-only sessions per host

If a threshold is exceeded, CBAC has two options:

• Send a reset message to the end points of the oldest half-open session, making resources available to service newly arriving SYN packets.

• In the case of half open TCP only sessions, CBAC blocks all SYN packets temporarily for the duration configured by the threshold value. When the router blocks a SYN packet, the TCP three-way handshake is never initiated, which prevents the router from using memory and processing resources needed for valid connections.

DoS detection and prevention requires that you create a CBAC inspection rule and apply that rule on an interface. The inspection rule must include the protocols that you want to monitor against DoS attacks. For example, if you have TCP inspection enabled on the inspection rule, then CBAC can track all TCP connections to watch for DoS attacks. If the inspection rule includes FTP protocol inspection but not TCP inspection, CBAC tracks only FTP connections for DoS attacks.

Return traffic will only be permitted back through the firewall if the state table contains information indicating that the packet belongs to a permissible session. Inspection controls the traffic that belongs to a valid session and forwards the traffic it does not know. When return traffic is inspected, the state table information is updated as necessary.

The temporary access list entries are never saved to NVRAM.

Use CBAC when the firewall will be passing traffic such as:

• Standard TCP and UDP Internet applications

• Multimedia applications

• Oracle support

Use CBAC for these applications if you want the application's traffic to be permitted through the firewall only when the traffic session is initiated from a particular side of the firewall (usually from the protected internal network).

In many cases, you will configure CBAC in one direction only at a single interface, which causes traffic to be permitted back into the internal network only if the traffic is part of a permissible (valid, existing) session. This is a typical configuration for protecting your internal networks from traffic that originates on the Internet.

You can also configure CBAC in two directions at one or more interfaces. CBAC is configured in two directions when the networks on both sides of the firewall should be protected, such as with extranet or intranet configurations, and to protect against DoS attacks. For example, if the firewall is situated between two partner companies' networks, you might wish to restrict traffic in one direction for certain applications, and restrict traffic in the opposite direction for other applications.

In this example, a TCP packet exits the internal network through the firewall's external interface. The TCP packet is the first packet of a Telnet session, and TCP is configured for CBAC inspection.

1. The packet reaches the firewall's external interface.

2. The packet is evaluated against the interface's existing outbound access list, and the packet is permitted. (A denied packet would simply be dropped at this point.)

3. The packet is inspected by CBAC to determine and record information about the state of the packet's connection. This information is recorded in a new state table entry created for the new connection.

4. (If the packet's application---Telnet---was not configured for CBAC inspection, the packet would simply be forwarded out the interface at this point without being inspected by CBAC. See the section "Define an Inspection Rule" for configuring CBAC inspection information.)

5. Based on the obtained state information, CBAC creates a temporary access list entry which is inserted at the beginning of the external interface's inbound extended access list. This temporary access list entry is designed to permit inbound packets that are part of the same connection as the outbound packet just inspected.

6. The outbound packet is forwarded out the interface.

7. Later, an inbound packet reaches the interface. This packet is part of the same Telnet connection previously established with the outbound packet. The inbound packet is evaluated against the inbound access list, and it is permitted because of the temporary access list entry previously created.

8. The permitted inbound packet is inspected by CBAC, and the connection's state table entry is updated as necessary. Based on the updated state information, the inbound extended access list temporary entries might be modified in order to permit only packets that are valid for the current state of the connection.

9. Any additional inbound or outbound packets that belong to the connection are inspected to update the state table entry and to modify the temporary inbound access list entries as required, and they are forwarded through the interface.

10. When the connection terminates or times out, the connection's state table entry is deleted, and the connection's temporary inbound access list entries are deleted.

In the sample process just described, the firewall access lists are configured as follows:

• An outbound IP access list (standard or extended) is applied to the external interface. This access list permits all packets that you want to allow to exit the network, including packets you want to be inspected by CBAC. In this case, Telnet packets are permitted.

• An inbound extended IP access list is applied to the external interface. This access list denies any traffic to be inspected by CBAC---including Telnet packets. When CBAC is triggered with an outbound packet, CBAC creates a temporary opening in the inbound access list to permit only traffic that is part of a valid, existing session.

If the inbound access list had be configured to permit all traffic, CBAC would be creating pointless openings in the firewall for packets that would be permitted anyway.

• All TCP sessions, regardless of the application-layer protocol (sometimes called "single-channel" or "generic" TCP inspection)

• All UDP sessions, regardless of the application-layer protocol (sometimes called "single-channel" or "generic" UDP inspection)

You can also configure CBAC to specifically inspect certain application-layer protocols. The following application-layer protocols can all be configured for CBAC:

• CU-SeeMe (only the White Pine version)

• FTP

• H.323 (such as NetMeeting, ProShare)

• HTTP (Java blocking)

• Java

• Microsoft NetShow

• UNIX R-commands (such as rlogin, rexec, and rsh)

• RealAudio

• RPC (Sun RPC, not DCE RPC)

• Microsoft RPC

• SMTP

• SQL*Net

• StreamWorks

• TFTP

• VDOLive

When a protocol is configured for CBAC, that protocol traffic is inspected, state information is maintained, and in general, packets are allowed back through the firewall only if they belong to a permissible session.

• Cisco 800 series

• Cisco uBR900 series

• Cisco 1600 series

• Cisco 1700 series

• Cisco 2500 series

• Cisco 2600 series

• Cisco 3600 series

• Cisco 7100 series

• Cisco 7200 series

"Internal" refers to the side where sessions must originate for their traffic to be permitted through the firewall. "External" refers to the side where sessions cannot originate (sessions originating from the external side will be blocked).

If you will be configuring CBAC in two directions, you should configure CBAC in one direction first, using the appropriate "internal" and "external" interface designations. When you configure CBAC in the other direction, the interface designations will be swapped. (CBAC can be configured in two directions at one or more interfaces. Configure CBAC in two directions when the networks on both sides of the firewall require protection, such as with extranet or intranet configurations, and for protection against DoS attacks.)

The firewall is most commonly used with one of two basic network topologies. Determining which of these topologies is most like your own can help you decide whether to configure CBAC on an internal interface or on an external interface.

Using these two sample topologies, decide whether to configure CBAC on an internal or external interface.

Follow these three general rules when evaluating your IP access lists at the firewall:

• Start with a basic configuration.

• Permit CBAC traffic to leave the network through the firewall.

All access lists that evaluate traffic leaving the protected network should permit traffic that will be inspected by CBAC. For example, if Telnet will be inspected by CBAC, then Telnet traffic should be permitted on all access lists that apply to traffic leaving the network.

• Use extended access lists to deny CBAC return traffic entering the network through the firewall.

For temporary openings to be created in an access list, the access list must be an extended access list. So wherever you have access lists that will be applied to returning traffic, you must use extended access lists. The access lists should deny CBAC return traffic because CBAC will open up temporary holes in the access lists. (You want traffic to be normally blocked when it enters your network.)

• If you have an outbound IP access list at the external interface, the access list can be a standard or extended access list. This outbound access list should permit traffic that you want to be inspected by CBAC. If traffic is not permitted, it will not be inspected by CBAC, but will be simply dropped.

• The inbound IP access list at the external interface must be an extended access list. This inbound access list should deny traffic that you want to be inspected by CBAC. (CBAC will create temporary openings in this inbound access list as appropriate to permit only return traffic that is part of a valid, existing session.)

• For complete information about how to configure IP access lists, refer to the "Configuring IP Services" chapter of the Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1.

• If you have an inbound IP access list at the internal interface or an outbound IP access list at external interface(s), these access lists can be either a standard or extended access list. These access lists should permit traffic that you want to be inspected by CBAC. If traffic is not permitted, it will not be inspected by CBAC, but will be simply dropped.

• The outbound IP access list at the internal interface and the inbound IP access list at the external interface must be extended access lists. These outbound access lists should deny traffic that you want to be inspected by CBAC. (CBAC will create temporary openings in these outbound access lists as appropriate to permit only return traffic that is part of a valid, existing session.) You do not necessarily need to configure an extended access list at both the outbound internal interface and the inbound external interface, but at least one is necessary to restrict traffic flowing through the firewall into the internal protected network.

• For complete information about how to configure IP access lists, refer to the "Configuring IP Services" chapter of the Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1.

You can use the default timeout and threshold values, or you can change to values more suitable to your security requirements. You should make any changes to the timeout and threshold values before you continue configuring CBAC.

Table 1: Timeout and Threshold Values

Timeout or Threshold Value to Change	Command	Default
The length of time the software waits for a TCP session to reach the established state before dropping the session.	ip inspect tcp synwait-time seconds	30 seconds
The length of time a TCP session will still be managed after the firewall detects a FIN-exchange.	ip inspect tcp finwait-time seconds	5 seconds
The length of time a TCP session will still be managed after no activity (the TCP idle timeout).1	ip inspect tcp idle-time seconds	3600 seconds (1 hour)
The length of time a UDP session will still be managed after no activity (the UDP idle timeout).1	ip inspect udp idle-time seconds	30 seconds
The length of time a DNS name lookup session will still be managed after no activity.	ip inspect dns-timeout seconds	5 seconds
The number of existing half-open sessions that will cause the software to start deleting half-open sessions.2	ip inspect max-incomplete high number	500 existing half-open sessions
The number of existing half-open sessions that will cause the software to stop deleting half-open sessions.2	ip inspect max-incomplete low number	400 existing half-open sessions
The rate of new sessions that will cause the software to start deleting half-open sessions.2	ip inspect one-minute high number	500 half-open sessions per minute
The rate of new sessions that will cause the software to stop deleting half-open sessions.2	ip inspect one-minute low number	400 half-open sessions per minute
The number of existing half-open TCP sessions with the same destination host address that will cause the software to start dropping half-open sessions to the same destination host address.3	ip inspect tcp max-incomplete host number block-time minutes	50 existing half-open TCP sessions; 0 minutes

1The global TCP and UDP idle timeouts can be overridden for specified application-layer protocols' sessions as described in the ip inspect name (global configuration) command description, found in the "Context-Based Access Control Commands" chapter of the Cisco IOS Release 12.0 Security Command Reference. 2See the following section, "Half-Open Sessions," for more information. 3Whenever the max-incomplete host threshold is exceeded, the software will drop half-open sessions differently depending on whether the block-time timeout is zero or a positive non-zero number. If the block-time timeout is zero, the software will delete the oldest existing half-open session for the host for every new connection request to the host and will let the SYN packet through. If the block-time timeout is greater than zero, 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.

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 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 firewall router reviews the "one-minute" rate on an ongoing basis, meaning that the router reviews the rate more frequently than one minute and does not keep deleting half-open sessions for one-minute after a DoS attack has stopped---it will be less time.

An inspection rule should specify each desired application-layer protocol as well as generic TCP or generic UDP if desired. The inspection rule consists of a series of statements each listing a protocol and specifying the same inspection rule name.

Inspection rules include options for controlling alert and audit trail messages and for checking IP packet fragmentation.

To define an inspection rule, follow the instructions in the following sections:

Repeat this command for each named inspection rule in which you want to inspect IP fragments.

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 to the FTP state information.

With TCP and UDP inspection, packets entering the network must exactly match the corresponding packet that previously exited the network. The entering packets must have the same source/destination addresses and source/destination port numbers as the exiting packet (but reversed); otherwise, the entering packets will be blocked at the interface. Also, all TCP packets with a sequence number outside of the window are dropped.

With UDP inspection configured, replies will only be permitted back in through the firewall if they are received within a configurable time after the last request was sent out. (This time is configured with the ip inspect udp idle-time command.)

Normally, you apply only one inspection rule to one interface. The only exception might occur if you want to enable CBAC in two directions as described earlier in the section "When and Where to Configure CBAC." For CBAC configured in both directions at a single firewall interface, you should apply two rules, one for each direction.

You should also consider the following recommendations:

• When setting passwords for privileged access to the firewall, use the enable secret command rather than the enable password command, which does not have as strong an encryption algorithm.

• Put a password on the console port. In authentication, authorization, and accounting (AAA) environments, use the same authentication for the console as for elsewhere. In a non-AAA environment, at a minimum configure the login and password password commands.

• Think about access control before you connect a console port to the network in any way, including attaching a modem to the port. Be aware that a break on the console port might give total control of the firewall, even with access control configured.

• Apply access lists and password protection to all virtual terminal ports. Use access lists to limit who can Telnet into your router.

• Do not enable any local service (such as SNMP or NTP) that you do not use. Cisco Discovery Protocol (CDP) and Network Time Protocol (NTP) are on by default, and you should turn these off if you do not need them.

To turn off CDP, enter the no cdp run global configuration command. To turn off NTP, enter the ntp disable interface configuration command on each interface not using NTP.

If you must run NTP, configure NTP only on required interfaces, and configure NTP to listen only to certain peers.

Any enabled service could present a potential security risk. A determined, hostile party might be able to find creative ways to misuse the enabled services to access the firewall or the network.

For local services that are enabled, protect against misuse. Protect by configuring the services to communicate only with specific peers, and protect by configuring access lists to deny packets for the services at specific interfaces.

• Protect against spoofing: protect the networks on both sides of the firewall from being spoofed from the other side. You could protect against spoofing by configuring input access lists at all interfaces to pass only traffic from expected source addresses, and to deny all other traffic.

You should also disable source routing. For IP, enter the no ip source-route global configuration command. Disabling source routing at all routers can also help prevent spoofing.

You should also disable minor services. For IP, enter the no service tcp-small-servers and no service udp-small-servers global configuration commands. In Cisco IOS Release 12.0 and later, these services are disabled by default.

• Prevent the firewall from being used as a relay by configuring access lists on any asynchronous Telnet ports.

• Normally, you should disable directed broadcasts for all applicable protocols on your firewall and on all your other routers. For IP, use the no ip directed-broadcast command. Rarely, some IP networks do require directed broadcasts; if this is the case, do not disable directed broadcasts.

Directed broadcasts can be misused to multiply the power of denial-of-service attacks, because every denial-of-service packet sent is broadcast to every host on a subnet. Furthermore, some hosts have other intrinsic security risks present when handling broadcasts.

• Configure the no proxy-arp command to prevent internal addresses from being revealed. (This is important to do if you do not already have NAT configured to prevent internal addresses from being revealed).

• Keep the firewall in a secured (locked) room.

%FW-4-ALERT_ON: getting aggressive, count (550/500) current 1-min rate: 250
%FW-4-ALERT_OFF: calming down, count (0/400) current 1-min rate: 0
 

When %FW-4-ALERT_ON and %FW-4-ALERT_OFF error messages appear together, each "aggressive/calming" pair of messages indicates a separate attack. The previous example shows one separate attack.

Error messages such as the following may indicate that a denial-of-service attack has occurred on a specific TCP host:

%FW-4-HOST_TCP_ALERT_ON: Max tcp half-open connections (50) exceeded for host 172.21.127.242.
%FW-4-BLOCK_HOST: Blocking new TCP connections to host 172.21.127.242 for 2 minutes (half-open count 50 exceeded)
%FW-4-UNBLOCK_HOST: New TCP connections to host 172.21.127.242 no longer blocked

%FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator (192.168.12.3:52419)
 

%FW-4-HTTP_JAVA_BLOCK: JAVA applet is blocked from (172.21.127.218:80) to
(172.16.57.30:44673).

%FW-3-FTP_PRIV_PORT: Privileged port 1000 used in PORT command -- FTP client 10.0.0.1 FTP server 10.1.0.1
	%FW-3-FTP_SESSION_NOT_AUTHENTICATED: Command issued before the session is authenticated  -- FTP client 10.0.0.1
%FW-3-FTP_NON_MATCHING_IP_ADDR: Non-matching address 172.19.148.154 used in PORT
 command  -- FTP client 172.19.54.143  FTP server 172.16.127.242

%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: http session initiator (172.16.57.30:44673) sent
1599 bytes -- responder (172.21.127.218:80) sent 93124 bytes

If required, you can also use the CBAC debug commands listed in this section. (Debugging can be turned off for each of the commands in this section by using the no form of the command. To disable all debugging, use the privileged EXEC commands no debug all or undebug all.)

The available debug commands are listed in the following categories:

• Generic Debug Commands

• Transport Level Debug Commands

• Application Protocol Debug Commands

For a complete description of the debug commands, refer to the Cisco IOS Release 12.0 Debug Command Reference.

In most situations, turning off CBAC has no negative security impact because CBAC creates "permit" access lists. Without CBAC configured, no "permit" access lists are maintained. Therefore, no derived traffic (returning traffic or traffic from the data channels) can go through the firewall. The exception is SMTP and Java blocking. With CBAC turned off, unacceptable SMTP commands or Java applets may go through the firewall.

The firewall has two interfaces:

• An Ethernet interface connects to the internal protected network.

Interface Ethernet0 has no ACL applied to it, meaning that all traffic initiated on the LAN is allowed access to the ISP. In this configuration example, Network Address Translation (NAT) is not turned on, and the addresses on interface Ethernet0 are reserved IP addresses. In a production environment, addresses on Ethernet0 either must be registered network addresses, or you must turn on NAT to hide these inside addresses from being visible on the Internet.

• An ISDN Basic Rate Interface (BRI) connects the router to the ISP. In this example, a dialer profile is used to control the BRI interface. This means that the ACL and CBAC inspection rules are applied at the dialer interface, not directly at the physical ISDN (BRI) interface using a dialer map.

!--------------------------------------
!General Cisco IOS Firewall Guidelines
!--------------------------------------
!The following global configuration entries illustrate good security practices. 
enable secret 5 <elided>
no ip source-route
no cdp run
!
!--------------------------------
!Create the CBAC inspection rule
!-------------------------------
!Create the CBAC inspection rule STOP to allow inspection of the protocol traffic
!specified by the rule. 
ip inspect name STOP tcp
ip inspect name STOP ftp
ip inspect name STOP smtp
ip inspect name STOP h323
ip inspect name STOP rcmd
!
!---------------------------------
!Create Access Control List 105 
!---------------------------------
!ACL 105 denies all IP protocol traffic except for specific ICMP control traffic. 
!This means that only the return traffic for protocols defined in the 
!inspection rule and the specified ICMP traffic is allowed access through the 
!interface where this rule is applied.
!
!Deny broadcast messages with a source address of 255.255.255.255; this helps to
!prevent broadcast attacks.
access-list 105 deny ip host 255.255.255.255 any
!
!Add anti-spoofing protection by denying traffic with a source address matching a host
!on the Ethernet interface.
acl 105 deny ip 192.168.1.0 0.0.0.255 any 
!
!ICMP traffic is not inspected by CBAC. To control the type of ICMP traffic at the
!interface, add static access list entries. This example has the following ICMP
!requirements: outgoing ping commands require echo-reply messages to come back,
!outgoing traceroute commands require time-exceeded messages to come back, path MTU
!discovery requires "too-big" messages to come back, and incoming traceroute
!messages must be allowed. Additionally, permit all "unreachable" messages to come
!back; that is, if a router cannot forward or deliver a datagram, it sends an ICMP
!unreachable
!message back to the source and drops the datagram.
access-list 105 permit icmp any any echo-reply
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 time-exceeded
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 packet-too-big
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 traceroute
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 unreachable
!
!Final deny for explicitness. This entry is not required but helps complete the access
!list picture. By default, the final entry in any access list is an implicit deny of IP
!protocol traffic. This ensures that the firewall blocks any traffic not explicitly
!permitted by the access list.
access-list 105 deny ip any any
!
!----------------------------------------------------------
!Configure the interface
!----------------------------------------------------------
!In this example, no ACLs or inspection rules are applied at interface Ethernet0, 
!meaning that all traffic on the local network is allowed to go out. This assumes a
!high-level of trust for the users on the local network.
interface Ethernet0
ip address 192.168.1.104 255.255.255.0

!
no ip directed-broadcast
!
!This example uses a dialer profile, so the ACL and CBAC inspection rules are applied
!at the dialer interface, not the physical BRI interface. The dialer pool-member
!command is used to associate the physical interface with a dialer profile. 
interface BRI0
no ip address
no ip directed-broadcast
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-5ess

!
!-------------------------------------------------------------------
!Create the dialer profile.
!-------------------------------------------------------------------
!Through the dialer profile, the ACL and CBAC inspection rules are
!applied to every pool member. In this example, the ACL is applied in, meaning that it
!applies to traffic inbound from the ISP. The CBAC inspection rule STOP is applied out,
!meaning that CBAC monitors the traffic through the interface and controls return
!traffic to the router for an existing connection. 
interface Dialer0
ip address negotiated
ip access-group 105 in
no ip directed-broadcast
ip inspect STOP out
encapsulation ppp
dialer remote-name <ISP router>
dialer idle-timeout 500
dialer string <elided>
dialer pool 1
dialer-group 1
ppp authentication callin

!
!---------------------------------------------------------
!Additional entries 
!---------------------------------------------------------
!Configure the router to forward packets destined for an unrecognized subnet of
!a directly connected network.
ip classless
!Route traffic to the dialer interface.
ip route 0.0.0.0 0.0.0.0 Dialer0
!Include a dialer list protocol entry to specify the protocol that triggers dialing.
dialer-list 1 protocol ip permit
!Add a user name (name of the router your are configuring) and password for caller
!identification and password authentication with the ISP router.
username <router host name> password 5 <elided>

The firewall has two interfaces:

• An Ethernet interface connects to the internal protected network.

Interface Ethernet0 has no ACL applied to it, meaning that all traffic initiated from the LAN is allowed access through the firewall.

• An ISDN Basic Rate Interface (BRI) connects the router to the branch office. In this example, a dialer profile is used to control the BRI interface. This means that the ACL and CBAC inspection rules are applied at dialer interface, not directly at the physical ISDN (BRI) interface.

!-------------------------------------------
!General firewall configuration guidelines
!-------------------------------------------
!The following global configuration entries illustrate good security practices. 
enable secret 5 <elided>
no ip source-route
no cdp run
!
!---------------------------
!Create the Inspection Rule
!---------------------------
!Create the CBAC inspection rule STOP to allow inspection of the specified protocol
!traffic. Create the inspection rule GO to allow inspection of HTTP and SMTP
!traffic. Note that Java applets will be permitted according to access list 51, which
!is defined later in this sample configuration.
ip inspect name STOP tcp
ip inspect name STOP ftp
ip inspect name STOP smtp
ip inspect name STOP h323
ip inspect name STOP rcmd
ip inspect name GO http java-list 51
ip inspect name GO smtp
!
!--------------------------------------------------------------
!Create Access Control Lists 106 and 51
!--------------------------------------------------------------
!ACL 106 permits mail and Web traffic from any host to the specified server. ACL106
!denies all other ip protocol traffic except for specific ICMP control traffic. 
!This means that only the return traffic for protocols defined in the 
!inspection rule and the specified ICMP traffic is allowed access through the 
!interface where this rule is applied.
!
!Deny broadcast messages with a source address of 255.255.255.255; this helps to 
!prevent broadcast attacks.
access-list 106 deny ip host 255.255.255.255 any
!
!Add anti-spoofing protection by denying traffic with a source address matching a host
!on the Ethernet interface.
access-list 106 deny ip 192.168.1.0 0.0.0.255 any 
!
!ICMP traffic is not inspected by CBAC. To control the type of ICMP traffic at the
!interface, add static access list entries. This example has the following ICMP
!requirements: outgoing ping commands require echo-reply messages to come back,
!outgoing traceroute commands require time-exceeded messages to come back, path MTU
!discovery requires "too-big" messages to come back, and incoming traceroute must be
!allowed. Additionally, permit all "unreachable" messages to come back; that is, if a
!router cannot forward or deliver a datagram, it sends an ICMP unreachable message back
!to the source and drops the datagram.
access-list 106 permit icmp any any echo-reply
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 time-exceeded
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 packet-too-big
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 traceroute
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 unreachable
!
!Permit mail and Web access to a specific server.
access-list 106 permit tcp any host 192.168.1.20 eq smtp
access-list 106 permit tcp any host 192.168.1.20 eq www
!
!Final deny for explicitness. This entry is not required but helps complete the access
!list picture. By default, the final entry in any access list is an implicit deny of IP
!protocol traffic. This ensures that the firewall blocks any traffic not explicitly
!permitted by the access list.
access-list 106 deny ip any any
!
!Access list 51 defines the sites for Java applet blocking. If the access list denies a
!site, that site is deemed "hostile" and applets from that site are blocked. If the 
!access list permits a site, that site is deemed "friendly" and applets from that
!site are not blocked. Java applet blocking is defined in the inspection rule "GO",
!meaning applets are permitted or denied from the sites defined in the access list. In
!this example, access list 51 permits Java applets from any site (source address). 
access-list 51 permit any
!
!----------------------------------------------------------
!Configure the interface.
!----------------------------------------------------------
!In this example, no ACLs or inspection rules are applied at interface Ethernet0, 
!meaning that all traffic on the local network is allowed to go out. This assumes a
!high-level of trust for the users on the local network.
interface Ethernet0
ip address 192.168.1.104 255.255.255.0
no ip directed-broadcast

!
!This example uses a dialer profile, so the ACL and CBAC inspection rules are applied
!at the dialer interface, not the physical BRI interface. The dialer pool-member
!command is used to associate the physical interface with a dialer profile. 
interface BRI0
no ip address
no ip directed-broadcast
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-5ess

!
!------------------------------------------------------------------
!Apply the ACL and CBAC inspection rules at the dialer interface.
!------------------------------------------------------------------
!Through the dialer profile, the ACL and CBAC inspection rules are 
!applied to every pool member. In this example, the ACL is applied in, meaning that it 
!applies to traffic inbound from the branch office. The CBAC inspection rule STOP is
!applied out, meaning that CBAC monitors the traffic and controls return traffic to the
!router for an existing connection. The CBAC inspection rule GO is applied in,
!protecting against certain types of DoS attacks as described in this document. Note
!that the GO inspection rule does not control return traffic because there is no ACL
!blocking traffic in that direction; however, it does monitor the connections.
interface Dialer0
ip address <ISDN interface address>
ip access-group 106 in
no ip directed-broadcast
ip inspect STOP out
ip inspect GO in
encapsulation ppp
dialer remote-name <branch office router>
dialer idle-timeout 500
dialer string <elided>
dialer pool 1
dialer-group 1
ppp authentication

!
!---------------------------------------------------------
Additional entries 
!---------------------------------------------------------
!Configure the router to forward packets destined for an unrecognized subnet of
!a directly connected network.
ip classless
!Route traffic to the dialer interface.
ip route 0.0.0.0 0.0.0.0 Dialer0
!Include a dialer list protocol entry to specify the protocol that triggers dialing.
dialer-list 1 protocol ip permit
!Add a user name (name of the router your are configuring) and password for caller
!identification and password authentication with the ISP router.
username <router host name> password 5 <elided>

The firewall has two interfaces configured:

• Interface Ethernet0 connects to the internal protected network

• Interface Serial0 connects to the WAN with Frame Relay

!----------------------------------------------------------------------
! This first section contains some configuration that is not required for CBAC,
! but illustrates good security practices. Note that there are no 
! services on the Ethernet side. Email is picked up via POP from a server on the
! corporate side.
!----------------------------------------------------------------------
!
hostname user1-examplecorp-fr
!
boot system flash c1600-fw1600-l
enable secret 5 <elided>
!
username user1 password <elided>
ip subnet-zero
no ip source-route
ip domain-name example.com
ip name-server 172.19.2.132
ip name-server 198.92.30.32
!
!
!----------------------------------------------------------------------
!The next section includes configuration required specifically for CBAC
!----------------------------------------------------------------------
!
!The following commands define the inspection rule "myfw", allowing
!the specified protocols to be inspected. Note that Java applets will be permitted
!according to access list 51, defined later in this configuration.
ip inspect name myfw cuseeme timeout 3600
ip inspect name myfw ftp timeout 3600
ip inspect name myfw http java-list 51 timeout 3600
ip inspect name myfw rcmd timeout 3600
ip inspect name myfw realaudio timeout 3600
ip inspect name myfw smtp timeout 3600
ip inspect name myfw tftp timeout 30
ip inspect name myfw udp timeout 15
ip inspect name myfw tcp timeout 3600
!
!The following interface configuration applies the "myfw" inspection rule to
!inbound traffic at Ethernet 0. Since this interface is on the internal network 
!side of the firewall, traffic entering Ethernet 0 is actually 
!exiting the internal network. Applying the inspection rule to this interface causes
!inbound traffic (which is exiting the network) to be inspected; return traffic will
!only be permitted back through the firewall if part of a session which began from
!within the network.
!Also note that access list 101 is applied to inbound traffic at Ethernet 0.
!Any traffic that passes the access list will be inspected by CBAC.
!(Traffic blocked by the access list will not be inspected.)
interface Ethernet0
description ExampleCorp Ethernet chez user1
ip address 172.19.139.1 255.255.255.248
ip broadcast-address 172.19.131.7
no ip directed-broadcast
no ip proxy-arp
ip inspect myfw in
ip access-group 101 in
no cdp enable

!
interface Serial0
description Frame Relay (Telco ID 22RTQQ062438-001) to ExampleCorp HQ
no ip address
ip broadcast-address 0.0.0.0
encapsulation frame-relay IETF
no arp frame-relay
bandwidth 56
service-module 56k clock source line
service-module 56k network-type dds
frame-relay lmi-type ansi

!
!Note that the following interface configuration applies access list 111 to
!inbound traffic at the external serial interface. (Inbound traffic is
!entering the network.) When CBAC inspection occurs on traffic exiting the 
!network, temporary openings will be added to access list 111 to allow returning
!traffic that is part of existing sessions.
!
interface Serial0.1 point-to-point
ip unnumbered Ethernet0
ip access-group 111 in
bandwidth 56
no cdp enable
frame-relay interface-dlci 16   

!
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0.1
!
!The following access list defines "friendly" and "hostile" sites for Java 
!applet blocking. Because Java applet blocking is defined in the inspection 
!rule "myfw" and references access list 51, applets will be actively denied
!if they are from any of the "deny" addresses and allowed only if they are from 
!either of the two "permit" networks.
!
access-list 51 deny   172.19.1.203
access-list 51 deny   172.19.2.147
access-list 51 permit 172.18.0.0 0.1.255.255
access-list 51 permit 192.168.1.0 0.0.0.255
access-list 51 deny   any
!
!The following access list 101 is applied to interface Ethernet 0 above.
!This access list permits all traffic that should be CBAC inspected, and also 
!provides anti-spoofing. The access list is deliberately set up to deny unknown
!IP protocols, because no such unknown protocols will be in legitimate use.
!
access-list 101 permit tcp 172.19.139.0 0.0.0.7 any
access-list 101 permit udp 172.19.139.0 0.0.0.7 any
access-list 101 permit icmp 172.19.139.0 0.0.0.7 any
access-list 101 deny   ip any any
!
!The following access list 111 is applied to interface Serial 0.1 above.
!This access list filters traffic coming in from the external side. When
!CBAC inspection occurs, temporary openings will be added to the beginning of
!this access list to allow return traffic back into the internal network.
!This access list should restrict traffic that will be inspected by
!CBAC. (Remember that CBAC will open holes as necessary to permit returning traffic.)
!Comments precede each access list entry. These entries are not all specifically
!related to CBAC, but are created to provide general good security.
!
!Anti-spoofing.
access-list 111 deny   ip 172.19.139.0 0.0.0.7 any
!Sometimes EIGRP is run on the Frame Relay link. When you use an
!input access list, you have to explicitly allow even control traffic.
!This could be more restrictive, but there would have to be entries
!for the EIGRP multicast as well as for the office's own unicast address.
access-list 111 permit igrp any any
!
!These are the ICMP types actually used...
!administratively-prohibited is useful when you are trying to figure out why
!you cannot reach something you think you should be able to reach.
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 administratively-prohibited
!
!This allows network admins at headquarters to ping hosts at the field office:
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 echo
!
!This allows the field office to do outgoing pings
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 echo-reply
!
!Path MTU discovery requires too-big messages
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 packet-too-big
!
!Outgoing traceroute requires time-exceeded messages to come back
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 time-exceeded
!
!Incoming traceroute
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 traceroute
!
!Permits all unreachables because if you are trying to debug
!things from the remote office, you want to see them. If nobody ever did 
!any debugging from the network, it would be more appropriate to permit only 
!port unreachables or no unreachables at all.
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 unreachable
!
!
!These next two entries permit users on most ExampleCorp networks to Telnet to
!a host in the field office. This is for remote administration by the network admins.
access-list 111 permit tcp 172.18.0.0 0.1.255.255 host 172.19.139.1 eq telnet
access-list 111 permit tcp 192.168.1.0 0.0.0.255 host 172.19.139.1 eq telnet
!
!Final deny for explicitness
access-list 111 deny ip any any
!
no cdp run
snmp-server community <elided> RO
!
line con 0
exec-timeout 0 0
password <elided>
login local

line vty 0
exec-timeout 0 0
password <elided>
login local
length 35

line vty 1
exec-timeout 0 0
password 7 <elided>
login local

line vty 2
exec-timeout 0 0
password 7 <elided>
login local

line vty 3
exec-timeout 0 0
password 7 <elided>
login local

line vty 4
exec-timeout 0 0
password 7 <elided>
login local

The branch office has this sample network configuration:

• Ethernet interface 0/0 supports the Human Resources department servers. This network includes an email (SMTP and POP3) host and a Windows NT server. The Windows NT server is the Primary Domain Controller (PDC) for the Human Resources domain and has a trust relationship with the rest of the company; however, it contains applications and databases that must not be accessed by the rest of the company or the other groups in the branch office. The devices on this LAN are accessible only by users in the Human Resources department on Ethernet interface 0/1. The Mail server must be able to send and receive email (through SMTP sessions) with all other devices. The Windows 95 machines can use this machine as their email server (for sending email through SMTP sessions) and as a repository for accumulating email that they can then download through POP3 sessions. No one else in the company is allowed to form POP3 sessions to any machine on this LAN.

• Ethernet interface 0/1 supports the Windows 95 computers in the Human Resources department. These users must have access to the Human Resources mail servers located on Ethernet interface 0/0 as well as access to the rest of the company. Access to the Windows NT server resources are controlled through the Windows NT permissions assigned to each user in the Windows NT domain.

• Ethernet interface 1/0 supports the branch office web servers, which can be accessed by everyone in the company. These servers use TCP ports 80 (HTTP) and 443 (SHTTP) for inbound Web access. This network also includes a backup domain controller (BDC) for the overall domain that is also used as file, print, and service server.

Ethernet interface 1/1 supports all users who are not in the Human Resources department. These users have no access to the Human Resources department servers, but they can access the other network interfaces and the serial interfaces for WAN connectivity. Serial interface 0/0 and 0/1 connect to the WAN with T1 links (links to corporate headquarters). In this sample configuration, the Domain Name System (DNS) servers are located somewhere within the rest of the company.

Additionally, network management (SNMP) and Telnet sessions are limited to the management network (192.168.55.0), which is located somewhere within the rest of the company across the serial interface.

! ------------------------------------------------------------------
! This first section contains some configuration that is not required
! for CBAC, but illustrates good security practices.
! ------------------------------------------------------------------
!Add this line to get timestamps on the syslog messages.
service timestamps log datetime localtime show-timezone
!
hostname Router1
!
boot system flash c3600-fw3600-l
!
! Configure AAA user authentication.
aaa new-model
aaa authentication login lista tacacs+ enable
!
enable secret 5 <elided>
ip subnet-zero
!
! Disable source routing to help prevent spoofing.
no ip source-route
!
! Set up the domain name and server IP addresses.
ip domain-name example.com
ip name-server 192.168.55.132
ip name-server 192.168.27.32
!
! The audit-trail command enables the delivery of specific CBAC messages 
! through the syslog notification process.
ip inspect audit-trail 
!
! Establish the time-out values for DNS queries. When this idle-timer expires,
! the dynamic ACL entries that were created to permit the reply to a DNS request 
! will be removed and any subsequent packets will be denied.
ip inspect dns-timeout 10
!
!----------------------------------------------------------------------
!The next section includes configuration statements required 
!specifically for CBAC.
!----------------------------------------------------------------------
! Define the CBAC inspection rule "inspect1", allowing the specified protocols to be
! inspected. The first rule enables SMTP specific inspection. SMTP inspection causes
! the exchange of the SMTP session to be inspected for illegal commands. Any packets
! with illegal commands are dropped, and the SMTP session will hang and eventually
! time out.
ip inspect name inspect1 smtp timeout 300
!
! In the next two lines of inspect1, define the maximum time that each of the UDP and 
! TCP sessions are allowed to continue without any traffic passing 
! through the router. When these timeouts are reached, the dynamic ACLs that 
! are inserted to permit the returning traffic are removed and subsequent packets
! (possibly even valid ones) will not be permitted.
ip inspect name inspect1 udp timeout 300
ip inspect name inspect1 tcp timeout 300
!
! Define the CBAC inspection rule "inspect2", allowing the specified protocols to be
! inspected. These rules are similar to those used in the inspection rule "inspect1,"
! except that on the interfaces where this rule is applied, SMTP sessions are not 
! expected to go through; therefore, the SMTP rule element is not applied here.
ip inspect name inspect2 udp timeout 300
ip inspect name inspect2 tcp timeout 3600
!
!----------------------------------------------------------------------
! The next section shows the Ethernet interface configuration statements for each 
! interface, including access lists and inspections rules. 
!----------------------------------------------------------------------
! Apply the "inspect1" inspection rule to sessions that are initiated in the outbound 
! direction (toward the LAN) at Ethernet interface 0/0. All packets in these sessions
! will be inspected by CBAC. Provided that network traffic passes the Access Control
! List (ACL) restrictions, traffic is then inspected by CBAC for access through the
! Cisco IOS Firewall. Traffic blocked by the access list is not inspected by CBAC.
! Access list 110 is applied to outbound traffic on this interface. 
interface Ethernet0/0
description HR_Server Ethernet
ip address 172.16.110.1 255.255.255.0
ip access-group 110 out
no ip directed-broadcast
no ip proxy-arp
ip inspect inspect1 out
no cdp enable

!
! Apply access list 120 to inbound traffic on Ethernet interface 0/1.
! Applying access list 120 to inbound traffic provides anti-spoofing on this interface
! by dropping traffic with a source address matching the IP address on a network other
! than Ethernet 0/1. The IP helper address lists the IP address of the DHCP server on
! Ethernet interface 1/0. 
interface Ethernet0/1
description HR_client Ethernet
ip address 172.16.120.1 255.255.255.0
ip access-group 120 in
ip helper-address 172.16.130.66
no ip directed-broadcast
no ip proxy-arp
no cdp enable

!
! Apply the "inspect2" inspection rule to sessions that are initiated in the outbound
! direction (toward the LAN) at Ethernet interface 1/0. Provided that network traffic
! passes the Access Control List (ACL) restrictions, traffic is then inspected by CBAC
! through the Cisco IOS Firewall. Traffic blocked by the access list is not inspected
! by CBAC. Access list 130 is applied to outbound traffic on this interface. 
interface Ethernet1/0
description Web_server Ethernet
ip address 172.16.130.1 255.255.255.0
ip access-group 130 out
no ip directed-broadcast
no ip proxy-arp
ip inspect inspect2 out
no cdp enable

!
! Apply access list 140 to inbound traffic at Ethernet interface 1/1. This
! provides anti-spoofing on the interface by dropping traffic with a source address
! matching the IP address of a network other than Ethernet 1/1. The IP helper address
! lists the IP address of the DHCP server on Ethernet interface 1/0. 
interface Ethernet1/1
description Everyone_else Ethernet
ip address 172.16.140.1 255.255.255.0
ip access-group 140 in
ip helper-address 172.16.130.66
no ip directed-broadcast
 
no ip proxy-arp
no cdp enable

!
!----------------------------------------------------------------------
! The next section configures the serial interfaces, including access lists. 
!----------------------------------------------------------------------
! Apply access list 150 to Serial interfaces 0/0. This provides anti-spoofing on the
! serial interface by dropping traffic with a source address matching the IP address
! of a host on Ethernet interface 0/0, 0/1, 1/0, or 1/1.
interface Serial0/0
description T1 to HQ
ip address 192.168.150.1 255.255.255.0
ip access-group 150 in
bandwidth 1544

!
interface Serial1/1
description T1 to HQ
ip address 192.168.160.1 255.255.255.0
ip access-group 150 in
bandwidth 1544

!
! ------------------------------
! Configure routing information.
! -------------------------------
router igrp 109
network 172.16.0.0
network 192.168.150.0
network 192.168.160.0
!
! Define protocol forwarding on the firewall. When you turn on a related command, 
! ip helper-address, you forward every IP broadcast in the ip forward protocol
! command list, including several which are on by default: TFTP (port 69), 
! DNS (port 53), Time service (port 37), NetBIOS Name Server (port 137), 
! NetBIOS Datagram Server (port 138), BOOTP client and server datagrams 
! (ports 67 and 68), and TACACS service (port 49). One common
! application that requires helper addresses is Dynamic Host Configuration
! Protocol (DHCP). DHCP information is carried inside of BOOTP packets. The
! "no ip forward protocol" statements turn off forwarding for the specified protocols.
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs 
no ip forward-protocol udp tftp 
ip forward-protocol udp bootpc
!
! Add this line to establish where router SYSLOG messages are sent. This includes the
! CBAC messages. 
logging 192.168.55.131 
!
! ---------------------------------------------------------------
! Define the configuration of each access list. 
! ---------------------------------------------------------------
! Defines Telnet controls in access list 12.
access-list 12 permit 192.168.55.0 0.0.0.255
!
! Defines SNMP controls in access list 13. 
access-list 13 permit 192.168.55.12
access-list 13 permit 192.168.55.19
!
! Access list 110 permits TCP and UDP protocol traffic for 
! specific ports and with a source address on Ethernet interface 0/1. The access list
! denies IP protocol traffic with any other source and destination address. The 
! access list permits ICMP access for any source and destination 
! address. Access list 110 is deliberately set up to deny unknown IP protocols 
! because no such unknown protocols will be in legitimate use. Access list
! 110 is applied to outbound traffic at Ethernet interface 0/0. In ACL 110,
! network traffic is being allowed access to the ports on any server on the HR server
! network. In less trusted environments, this can be a security problem; however, you
! can limit access more severely by specifying specific destination addresses in the
! ACL statements.
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq smtp
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq pop3
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq 110
access-list 110 permit udp any any eq 137
access-list 110 permit udp any any eq 138
access-list 110 permit udp any any eq 139
access-list 110 permit icmp any any 
access-list 110 deny ip any any!
!
! Access-list 120 permits TCP, UDP, and ICMP protocol traffic with a source address 
! on Ethernet interface 0/1, but denies all other IP protocol traffic. Access list
! 120 is applied to inbound traffic on Ethernet interface 0/1.
access-list 120 permit tcp 172.16.120.0 0.0.0.255 any
access-list 120 permit udp 172.16.120.0 0.0.0.255 any
access-list 120 permit icmp 172.16.120.0 0.0.0.255 any
access-list 120 deny ip any any
!
! Access list 130 permits TCP, UDP, and ICMP protocol traffic for specific ports and
! with any source and destination address. It opens access to the web server and to
! all NBT services to the rest of the company, which can be controlled through the
! trust relations on the Windows NT servers. The bootpc entry permits access to the
! DHCP server. Access list 130 denies all other IP protocol traffic. Access list 130 is
! applied to outbound traffic at Ethernet interface 1/0.
access-list 130 permit tcp any any eq www
access-list 130 permit tcp any any eq 443
access-list 130 permit tcp any any eq 110
access-list 130 permit udp any any eq 137
access-list 130 permit udp any any eq 138
access-list 130 permit udp any any eq 139
access-list 130 permit udp any any eq bootpc 
access-list 130 permit icmp any any 
access-list 130 deny ip any any
!
! Access list 140 permits TCP, UDP, and ICMP protocol traffic with a source address on
! Ethernet interface 1/1, and it denies all other IP protocol traffic. Access list 140
! is applied to inbound traffic at Ethernet interface 1/1.
access-list 140 permit tcp 172.16.140.0 0.0.0.255 any
access-list 140 permit udp 172.16.140.0 0.0.0.255 any
access-list 140 permit icmp 172.16.140.0 0.0.0.255 any
access-list 140 deny ip any any
!
! Access list 150 denies IP protocol traffic with a source address on Ethernet 
! interfaces 0/0, 0/1, 1/0, and 1/1, and it permits IP protocol traffic with any other
! source and destination address. Access list 150 is applied to inbound traffic
! on each of the serial interfaces.
access-list 150 deny ip 172.16.110.0 0.0.0.255 any
access-list 150 deny ip 172.16.120.0 0.0.0.255 any
access-list 150 deny ip 172.16.130.0 0.0.0.255 any
access-list 150 deny ip 172.16.140.0 0.0.0.255 any
access-list 150 permit ip any any
!
! Disable Cisco Discovery Protocol.
no cdp run 
!
snmp-server community <elided> ro 13
tacacs-server host 192.168.55.2
tacacs-server key <elided>
!
! -----------------------------------------------------------------------------------
! Configures the router console port and the virtual terminal line interfaces,
! including AAA authentication at login. Authentication is required for users defined
! in "lista." Access-class 12 is applied on each line, restricting Telnet access to
! connections with a source address on the network management network.
! -----------------------------------------------------------------------------------
line console 0
exec-timeout 3 00
login authentication lista
line aux 0
exec-timeout 3 00
login authentication lista
line vty 0
exec-timeout 1 30
login authentication lista
access-class 12 in

line vty 1
exec-timeout 1 30
login authentication lista
access-class 12 in

line vty 2
exec-timeout 1 30
login authentication lista
access-class 12 in

line vty 3
exec-timeout 1 30
login authentication lista
access-class 12 in

line vty 4
exec-timeout 1 30
login authentication lista
access-class 12 in

or

or

or

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/destination addresses and source/destination port numbers as the exiting packet (but reversed). Otherwise, the entering packets will be blocked at the interface.

Application-Layer Protocol Inspection

Java, H.323, RPC, and SMTP, and SQL*Net inspection have additional information, described in the next four sections.

Java Inspection

Caution CBAC does not detect or block encapsulated Java applets. Therefore, Java applets that are wrapped or encapsulated, such as applets in .zip or .jar format, are not blocked at the firewall. CBAC also does not detect or block applets loaded via FTP, gopher, or HTTP on a nonstandard port.

H.323 Inspection

RPC Inspection

SMTP Inspection

• DATA

• EHLO

• EXPN

• HELO

• HELP

• MAIL

• NOOP

• QUIT

• RCPT

• RSET

• SAML

• SEND

• SOML

• VRFY

Use of the timeout Keyword

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.

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 non-initial 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.

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.

ip inspect name myrules tcp
ip inspect name myrules udp audit-trail on
ip inspect name myrules cuseeme
ip inspect name myrules ftp timeout 120
ip inspect name myrules rpc program-number 100003
ip inspect name myrules rpc program-number 100005
ip inspect name myrules rpc program-number 100021
 

ip inspect name myrules tcp
ip inspect name myrules udp audit-trail on
ip inspect name myrules cuseeme
ip inspect name myrules ftp timeout 120
ip inspect name myrules rpc program-number 100003
ip inspect name myrules rpc program-number 100005
ip inspect name myrules rpc program-number 100021
ip inspect name myrules fragment max 100 timeout 4
 
 
 
 
 

no ip inspect alert-off