158 Chapter 5 Context-Based Access Control Configuration

Defining Inspection Rules

The inspection rules are what you use to define the applications and traffic types that you want to be inspected. Basically, this comes down to a named list that can have multiple lines, similar to an ACL. Most of the time you configure only a single inspection rule on a router, but if you’re applying CBAC in two directions, you’ve got to create two inspection rules. You’ll be creating a single inspection rule and applying it in a single direction for our corporate network example.

You should list all the applications that you want CBAC to monitor in the inspection rule. Generic TCP or UDP traffic is also allowed here. I’ve named the inspection rule IOSFW. Here it is on the Lab_B router:

Lab_B#conf t

Lab_B(config)#ip inspect name IOSFW ?

Lab_B(config)#ip inspect name IOSFW ftp

Lab_B(config)#ip inspect name IOSFW h323

Lab_B(config)#ip inspect name IOSFW http

Lab_B(config)#ip inspect name IOSFW tcp

Lab_B(config)#ip inspect name IOSFW udp

Lab_B(config)#^Z

Lab_B#

You can see here that this inspection rule is configured to inspect three protocols—FTP, H323, and HTTP—plus all generic TCP and UCP traffic. If you want, you can include parameters for each protocol that control alerts, audit trails, and timeouts, as in the following example.

Lab_B(config)#ip inspect name IOSFW http alert on audit-trail on

Lab_B(config)#^Z

Lab_B#

The ability to define inspection rules is important because there are several types of applications that have special inspection features. For example, when configuring Java applet filtering, you can use ACLs to specify trusted applet sources such as these:

Lab_B#conf t

Lab_B(config)#ip inspect name IOSFW http java-list 10 alert on

Lab_B(config)#access-list 10 permit 172.16.2.0 0.0.0.255

Lab_B(config)#access-list 10 permit deny any

Lab_B(config)#^Z

Lab_B#

If the applet comes from a trusted site, as specified by the ACL, CBAC allows it through. If not, the applet is stripped. There are also specific inspection rules for IP packet fragmentation, RPC, and SMTP that you can apply to prevent certain types of attacks.

You’re almost there! With the inspection rules defined, you’re ready for the second-to-last step: applying the inspection rules and ACLs to interfaces.

Applying Inspection Rules and ACLs to Router Interfaces

Let’s review what you set out to accomplish in the corporate network example and check your progress. You have a perimeter router (Lab_B) that you’ve been placing CBAC on, and you’ve configured alerts and audit trails, global timeouts, PAM, and an inspection rule. Check! But you

160 Chapter 5 Context-Based Access Control Configuration

still need to allow access from the external network to the web server and the DNS server on appropriate ports. In addition, you need to allow your internal users to access the protocols you configured into your inspection rule, as well as give them general TCP and UDP services.

CBAC must be used in conjunction with ACLs. Remember, your inspection rule was to permit your internal clients dynamic access to specified protocols and to generic TCP and UDP services on the external network, while protecting them from any unwanted attacks. Cisco recommends the following guidelines for applying rules and ACLs to interfaces:

On the interface where traffic initiates (in the corporate network example, the dirty DMZ):

Apply an ACL inward that permits only wanted traffic.

Apply the CBAC inspection rule in the inward direction that inspects wanted traffic.

On all other interfaces:

Apply an ACL in the inward direction that denies all other traffic except for traffic types not inspected by CBAC such as ICMP.

Let’s go ahead and do this on the Lab_B router using the following commands:

Lab_B#conf t

Lab_B(config)#access-list 150 permit ip 172.16.1.0 0.0.0.255 any

Lab_B(config)#access-list 150 deny ip any any

Lab_B(config)#int f0/0

Lab_B(config-if)#ip inspect IOSFW in

Lab_B(config-if)#ip access-group 150 in

Lab_B(config-if)#^Z

Lab_B#

So far, so good. You’ve defined an access list for the interface where traffic initiates that permits wanted traffic (the internal 172.16.1.0 network addresses—you’re assuming that the firewall is NATing other internal traffic). You’ve applied this ACL inbound on the internal interface and applied the CBAC inspection rule inbound on this same interface. So now let’s protect that external interface using the following commands:

Lab_B#conf t

Lab_B(config)#access-list 151 permit tcp any host 172.16.1.2 eq www

Lab_B(config)#access-list 151 permit udp any host 172.16.1.3 eq domain

Lab_B(config)#access-list 151 deny ip any any

Lab_B(config)#int s1/0

Lab_B(config-if)#ip access-group 151 in

Lab_B(config-if)#^Z

Lab_B#

If you aren’t familiar with CBAC, you might not like the looks of this—didn’t you just block everything coming in from the Internet except requests to the web server and the DNS server? The access-list 151 certainly makes it look as if you did! But remember that CBAC is listening to all incoming traffic on F0/0. So when user requests to the Internet arrive there, CBAC,

Introduction to CBAC Configuration 161

knowing those requests require responses, temporarily changes the ACL (151) to permit conversation between the local hosts and the Internet host. Once the conversation is over (or times out), CBAC removes the changes.

Suppose that a host on the Internet tries to access a local machine other than the web server or the DNS server. The request arrives at interface S1/0, but CBAC has no record of an open session between an internal host and that particular Internet host, and so it hasn’t changed the ACL. That packet is denied because the only exceptions to the ACL that will be allowed are those entered by CBAC. Any bad guys who try to make it seem as though they have an established TCP connection when they don’t will simply have their packets dropped!

The only items allowed in from the Internet are those allowed by ACL 151, which by default, allows access to the web server and the DNS server. CBAC adds entries so that servers contacted by your internal users can respond to user requests. But when your internal users aren’t accessing Internet services, CBAC leaves your network locked up tight!

Did I mention that it’s possible to configure both internal and external CBAC on the same router? Cool, huh?

Configuring IP ACLs at the Interface

For CBAC to work properly, you’ve got to have an ACL in place. Because CBAC dynamically makes changes to the ACL to permit the specific conversations it sees—you can see them too with the show ip access list command—the ACL needs to be an extended ACL. In the preceding example, you used access-list 151. You may need to have additional permit entries to allow traffic types that CBAC can’t predict, such as ICMP, for example.

Testing and Verifying CBAC

As with most IOS commands, there is a set of show and debug commands that allow you to test and verify the operation of CBAC. You can use the following commands to display CBAC operation:

The show ip inspect config command displays information about the entire global timeouts and thresholds configuration for CBAC as well as the inspection rule configuration, excluding interface information.

Lab_B#show ip inspect config

Session audit trail is enabled

Session alert is enabled

one-minute (sampling period) thresholds are [400:500] connections max-incomplete sessions thresholds are [400:500]

max-incomplete tcp connections per host is 50. Block-time 0 minute. tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec

tcp idle-time is 3600 sec -- udp idle-time is 30 sec dns-timeout is 5 sec

Inspection Rule Configuration

162 Chapter 5 Context-Based Access Control Configuration

Inspection name IOSFW

ftp alert is on audit-trail is on timeout 3600 h323 alert is on audit-trail is on timeout 3600

http java-list 10 alert is on audit-trail is on timeout 3600 tcp alert is on audit-trail is on timeout 3600

udp alert is on audit-trail is on timeout 30

The show ip inspect interfaces command displays information about the interface configuration.

Lab_B#show ip inspect interfaces

Interface Configuration

Interface FastEthernet0/0

Inbound inspection rule is IOSFW

ftp alert is on audit-trail is on timeout 3600 h323 alert is on audit-trail is on timeout 3600

http java-list 10 alert is on audit-trail is on timeout 3600 tcp alert is on audit-trail is on timeout 3600

udp alert is on audit-trail is on timeout 30 Outgoing inspection rule is not set

Inbound access list is 150

Outgoing access list is not set

The show ip inspect name command displays information about the inspection rule configuration.

Lab_B#show ip inspect name IOSFW

Inspection name IOSFW

ftp alert is on audit-trail is on timeout 3600 h323 alert is on audit-trail is on timeout 3600

http java-list 10 alert is on audit-trail is on timeout 3600 tcp alert is on audit-trail is on timeout 3600

udp alert is on audit-trail is on timeout 30 Lab_B#

And you can remove any and all CBAC by doing the following:

Lab_B#conf t

Lab_B(config)#no ip inspect

Lab_B(config)#^Z

Lab_B#show ip inspect interfaces

Lab_B#

If you do this, you’ll wipe out all dynamic ACLs, reset all global timeouts, and delete all existing sessions—so be careful!