CBAC Configuration

This section covers the configuration of CBAC for stateful inspection and filtering. Unlike the configuration of RACLs, discussed in the last chapter, the configuration of CBAC is more complicated; there are many more commands with many more options that you either must or can configure.

Following this section, I cover some examples on how you would use CBAC to implement a stateful firewall. Note that this chapter focuses only on the use of CBAC for filtering. I discuss some of CBAC's other inspection features, such as DoS detection and prevention, in Chapter 17.

To simplify the configuration process, I have divided the configuration process into seven simple steps:

Step 1. Determine which interfaces will be internal and external on your router.

Step 2. Create your normal IP ACLs to filter traffic entering and leaving your network. Make sure that you permit the traffic that is to be inspected as it is leaving your network.

Step 3. Change the global timeout values for connections. This is optional.

Step 4. Configure Port Application Mapping (PAM), which specifies the port numbers that CBAC should inspect if the application is using a nonstandard port number, such as HTTP with 8080. This is optional and is required only if your application is using a nonstandard port number.

Step 5. Define your inspection rules. These rules define what entries are added to the state table and what returning traffic is allowed back in. If outbound traffic does not match an inspection rule, the router does not inspect it and treats it as normal traffic.

Step 6. Activate the inspection rule or rules on your router's interface(s). The router then will use CBAC to inspect traffic.

Step 7. Test your configuration by sending traffic through your CBAC router. Even though this is optional, I highly recommend it. The only way that you will find problems is by scrutinizing your configuration and implementation by sending test packets through the router.


Configuring CBAC is not simple. You need to have a very good understanding of how CBAC works, including the inspection process, if you want to reduce the likelihood that you will make configuration mistakes. Configuration mistakes on your part, whether they are inadvertent or the result of trying to get a specific application to work, could open your router and network to security threats. Therefore, take the appropriate amount of time to plan, configure, implement, and test your CBAC policies.

Step 1: Interface Selection

One of the first CBAC tasks that you need to accomplish is to determine which interface is internal and which is external. In this context, internal is where the connections originate, and external is where the returning traffic of these connections will be coming from.


If you will be configuring two-way CBAC?filtering traffic in two directions?I highly recommend that you first configure one-way CBAC and get this to function correctly before adding the second direction. Two-way configurations are common in intranet and extranet environments.

Step 2: ACL Configuration

In Step 2, you configure your ACLs to filter traffic entering and possibly leaving your network. These ACLs contain many of the filtering suggestions covered in Chapter 7, "Basic Access Lists," such as bogon filtering.


My recommendation is first to create a basic ACL configuration that allows the necessary traffic into and out of your network, and then add the bogon and other filters for a more robust security solution. This simplifies your CBAC troubleshooting process. After you add your additional filters, continue by adding CBAC to your configuration. This ensures that you easily can narrow any connectivity issues to either your ACL or your CBAC configuration.

After you have configured your filtering ACLs, you need to activate them on your router's interfaces. However, there is one restriction on the use of ACLs and their applications when using CBAC.

On the external interface inbound and the internal interface outbound, only an extended ACL can be applied. For any other situation, you can use either standard or extended ACLs. This means that, for the internal interface inbound and the external interface outbound, you can use either standard or extended ACLs applied in either direction?in or out. Figure 9-8 displays the appropriate use of ACLs.

Figure 9-8. CBAC and the Application of ACLs

[View full size image]


Unlike RACLs, CBAC's ACLs can be either named or numbered.

Step 3: Global Timeouts

Optionally, you can change the timeout for connections in the state table (and the dynamic ACL entries, before FAB) with the following CBAC inspection commands:

Router(config)# ip inspect tcp synwait-time #_of_seconds

Router(config)# ip inspect tcp finwait-time #_of_seconds

Router(config)# ip inspect tcp idle-time #_of_seconds

Router(config)# ip inspect udp idle-time #_of_seconds

Router(config)# ip inspect dns-timeout #_of_seconds

The ip inspect tcp synwait-time command specifies how long the Cisco IOS waits for a specific TCP session to be established (to complete the three-way handshake). The default is 30 seconds. If the three-way handshake does not complete by the end of this timeout, the Cisco IOS removes the entry from its state table and the dynamic entry in the ACL (before FAB), and it notifies both parties that the connection has been terminated.

The ip inspect tcp finwait-time command specifies how long the Cisco IOS waits to remove an entry from its tables when the source or destination begins the teardown process of a TCP session. The default is 5 seconds. When the Cisco IOS sees that a connection is being torn down, it gives the two devices this time period to tear down the connection before removing the entry from the state table and the corresponding dynamic entry from the ACL (before FAB).

The ip inspect tcp idle-time command specifies how long the Cisco IOS maintains an idle TCP connection in its state table. An idle connection is one that is established but has no traffic traversing it. The default is 3600 seconds (1 hour). When the idle period expires, the Cisco IOS removes the entry from the state table and the corresponding dynamic entry from the ACL (before FAB).

The ip inspect udp idle-time command specifies how long the Cisco IOS maintains an idle UDP connection in its state table. The default is 30 seconds. After the idle period expires, the Cisco IOS removes the UDP entry from the state table and the corresponding dynamic entry from the ACL (before FAB).

The ip inspect dns-timeout command specifies how long the Cisco IOS maintains a DNS query connection in its state table. The default is 5 seconds. When this time period expires, the Cisco IOS removes the DNS query entry from the state table and the corresponding dynamic entry from the ACL (before FAB). This timer supercedes the UDP idle timer. This timer is used to prevent IP spoofing of DNS responses, providing a smaller window for a hacker to spoof DNS responses and, thereby, redirecting an internal device to the wrong service.


It is important to point out that CBAC is stateful for TCP connections, but it must approximate UDP and ICMP connections. It does this for "connectionless" sessions by assigning an idle period to them. Also, there is no global timeout command for ICMP traffic; this is configured on an inspection-by-inspection basis and is discussed later.

Step 4: Port Application Mapping

CBAC uses PAM to determine what type of inspection should be performed on a connection. For example, the default application associated with port 25 is SMTP; therefore, CBAC understands, by default, that e-mail is used on this connection and, consequently, can inspect the connection for the appropriate SMTP commands. As another example, the control connection for FTP is TCP 21. Again, CBAC understands that this is used by FTP and performs the appropriate inspection on this connection.

PAM is used to remap ports to or associate additional ports with a specific application so that CBAC can perform the appropriate inspection on the connection. As an example, you might have a web server running on port 8080. By default, CBAC treats this as a normal TCP connection. To have CBAC inspect the connection and treat it as an HTTP connection, you need to associate port 8080 with HTTP.

PAM is the process used to map nonstandard ports to applications so that CBAC can perform the appropriate type of inspection. PAM can be used to associate either TCP or UDP ports to applications. PAM even enables you to assign ports on a host-by-host basis to a specific application. For example, you might have only one HTTP server running on port 8080. You can use PAM to associate only this port on this server for CBAC HTTP application inspection; any other TCP 8080 port on any other device would be treated as a normal TCP connection. With this feature, you greatly reduce the amount of inspection that CBAC has to perform by limiting it to just those devices using the nonstandard ports.

PAM Table

Port mappings are placed in the PAM table, and CBAC uses this table to perform the appropriate inspection on a connection. Three types of entries are used in this table:

  • System-defined entries? These are the well-known port numbers of applications, such as TCP port 80 for HTTP. These entries cannot be deleted or changed. For example, you cannot assign SMTP port 25 to be inspected on port 80, or HTTP port 80 to 25; however, you can override the system-defined entries on a host-by-host basis (see the last point in this list). Table 9-1 lists the system-defined entries in the PAM table.

    Table 9-1. PAM System-Defined Entries


    Port Number














































    554 and 8559

  • User-defined entries? These are applications running on nonstandard port numbers, such as a web server running on ports 8000 or 8080. You easily can create these entries in the PAM table to accommodate all connections with the specified port number. You also can map ranges of ports to a specific application.

  • Host-specific entries? These are a subset of user-defined entries, where the PAM mapping maps only a connection or connections for a specific host or hosts, but not all connections using the same port number. This enables you to limit the inspection that CBAC does for a specific application. For example, you might have two applications running on port 8080: a web server and a home-grown application. With PAM, you can put an entry in the table for port 8080 for just the web server. This causes CBAC to use HTTP inspection on port 8080 for the web server and normal TCP inspection for 8080 on all other devices.

PAM Configuration

Configuring PAM is necessary only if you are running an application on a nonstandard port and want CBAC to inspect this connection. The configuration is straightforward:

Router(config)# ip port-map application_name port port_# [list acl_#]

First, you must specify the name of the application (supported applications are listed in Table 9-1), followed by the port number. To remap more than one port to an application, repeat the command with the next port number. Optionally, you can associate a standard ACL with the PAM remapping. This standard ACL contains the IP addresses of devices that use the nonstandard port number. Put permit entries in the ACL to match on those devices that use the nonstandard port number and deny entries for those that do not; remember that there is an implicit deny at the end of this ACL. If you omit the ACL, CBAC assumes that any traffic on the specified port should be inspected per the configured application.


I have had issues in the past with different versions of the Cisco IOS when I have updated the PAM table and the Cisco IOS did not accept my changes until I saved my configuration and rebooted the router. If you experience this problem, repeat the process I performed.

PAM Verification

After you have configured your port mappings with PAM, you can view them with any of the following commands:

Router# show ip port-map

Router# show ip port-map application_name

Router# show ip port-map port port_number

Example 9-1 displays the contents of the PAM table.

Example 9-1. Viewing the PAM Table

Router# show ip port-map

Default mapping: dns              port 53           system defined

Default mapping: vdolive          port 7000         system defined

Default mapping: sunrpc           port 111          system defined

Default mapping: cuseeme          port 7648         system defined

Default mapping: tftp             port 69           system defined

Default mapping: https            port 443          system defined

Default mapping: rtsp             port 8554         system defined

Default mapping: realmedia        port 7070         system defined

Default mapping: streamworks      port 1558         system defined

Default mapping: ftp              port 21           system defined

Default mapping: telnet           port 23           system defined

<--output omitted-->

Example 9-1 shows a partial listing of the system-defined entries.

PAM Examples

Now you can take a look at an example where PAM is necessary, using the network shown in Figure 9-9.

Figure 9-9. PAM Example

[View full size image]

Example 9-2 shows the configuration to set up PAM.

Example 9-2. Using PAM and ACLs to Restrict CBAC Inspection

Router(config)# ip port-map http port 8080 list 1

Router(config)# access-list 1 permit

Router(config)# ip port-map http port 8090 list 2

Router(config)# access-list 2 permit

In Example 9-2, is running a web server on port 8080 and is running a web server on port 8090. The first two commands associate port 8080 HTTP inspection with, and the last two commands associate port 8090 HTTP inspection with

Step 5: Inspection Rules

The heart of CBAC is the inspection rules that you define. Inspection rules define what traffic CBAC should inspect. When inspecting traffic, new connections are placed in the state table, and dynamic ACL entries are created (before FAB) to allow for the return of traffic. Inspection can restrict commands executed on a connection, open secondary connections for an application, perform address translation of embedded addressing information, and prevent certain kinds of attacks.


By default, there are no predefined inspection rules: You must create them manually. If you do not define an inspection rule for a particular connection, CBAC does not inspect it and this traffic is treated normally.

Inspection Rule Components

The general syntax of an inspection rule is as follows:

Router(config)# ip inspect name inspection_name protocol

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Inspection rules are created with the ip inspect name command. The syntax of the previous command is used for inspections of all types of traffic, with the exception of Java, URLs, and RPCs (I discuss these later in the following sections).

Rules are grouped with an inspection_name. This name is similar to the name or number used in an ACL: It associates statements with a particular grouping. Normally, you create one grouping of inspection rules because most companies are concerned about providing a stateful function for a two-interface perimeter router. However, if you need to filter traffic between two networks in an intranet or extranet, or if you have a three-interface router configuration, you typically need to create more than one rule set.

Following the name of the inspection is the name of the protocol or application that you want CBAC to inspect (protocol). For protocols and applications, you can specify the following: cuseeme, fragment, ftp, h323, http, icmp, netshow, rcmd (UNIX R commands), realaudio, rpc, rtsp, sip, skinny, smtp, sqlnet, streamworks, tcp, tftp, udp, and vdolive.

Optionally, you can enable or disable alerts and audits on a per-application or per-protocol basis with the alert and audit keywords. If you omit these parameters, CBAC uses the default configuration defined with the ip inspect alert and ip inspect audit-trail commands, respectively. These commands are discussed later in the "Alerts and Audits" section.

The last optional parameter is the timeout parameter. If you omit this, it defaults to the timeout value configured with the commands discussed previously in the "Step 3: Global Timeouts" section.

The following sections discuss some of the most important and most common inspection rules that you can configure with CBAC.

Generic TCP and UDP Inspection

You can configure generic TCP and UDP inspection of connections. With generic inspection, CBAC performs only connection inspection: It adds new connections to the state table and a dynamic ACL entry to the external ACL, and removes this information upon termination or timeout of the connection.

With generic inspection, CBAC does not monitor what actually is occurring on the connection, such as what commands are being executed or whether a secondary connection is being negotiated. However, you can configure specific inspection of an application. When you do this, the application inspection, such as FTP, takes precedence over generic TCP and UDP inspection.


Basically, TCP and UDP inspection is used to allow returning traffic into your network. However, one additional function of generic TCP inspection is that CBAC examines the sequence numbers in returning segments to ensure that they fall within the configured window range.

Also, 99.9 percent of all traffic that a small company needs to pass through a router configured with CBAC can be accomplished with the inspection of generic TCP and UDP connections, as well as FTP, simplifying your CBAC configuration.

TCP and UDP inspection is done with the following two commands:

Router(config)# ip inspect name inspection_name tcp

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Router(config)# ip inspect name inspection_name udp

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

As you can see, setting up inspection for TCP and UDP is simple.


Unlike RACLs, with ip inspect statements, you cannot control what traffic within a connection should or should not be inspected. CBAC inspects all traffic covered by an inspection statement.


If you are using NetMeeting, an H.323 application, you must enable generic TCP inspection as well as H.323 inspection. This is because NetMeeting went beyond the H.323 specification and uses an additional TCP connection that is not defined by H.323. Configuring generic TCP inspection enables CBAC to deal with this additional connection.

ICMP Inspection

As of Cisco IOS 12.2(11)YU and 12.2(15)T, CBAC can inspect ICMP connections. ICMP inspection allows the replies to internal ICMP messages to be returned to the internal device. This is useful when internal network administrators are trying to troubleshoot Layer 3 connectivity problems outside of their network, while still minimizing the exposure from different kinds of ICMP attacks.


One limitation of ICMP inspection is that it cannot inspect traceroute implementations that use UDP; many UNIX implementations of traceroute use UDP. You can get around this problem by either enabling generic UDP inspection or specifying the ICMP option in the traceroute program, if this is supported.

Here is the general syntax for ICMP inspection:

Router(config)# ip inspect name inspection_name icmp

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

The default timeout for the return traffic in an ICMP connection is 10 seconds. You can change this by specifying a different value with the optional timeout parameter in the ip inspect name command. If multiple ICMP messages are sent for the test, the idle timeout starts after the last message.

HTTP Inspection

HTTP inspection can be used in any of the following circumstances:

  • Your HTTP server(s) are running on a nonstandard port, such as 8080.

  • You want to filter Java applets.

  • You want to filter URLs.

To enable inspection for HTTP, use the following configuration:

Router(config)# ip inspect name inspection_name http

  [urlfilter] [java-list standard_ACL_#] [alert {on | off}]

  [audit-trail {on | off}] [timeout seconds]

The urlfilter parameter is used to inspect and filter URLs, and the java-list parameter is used to inspect and filter Java applets. I discuss these two options in much more depth in Chapter 10.

RPC Inspection

On a computer, a procedure is a software component running on a system. In Remote Procedure Calls (RPCs), your computer is accessing a procedure on a different computer. RPCs are popular in UNIX environments, with NFS being one of the most common. Even Microsoft uses some RPCs in its software applications.

CBAC can perform inspection on RPCs with the following command:

Router(config)# ip inspect name inspection_name rpc

  program-number program_number [wait-time minutes]

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Unlike the inspection commands discussed so far, you need to enter the program number of the RPC that you want to inspect. Optionally, you can specify a wait period (wait-time), in minutes, that CBAC should use to keep the temporary entry in the state table. This is used to allow more connections from the source to the same destination and port number (but maybe a different RPC). The default is 0 minutes, meaning that the idle timer is used.

SMTP Inspection

CBAC supports application inspection of SMTP connections using the following command:

Router(config)# ip inspect name inspection_name smtp

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

With the activation of SMTP inspection, CBAC filters the SMTP commands on the e-mail connection. CBAC allows only the SMTP commands defined in IETF RFC 821, Section 4.5, through the router; any other SMTP commands are blocked. The allowed SMTP commands include DATA, EXPN, HELO, HELP, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SEND, SOML, and VRFY.


SMTP inspection does not support ESMTP. Therefore, if you have enabled SMTP inspection, and your internal e-mail server uses ESMTP and is experiencing e-mail connection problems, you should disable SMTP application inspection for this connection.

Fragment Inspection

CBAC also supports the inspection of fragments with the following command:

Router(config)# ip inspect name inspection_name fragment

  max number_of_fragments timeout seconds_to_reassemble

The max parameter specifies the maximum number of fragmented sessions. The default is 256, but you can change this to 50 to 10,000. In other words, this parameter controls the maximum number of sessions that can contain fragments. Setting this to a large value seriously can affect the performance of the router because it must store all the fragments for these sessions.

The timeout parameter specifies for how many seconds the Cisco IOS stores fragments for a session while trying to determine whether the fragments can be reassembled into a packet. The default is 1 second. If the router does not receive all the fragments for a reassembled packet within this time period, CBAC drops the fragments. The Cisco IOS automatically can adjust the timeout value during periods of heavy loads. It does this by examining the number of free connection entries specified by the maximum in the max parameter. If there are fewer than 32 connection states, the Cisco IOS divides the time period by half. If there are fewer than 16 connection states, the Cisco IOS automatically changes the time interval to 1 second.


CBAC expects a fragmented packet to arrive in order: The first fragment in the packet should arrive first. If the first fragment is not received first, the Cisco IOS drops the fragments. This can cause problems if an operating system, such as Linux, sends fragments out of order. In the Linux case, the fragments are sent in reverse order. In addition, if load balancing is used between the source and you, the fragments also might arrive out of order. Therefore, I recommend that you not use this inspection feature unless you are under a DoS fragmentation attack: Then enable it.

Skinny Inspection

Skinny inspection is needed only if you are using the Cisco VoIP solution with CM. You need to configure two possible commands:

Router(config)# ip inspect name inspection_name skinny

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Router(config)# ip inspect name inspection_name tftp

  [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

The first command (skinny parameter) is required: It causes CBAC to inspect TCP port 2000 Skinny connections. If you use a TFTP server to download configuration information to your IP phones, you also need to enable inspection for TFTP, which the second configuration command does.


There is a configured inactivity timeout for the connection between the IP phone and CM. It is important for the timeout value that you specify in your Skinny inspection to be greater than the IP phone?CM timeout period; otherwise, you inadvertently might disconnect an IP phone client. CBAC uses the default timeout for TCP connections for Skinny unless you override them with the timeout value parameter (3600 seconds). When CBAC closes a Skinny connection because of inactivity, it sends a TCP RST message to both ends, indicating that the session is being closed. Any phone connections that the IP phone has active will remain active; however, when the user hangs up the phone, the IP phone connection eventually times out after its idle period expires.

Step 6: Inspection Activation

After you have created your inspection rules, you must activate them on your router. As with ACLs, this is done on a router's interface. The ip inspect command is used to activate the inspection rule:

Router(config)# interface type [slot_#]port_#

Router(config-if)#  ip inspect inspection_name {in | out}

With the ip inspect command, you need to specify the name of the inspection rule grouping, as well as the direction in which you want CBAC to inspect traffic: in specifies that inspection of traffic is done as traffic enters the interface, and out specifies that it is done as traffic leaves an interface.

The most common implementation of inspection is to activate the inspection rules on the external interface in the outbound direction. This causes CBAC to build temporary ACL entries on the external interface's inbound extended ACL (assuming that your Cisco IOS does not support FAB). If you apply the CBAC inspection rules on an internal interface, you first need to make sure that, for internal traffic, your internal ACL allows the inspected traffic into the router. Second, you activate the inspection rules in the inbound direction, which builds dynamic ACL entries for the extended ACL applied outbound on the outside interface (again, assuming that your Cisco IOS does not support FAB).

Typically, you activate your inspection rules on only one interface on your router. The exception to this is when you need to inspect traffic in two directions, such as in an intranet or extranet environment.

Step 7: Troubleshooting CBAC

After you have configured CBAC, you have three options for monitoring the CBAC inspection process and assisting you in troubleshooting problems:

  • show commands

  • debug commands

  • Alerts and audits

The best way to test CBAC is to initiate a connection that you know CBAC has been configured to inspect, and then use these tools to verify the inspection process. The following three sections cover these three tools.

show commands

CBAC supports many show commands that you can use to view the temporary ACL entries created from the information in the state table, as well as the state table and the operation of CBAC. To view information about CBAC inspection information, use the show ip inspect command:

Router# show ip inspect [parameter]

Table 9-2 displays the optional parameters that you can include with this command.

Table 9-2. show ip inspect Parameters



name inspection_name

Limits the output of the display to only the inspection rule set that you specified


Displays the complete CBAC inspection configuration on the router


Displays the inspection rules activated on your router's interface(s)


Displays a summary of the connections in the CBAC state table

session [detail]

Displays all the details for connections in the CBAC state table


Displays all the information from the options listed in this table

To examine your ACLs, use the following commands:

  • show ip interface

  • show access-list

  • show ip access-list

These commands were discussed in Chapter 7.


The important thing to point out about displaying ACLs is that you see both the dynamic CBAC ACL entries (before FAB) and the static entries that you configured in the associated named or numbered extended ACL.

Now take a look at a couple of show ip inspect commands. Example 9-3 shows output from the show ip inspect name inspect_outbound command.

Example 9-3. Using the show ip inspect name Command

Router# show ip inspect name inspect_outbound

show ip inspect name inspect_outbound

Inspection name inspect_outbound

  tcp alert is on audit-trail is off timeout 3600

  udp alert is on audit-trail is off timeout 30

In the Example 9-3, you can see the inspection rules configured for the inspection rule set called inspect_outbound. With this rule set, TCP and UDP traffic is being inspected, both with their default idle timeouts.

To view the CBAC state table, use the command in Example 9-4.

Example 9-4. Viewing the CBAC State Table

Router# show ip inspect sessions

Established Sessions

 Session 25A3378 (>( ftp-data SIS_OPEN

 Session 25A5AC2 (>( ftp SIS_OPEN

In this example, there are two entries in the state table: is inside the network, and is outside. The second entry shows the internal device opening a connection to an external FTP server. The first connection displays the data connection that the FTP server opened back to the internal client. Example 9-5 shows the CBAC dynamic ACL entries created in the inbound extended ACL.

Example 9-5. Displaying CBAC Dynamic ACL Entries Before FAB

router# show ip access-list

Extended IP access list 100

 permit tcp host eq 21 host eq 32703 (24 matches)

 permit tcp host eq 20 host eq 32704 (88 matches)

<--output omitted-->

As you can see from this output, there are two reversed ACL entries to allow the traffic from the FTP server to be sent to the initiating FTP internal client.

Now look at an example of the same internal client opening an H.323v2 connection to an external H.323 server. Example 9-6 shows the entries in the state table on the router.

Example 9-6. Viewing the CBAC State Table for H.323v2

Router# show ip inspect session

Session 615E2688 (>( H323-RTCP-audio SIS_OPEN

Session 615E2688 (>( H323-RTP-audio SIS_OPEN

Session 615E2688 (>( H323-RTP-video SIS_OPEN

Session 615E2688 (>( H323-RTCP-video SIS_OPEN

Session 615E1640 (>( H323 SIS_OPEN

In this example, you can see all of the H.323 connections set up to download the video and audio streams from the H.323 server application. Example 9-7 shows the ACL entries created from these entries in the state table with a Cisco IOS that does not support FAB.

Example 9-7. H.323 CBAC Dynamically Added Entries

Router# show ip access-lists

Extended IP access list 100

 permit udp host eq 43509 host eq 39509 (12 matches)

 permit udp host eq 43408 host eq 39408 (381 matches)

 permit udp host eq 43311 host eq 39311 (16 matches)

 permit udp host eq 43510 host eq 39510 (4938 matches)

 permit tcp host eq 1720 host eq 10001 (39 matches)

<--output omitted-->


I like to use one other show command, but it is a hidden command (I do not know why). The show ip inspect stat command is great for checking out the current, maximum ever, and other counts for connections that CBAC has seen.

debug commands

For more detailed troubleshooting of CBAC, you can use debug commands. With debug commands, you can see, in real time, the operation of CBAC on your router. Here is the format of the debug command for inspection:

Router# debug ip inspect parameter

Table 9-3 lists the parameters for this debug command. Here is the list of application names that you can specify for inspection: cuseeme, dns, ftp-cmd, ftp-token, h323, http, netshow, rcmd, realaudio, rpc, rtsp, sip, skinny, smtp, sqlnet, streamworks, tftp, and vdolive.

Table 9-3. debug ip inspect Parameters




Displays TCP inspection events


Displays UDP inspection events


Displays ICMP inspection events


Displays inspection events for the specified application, such as TFTP or SMTP


Displays CBAC events, including the processing of packets


Displays information about an entry being added to the state table


Displays information about an entry being removed from the state table


Displays information about the software functions that CBAC calls


Displays information related to CBAC timers, such as information that the TCP or UDP idle timers are reached


Displays information about all the CBAC processes on the router

Alerts and Audits

CBAC inspection supports two types of logging functions: alerts and audits. The following two subsections explain how these function and how they are configured.


Alerts display messages concerning the operation of CBAC, such as insufficient router resources, DoS attacks, and other threats. Alerts are enabled by default and automatically display on the router's console line. To globally disable alerts, use this command:

Router(config)# ip inspect alert-off

Remember that you also can disable and enable alerts per inspection rule.


I highly recommend that you leave alerts enabled. Alerts are useful because they can notify you of network attacks, such as an attack against your e-mail server.

Here is an example of someone trying to send an unapproved SMTP command to an e-mail server:

%FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator


CBAC can detect a small number of SMTP attacks besides the use of invalid commands, including these:

  • Someone trying to send a pipe (|) in the To or From fields of the e-mail message

  • Someone trying to send :decode@ in the e-mail header

  • Someone trying to use the old SMTP wiz or debug commands on the SMTP port

  • Someone trying to execute arbitrary commands to exploit a bug in the Majordomo e-mail program

Here is an example of an alert being generated when a hacker tries to exploit the SMTP Majordomo bug:

02:04:55: %FW-4-TCP_MAJORDOMO_EXEC_BUG: Sig:3107:

  Majordomo Execute Attack - from to


Auditing keeps track of the connections that CBAC inspects, including valid and invalid access attempts. For example, you can see messages when CBAC adds or removes an entry from the state table. The audit record gives some basic statistical information about the connection. Auditing is disabled by default but can be enabled with the following command:

Router(config)# ip inspect audit trail

Here is an example audit message from CBAC:

%FW-6-SESS_AUDIT_TRAIL: tcp session

  initiator ( sent 22 bytes

  responder ( sent 200 bytes

In this example, an audit trail is being created from a Telnet connection initiated from


By default, when alerts and audits are enabled, they display messages on the console line. However, you can log this information to other locations, including the router's internal buffer or an external syslog server. These logging concepts are discussed in Chapter 18.

CBAC Removal

If you no longer want to use CBAC on your router, remove it with the following configuration command:

Router(config)# no ip inspect

This command causes the Cisco IOS to remove all CBAC commands, remove the state table, and remove all temporary ACL entries created by CBAC. This command also resets all timeout and threshold values to their factory defaults.


Disabling CBAC causes all inspection processes to cease. When this is done, the Cisco IOS cannot detect certain kinds of attacks, such as some types of SMTP- and Java-based attacks.