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.

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.

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.

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]

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.

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

  Application	Port Number
  ftp	21
  telnet	23
  smtp	25
  dns	53
  tftp	69
  http	80
  sunrpc	111
  msrpc	135
  https	443
  exec	512
  login	513
  shell	514
  sql-net	1521
  streamworks	1558
  h323	1720
  netshow	1755
  skinny	2000
  mgcp	2427
  sip	5060
  vdolive	7000
  realmedia	7070
  cuseeme	7648
  rstp	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.

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 192.1.1.2

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

Router(config)# access-list 2 permit 192.1.1.3

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

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.

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.

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.

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.

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.

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.

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.

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

Parameter	Explanation
name inspection_name	Limits the output of the display to only the inspection rule set that you specified
config	Displays the complete CBAC inspection configuration on the router
interfaces	Displays the inspection rules activated on your router's interface(s)
session	Displays a summary of the connections in the CBAC state table
session [detail]	Displays all the details for connections in the CBAC state table
all	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.

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 (200.1.1.1:20)=>(192.1.1.2:32704) ftp-data SIS_OPEN

 Session 25A5AC2 (192.1.1.2:32703)=>(200.1.1.1:21) ftp SIS_OPEN

In this example, there are two entries in the state table: 192.1.1.2 is inside the network, and 200.1.1.1 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 200.1.1.1 eq 21 host 192.1.1.2 eq 32703 (24 matches)

 permit tcp host 200.1.1.1 eq 20 host 192.1.1.2 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 (192.1.1.2:38509)=>(200.1.1.2:38509) H323-RTCP-audio SIS_OPEN

Session 615E2688 (192.1.1.2:38408)=>(200.1.1.2:38408) H323-RTP-audio SIS_OPEN

Session 615E2688 (192.1.1.2:38310)=>(200.1.1.2:38310) H323-RTP-video SIS_OPEN

Session 615E2688 (192.1.1.2:38511)=>(200.1.1.2:35611) H323-RTCP-video SIS_OPEN

Session 615E1640 (192.1.1.2:10001)=>(200.1.1.2:1720) 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 200.1.1.2 eq 43509 host 192.1.1.2 eq 39509 (12 matches)

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

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

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

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

<--output omitted-->

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

Parameter	Explanation
tcp	Displays TCP inspection events
udp	Displays UDP inspection events
icmp	Displays ICMP inspection events
application_name	Displays inspection events for the specified application, such as TFTP or SMTP
events	Displays CBAC events, including the processing of packets
object-creation	Displays information about an entry being added to the state table
object-deletion	Displays information about an entry being removed from the state table
function-trace	Displays information about the software functions that CBAC calls
timers	Displays information related to CBAC timers, such as information that the TCP or UDP idle timers are reached
detailed	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

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.

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

  (200.5.5.5:49387)

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 200.5.5.5 to 192.1.1.1:

Audits

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 (192.1.1.2:32782) sent 22 bytes

  responder (200.1.1.1:23) sent 200 bytes

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

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.

Copyright eTutorials.org 2008-2024. All rights reserved.