Configuring CBAC

This section will discuss the configuration of CBAC.

Several steps are required to make CBAC effectively secure the corporate network:

Each of these will be discussed in turn.

Choose an Interface

The first step of configuring CBAC poses the administrator with a dilemma: Should CBAC be configured on the inside or outside interface? Should a demilitarized zone (DMZ) be created? No matter what configuration is ultimately chosen, one direction should always be configured first. Only after this configuration is thoroughly tested should a second interface be added.

The outside interface is the interface that connects to the Internet. An inside interface is an interface that connects directly to the corporate LAN. A DMZ is a network that is owned and controlled by a company and is not directly connected to either the Internet or the company LAN.

The most common configuration is shown in Figure 5-8. In this configuration, the CBAC is enabled on the external interface to prevent unauthorized access into the corporate network. In this configuration example, the only traffic allowed in from the Internet is in response to traffic initiated within the corporate network.

Figure 5-9 shows a different and slightly more complex configuration. In this configuration you build a DMZ to allow some access from the Internet to services provided to the general public. Examples of these services could include DNS, Web, or FTP servers.

When enabling CBAC as in the example in Figure 5-9, configure it on the internal Ethernet 0 interface. This method allows access to the DMZ from the Internet while still allowing access to the internal network in response to sessions initiated from within the corporate network.

No matter which interface is chosen for CBAC configuration, some basics regarding applying access lists in relation to CBAC need to be discussed.

Configure IP Access Lists on the Interface

To maximize the benefits of CBAC, IP access lists need to be correctly configured. Some general rules should be followed when designing access lists for use with CBAC:

• Start with the basics. Make the initial access list as simple as possible and expand after it is thoroughly tested.

• Permit those protocols you wish CBAC to inspect to leave the network. For example, if TFTP traffic is prohibited from leaving the network, CBAC will never evaluate TFTP traffic.

• Deny returning CBAC traffic from entering through the router through an extended access list. This may sound wrong at first, but CBAC will create the temporary holes to allow data through in response to a valid request.

• Do not initially configure an access list preventing traffic from the internal side to the external side of the network. All traffic should flow freely out of the network until CBAC is fully functional. This is invaluable for troubleshooting purposes.

• Allow ICMP messages to flow freely in the initial configuration. ICMP traffic is not inspected by CBAC, therefore, entries are needed in the access list to permit return traffic for ICMP commands.

• Add an access list entry denying any network traffic from a source address matching an address on the protected network. This should really be done on all routers.

• An outbound access list on an external interface should permit traffic that you want to be inspected by CBAC. If traffic is not permitted, it will be dropped before getting to the CBAC.

• The inbound IP access list at the external interface must deny traffic destined to be inspected by CBAC.

• The inbound IP access list at the internal interface must permit traffic destined for inspection by CBAC.

In essence, you need to allow the CBAC to see the packets from the trusted side of the network. You also need to prevent returning packets and rely on CBAC to allow them to traverse the interface.

Configure Global Timeouts and Thresholds

CBAC uses timeouts and thresholds in conjunction in order to determine how long to manage state information for a session. Timeouts and thresholds are also used to determine when to drop sessions that are not fully established. Because timeouts and thresholds are so closely related, they are usually configured at the same time. These are global, so they apply to all CBAC configurations on the router.

The easiest way to configure the timeouts and thresholds is simply to use the default values. In this case, no changes to the configuration are necessary. However, this section will still explore timeouts and thresholds in case optimizations are necessary based on your individual corporate needs.

All of the threshold and timeouts available for changing, as well as their default values and a short description of the effect when they are changed, are listed in Table 5-3.

As with most commands, the timeout and threshold commands can be reset to the default by entering the no form of the command.

Define Inspection Rules

After the timeouts and thresholds are set, the inspection rules are defined. The inspection rules delineate which packets will be inspected by CBAC for a given interface. Unless you are configuring two separate interfaces both to use CBAC, only a single inspection rule is defined. The inspection rules define which application-layer protocols relying on IP will be inspected by CBAC. The inspection rules also include options for audit trail messages, alert messages, and packet fragmentation.

Two variations of the ip inspect name command are available for setting inspection of an application-layer protocol. The following are the two variations:

							ip inspect name
							inspection-name protocol [alert {on | off}]
    [audit-trail {on | off}] [timeout
							seconds]

and

							ip inspect name
							inspection-name
							rpc program-number
							number [wait-time
							minutes]
    [alert {on | off}] [audit-trail {on | off}] [timeout
							seconds]

The first instance of the command configures CBAC inspection for application-layer protocols, except for RPC and Java. The protocol keywords will be discussed in the next section. This command is repeated for each desired protocol, using the same inspection name each time. If more than one interface is using CBAC, this command is repeated for each protocol used with each interface, associating one name for each interface.

The second variation is used to enable CBAC inspection for the RPC application-layer protocol. As with the first instance, this command is specified multiple times, once for each program number.

Protocol Keywords

Table 5-4 contains a list of the keywords used for the protocol argument in the ip inspect name command.

A note concerning Microsoft NetMeeting 2.0: NetMeeting is an H.323 application-layer protocol that operates slightly outside of the normally accepted mode. Specifically, NetMeeting uses an additional TCP channel that is not defined within the H.323 specifications. To use NetMeeting and CBAC effectively, TCP inspection must also be enabled.

Java Blocking

CBAC filters Java applets by relying on a list of sites designated as friendly. In this method, a Java applet from a friendly site is allowed through, while all others are blocked. Java applets from sites other than friendly ones are not allowed through. The ip inspect-name command is used to block Java applets:

								ip inspect name
								inspection-name
								http [java-list
								access-list]
    [alert {on | off}] [audit-trail {on | off}] [timeout
								seconds]

Use the same inspection-name as the other protocols checked by CBAC, unless you intend to use CBAC on more than one interface. CBAC does not detect or block Java applets that are encapsulated within another format. CBAC also does not detect or block Java applets loaded through HTTP on a nonstandard port or through the use of FTP, Gopher, or any other protocol where it cannot be determined that the Java applet is within the data.

Fragmentation Inspection

CBAC can be used to help protect against DoS attacks that use fragmented packets by maintaining an interfragment state table for IP packets. When a packet is received that has the fragment bit set, is not the first packet of a sequence of packets, and is not received in the proper order, CBAC will drop the packet.

This can cause problems in situations where it would normally be acceptable to accept packets out of order. When the sending host fails to receive an acknowledgement that all packets were received, another set of packets is sent. This can affect performance extremely. If it is acceptable to receive packets out of order, the default settings should be left as they are. If, however, receiving packets out of order is unacceptable, use the following form of the ip inspect name command:

								ip inspect name
								inspection-name
								fragment [max
								number
								timeout
								seconds]

Generic TCP and UDP

Inspecting TCP and UDP packets is possible even if the application-layer protocol has not been configured for inspection. Doing this, however, means that CBAC does not recognize commands that are specific to the application. In this case, CBAC does not necessarily allow all packets of an application through the interface. This usually happens when the returning packets have a different port number than that associated with the packet previously sent out this interface. Because a defined application-layer protocol takes precedence over the TCP or UDP packet inspection, the more protocols that are defined, the less likely that this problem will be seen.

When using TCP and UDP inspection, packets attempting to enter the network must match the corresponding packet that previously exited the network in the source and destination addresses and ports. Failure to match results in the packet being dropped. UDP packets must also be received within the time specified by the ip inspect udp idle-time command. TCP packets must have the proper sequence number before being allowed to enter the interface. Inspection of TCP and UDP packets is enabled with the following commands:

								ip inspect name
								inspection-name
								tcp [timeout
								seconds]

ip inspect name
								inspection-name
								udp
								[timeout
								seconds]
							

The next step in the configuration process is to configure logging and the audit trail.

Configure Logging and Audit Trail

Turning on logging and audit trails provides a record of all access through the firewall. Logging and audit trails are extremely simple to implement. The following is a small sample configuration that turns on both logging and audit trails:

service timestamps log datetime
!Adds the date and time to syslog and audit messages
logging 172.30.1.8
!Specifies that syslog messages are sent to 172.20.1.8
logging facility syslog
!Configures the syslog facility in which error messages are sent
!Valid options instead of syslog are: auth, cron, kern, local0-7, lpr, mail,
!news, sys9, sys10, sys11, sys12, sys13, sys14, daemon, user, and uucp.
logging trap 7
!Sets logging to level 7 (informational)
ip inspect audit-trail
!Turns on CBAC audit trail messages

CBAC Configuration Example

In the configuration example at the end of this section, a company, Bigg Incorporated, has a connection to a parts distributor on the 10.1.1.0/24 network through interface Serial 0.1. It also has a connection to one of its branch offices through interface Serial 0.2. The branch office is running on network 172.31.1.0/24. Figure 5-10 shows a logical view of these connections.

Because Bigg Inc. has no control over the network practices at the parts distributor, it enabled CBAC security between its main site and the distributor. All information exchanges, with the exception of ICMP messages, are denied by default. When a connection is initiated from within the corporate network, the CBAC will evaluate and allow a connection to be made.

In this configuration, Bigg Inc. set the CBAC to examine seven protocols and set the timeout on each to 30 seconds. Next, the company created an extended access list numbered 111. This access list, working in conjunction with CBAC, allows only ICMP messages through, unless the connection is initiated from within the network.

Bigg Inc. has added a named access list to the inbound and outbound sides of the serial interface connected to the branch office. This access list, in conjunction with the reflect statement, prevents all traffic from going to the branch office, except when in response to a session initiated from within the branch. Bigg Inc. could have added this prevention within the extended access list. However, this configuration illustrates how you can use CBAC on one interface without interfering with any other interface.

Interface Serial 0.1, which connects to the distributor's office, is set up with an IP address, an access list, and a call to the CBAC to inspect outgoing packets. Bigg Inc. allows HTTP (Web server) access to the host at 10.1.1.34 for ports 80 (the default) and ports 8001, 8002, 8003, and 8004.

Interface Serial 0.2 is then set up with an IP address and a standard access list that limits packets to the 172.31.1.0/24.

Finally, Bigg Inc. set up an Ethernet interface that connects to the local network and the static IP routes. The company could alternatively use a routing protocol instead of static routes.

The following is the configuration:

ip port-map http 8001
ip port-map http 8002
ip port-map http 8003
ip port-map http 8004
!Sets HTTP to equal ports 8001, 8002, 8003 and 8004 in addition
!to the default port 80


ip inspect name test cuseeme timeout 30
ip inspect name test ftp timeout 30
ip inspect name test h323 timeout 30
ip inspect name test realaudio timeout 30
ip inspect name test rpc program-number 100000
ip inspect name test streamworks timeout 30
ip inspect name test vdolive timeout 30
time-range httptime
periodic weekday 08:00 to 17:00
!Set the httptime to occur between 08:00 and 17:00
!(8 a.m. till 5 p.m.) on weekdays

access-list 111 permit ip any host 10.1.1.34 eq http time-range httptime
!Because they added a port map earlier, this allows the new ports
!to have http access as well as the default port.  Additionally, they
!limit HTTP access to weekdays (mon-fri) at certain hours
access-list 111 deny TCP any any
access-list 111 deny UDP any any
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any 172.30.1.0 0.0.0.255 time-exceeded
access-list 111 permit icmp any 172.30.1.0 0.0.0.255 packet-too-big
access-list 111 permit icmp any 172.30.1.0 0.0.0.255 traceroute
access-list 111 permit icmp any 172.30.1.0 0.0.0.255 unreachable
access-list 111 deny ip any any


ip access list extended inbound
evaluate packetssent
!The only packets allowed to enter are in response to connections
!initiated from within the corporate network
deny ip any any

ip access list extended outbound
permit tcp any any reflect packetssent timeout 90
permit udp any any reflect packetssent timeout 60
permit icmp any any reflect packetssent timeout 30
permit ip any any

interface s0.1
ip address 192.168.1.1 255.255.255.252
ip access-group 111 in
ip inspect test out

interface s0.2
ip address 192.168.1.5 255.255.255.252
ip access-group inbound in
!Set the named access list "inbound" to packets entering the
!interface
ip access-group outbound out
!Set the named access list "outbound" to packets leaving the
!interface for use with the reflect statement

interface e0
ip address 10.1.1.1 255.255.255.0

ip route 172.30.1.0 255.255.255.0 192.168.1.2
ip route 172.31.2.0 255.255.255.0 192.168.1.6