After you configure global timeouts and
thresholds, you must define an inspection rule. This rule specifies
what IP traffic (which application-layer protocols) will be
inspected by CBAC at an interface. Normally, you define only one
inspection rule. 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 configure
two rules, one for each direction.
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:
Configuring Application-Layer Protocol Inspection
This section provides instructions for configuring CBAC.
Note: For CBAC inspection to work with NetMeeting 2.0
traffic (an H.323 application-layer protocol), you must also
configure inspection for TCP, as described later in the section
"Configuring Generic TCP and UDP Inspection." This
requirement exists because NetMeeting 2.0 uses an additional TCP
channel not defined in the H.323 specification.
Configuring Application-layer Protocols
To configure CBAC inspection for an application-layer protocol,
use one or both of the global configuration commands in Figure
.
Figure
identifies application protocol keywords..
Configuring Java Inspection
Java applet filtering distinguishes between trusted and untrusted
applets by relying on a list of external sites that you designate as
"friendly." If an applet is from a friendly site, the
firewall allows the applet through. If the applet is not from a
friendly site, the applet will be blocked. (Alternately, you could
permit applets from all external sites except for those you
specifically designate as hostile.)
To block all Java applets except for applets from friendly
locations, use the global configuration commands in Figure
.
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 from
FTP, gopher, HTTP on a nonstandard port, and so forth.
Configuring IP Packet Fragmentation Inspection
CBAC inspection rules can help protect hosts against certain DoS
attacks involving fragmented IP packets.
Using fragmentation inspection, the firewall maintains an interfragment
state (structure) for IP traffic. Noninitial fragments are
discarded unless the corresponding initial fragment was permitted to
pass through the firewall. Noninitial fragments received before the
corresponding initial fragments are discarded.
Note: Fragmentation inspection can have undesirable
effects in certain cases, because it can result in the firewall
discarding any packet whose fragments arrive out of order. There are
many circumstances that can cause out-of-order delivery of
legitimate fragments. Applying fragmentation inspection in
situations where legitimate fragments, which are likely to arrive
out of order, might have a severe performance impact.
Because routers running Cisco IOS software are used in a 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 disabled by default.
Fragmentation detection must be explicitly enabled for an inspection
rule using the
global
configuration command in Figure
.
Repeat this command for each named inspection rule in which you
want to inspect IP fragments.
Configuring Generic TCP and UDP Inspection
You can configure TCP and UDP inspection to permit TCP and UDP
packets to enter the internal network through the firewall, even if
the application-layer protocol is not configured to be inspected.
However, TCP and UDP inspection do not recognize
application-specific commands, and therefore might not permit all
return packets for an application, particularly if the return
packets have a different port number than the previous exiting
packet.
Any application-layer protocol that is inspected will take
precedence over the TCP or UDP packet inspection. For example, if
inspection is configured for FTP, all control channel information
will be recorded in the state table, and all FTP traffic will be
permitted back through the firewall if the control channel
information is valid for the state of the FTP session. The fact that
TCP inspection is configured is irrelevant 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