11-3. Configuring IOS Firewall Stateful Inspection An IOS firewall can inspect traffic passing through according to the expected state or behavior of each protocol used. This stateful inspection process is called Content-Based Access Control (CBAC). When a router becomes an IOS firewall by enabling CBAC, you should begin to think of the router interfaces in firewall terms. Some of the interfaces are connected to protected networks, where data or services must be secured. Others connect to public or unprotected networks, where untrusted users and resources are located. For example, the FastEthernet 0/0 interface might become the inside firewall interface. FastEthernet 0/1 might become the outside interface, because it lies toward the Internet. The same thing can be said of logical VLAN interfaces if they are switched virtual interfaces (SVIs) that route traffic. Figure 11-6 provides an example. Figure 11-6. Designating IOS Firewall Interfaces 
The top portion of the figure shows an IOS firewall with only two interfaces, which connect to the inside (more secure) and outside (less secure) networks. The bottom portion of the figure shows an IOS firewall with three interfaces, connected to the inside (most secure), DMZ (less secure), and outside (least secure) networks. The IOS firewall has no concept of these interface designations or security levels; these concepts are put into play by the inspection processes and policies that are configured. Consider each interface that is involved in traffic inspection. The IOS firewall can inspect data that travels into each interface as it moves toward another interface. As well, traffic coming out of an interface has just come from another interface. The IOS firewall maintains the relationship between pairs of interfaces, in which traffic originates on one interface and is destined for another. Therefore, you have to know which interfaces are considered more secure than others. How CBAC Works CBAC inspection is not inherent in an IOS firewallit must be configured. However, the CBAC concept is simple, and the configuration isn't very complicated. CBAC inspection occurs in one direction (in or out) on an interface. (You can configure two CBAC processes, one for each in or out direction, but you don't have to.) For the sake of this discussion, assume that only inbound inspection is configured on the inside IOS firewall interface. Figure 11-7 shows this arrangement, along with the inspection mechanism. Figure 11-7. CBAC Inspection on an IOS Firewall with Two Interfaces 
As packets from the inside pass into the inspected interface, toward the outside, the following things happen: 1. | The packets are filtered by an inbound access list (access-list 1, for example) on the interface if one is configured. This can be useful if you need to control what types of traffic your trusted users are allowed to initiate.
| 2. | Packets that are permitted into the interface are inspected according to an inspection rule. Rules can apply to application protocols, generic UDP or TCP protocols, or ICMP.
| 3. | The IOS firewall forwards the packets under normal routing behavior. If an extended IP access list is applied to the egress interface, CBAC places a dynamic permit entry in it so that return traffic is allowed.
However, beginning with Cisco IOS software Release 12.3(4)T, dynamic ACL entries are not created. Instead, the firewall keeps a session state table of all active connections. This feature is called Firewall ACL Bypass. The session state table is searched much more efficiently than the traditional dynamic ACL.
NOTE CBAC finds the right access list by performing a route lookup for the destination address. The corresponding egress interface is checked; if an inbound ACL is applied to it, CBAC creates dynamic permit entries in it, ahead of any configured permit or deny statements. (With IOS Release 12.3(4)T or later, this is done by creating new session state table entries.) If the egress interface doesn't have an ACL applied, CBAC can't create any dynamic ACL entries. Therefore, all inbound traffic (return or otherwise) is allowed to pass back through the firewall. Obviously, it is very important to configure and apply an inbound ACL to each egress interface so that the firewall inspection is fully functional. | 4. | When packets return from the outside, they are filtered according to the extended IP access list applied to that interface. Three conditions are supported:
- Return traffic from connections that originated on the inside are permitted by the dynamic ACL entries (or session state table entries) that CBAC created. - Inbound traffic to services or resources on the inside are permitted only if access has been explicitly configured. - All other inbound traffic is dropped or denied.
|
CBAC also monitors inbound UDP and TCP connections in an aggressive fashion, considering large numbers of half-open or incomplete connections to be malicious attacks. TCP connections are fully inspected to make sure that source and destination addresses and ports, as well as connection state information, are consistent. UDP sessions are inspected for source and destination address and port consistency but cannot be fully inspected for connection state. Instead, the sessions are held open until they become idle for a period of time. ICMP sessions are inspected only from the standpoint that they are initiated from a protected interface. Return traffic from any unprotected source is allowed to reach the originating host, but only for a small number of ICMP packet types. ICMP sessions are automatically closed after a very brief idle time to prevent any misuse. Table 11-2 lists the only ICMP message types automatically permitted to return through the firewall. Table 11-2. ICMP Message Types Supported by CBAC InspectionICMP Message | ICMP Type | Description |
|---|
Echo reply | 0 | Commonly used as a reply to a ping or traceroute request packet. | Unreachable | 3 | Sent when a network or host is unavailable or unknown. | Echo request | 8 | Commonly used as a ping or traceroute request to determine if a destination is alive and the path to reach it. | Time exceeded | 11 | Sent when the time-to-live (TTL) value in a packet has expired or reached 0. This is commonly used by the traceroute utility to determine each router hop along the path to a destination host. | Time stamp request | 13 | Sent when a source host asks the destination for its idea of the current time. | Time stamp reply | 14 | Sent as a response to a time stamp request packet. |
Stateful inspection gets slightly more complex when an IOS firewall has more than two interfaces. Figure 11-8 shows how CBAC works on a firewall with three interfaces. The concept is no different from that of Figure 11-7, where only two interfaces are involved. Figure 11-8. CBAC Inspection on an IOS Firewall with Three Interfaces 
When CBAC inspection is enabled on an interface, traffic destined outbound triggers the inspection, and return traffic is allowed back through the interface. In Figure 11-8, the Inside and DMZ interfaces have CBAC inspection enabled because they generally support users or hosts that connect to resources on the outside network. Inspection is not enabled on the outside interface simply because the outside network is considered insecure. The only inbound traffic that is allowed to get in from the outside is identified and permitted by an access list applied to the outside interface. Configuring CBAC Inspection Follow these steps to configure CBAC inspection on an IOS firewall: 1. | Identify an interface that will be inspected, along with the traffic direction.
Usually, inspection is configured on the inside interface for outbound traffic. (Note that from the firewall's perspective, this is actually traffic coming in on the inside interface, heading elsewhere.)
| 2. | Inspect any supported application protocols.
Configure an inspection rule named inspection-name. Define inspection for as many specific application protocols as needed with the commands listed in Table 11-3. One inspection rule can contain many ip inspect name commands.
Table 11-3. Inspection Rule Command Syntax by ApplicationApplication | Command Syntax |
|---|
ICMP | IOSFirewall(config)# ip inspect name inspection-name icmp | UDP (generic) | IOSFirewall(config)# ip inspect name inspection-name udp | TCP (generic) | IOSFirewall(config)# ip inspect name inspection-name tcp | HTTP | IOSFirewall(config)# ip inspect name inspection-name http [urlfilter] [java-list access-list] | CU-SeeMe | IOSFirewall(config)# ip inspect name inspection-name cuseeme | ESMTP | IOSFirewall(config)# ip inspect name inspection-name esmtp [max-data max-bytes-per-session] | FTP | IOSFirewall(config)# ip inspect name inspection-name ftp | H.323 | IOSFirewall(config)# ip inspect name inspection-name H323 | IP Fragments | IOSFirewall(config)# ip inspect name inspection-name fragment [max fragments] | Microsoft Netshow | IOSFirewall(config)# ip inspect name inspection-name netshow | RealAudio | IOSFirewall(config)# ip inspect name inspection-name realaudio | RPC | IOSFirewall(config)# ip inspect name inspection-name rpc program-number number [wait-time minutes] | RTSP | IOSFirewall(config)# ip inspect name inspection-name rtsp | SCCP (Skinny) | IOSFirewall(config)# ip inspect name inspection-name skinny | SIP | IOSFirewall(config)# ip inspect name inspection-name sip | SMTP | IOSFirewall(config)# ip inspect name inspection-name smtp [max-data max-bytes-per-session] | SQL*Net | IOSFirewall(config)# ip inspect name inspection-name sqlnet | StreamWorks | IOSFirewall(config)# ip inspect name inspection-name streamworks | TFTP | IOSFirewall(config)# ip inspect name inspection-name tftp | UNIX "r" commands | IOSFirewall(config)# ip inspect name inspection-name rcmd | VDOLive | IOSFirewall(config)# ip inspect name inspection-name vdolive |
With HTTP inspection, you can use the urlfilter keyword to enable URL filtering. This feature is fully described in section 11-4, "HTTP, Java, and URL Filtering."
You can also enable Java applet blocking by including the java-list keyword. The access-list is a standard numbered IP access list that permits only trusted or "friendly" sites for Java content.
For fragmentation inspection, use the fragment keyword. The IOS firewall looks for the initial fragment of a fragmented packet before any of the subsequent fragments are allowed to pass through toward the destination.
However, the firewall must receive the fragments in sequential order. If legitimate fragments arrive out of order, they are dropped.
The IOS firewall keeps a fragmentation state in memory for each fragmented packet received. By default, up to 256 fragmented packets can be tracked at any time. You can change this limit with the max keyword, keeping the state of up to fragments (50 to 10,000) packets.
You can enable RPC inspection with the rpc program-number keywords. Packets involved with the program number given (1 to 4294967295) are allowed, and any program numbers not specified are blocked. The ip inspect name command can be repeated with the rpc program-number keywords to allow multiple RPC program numbers.
The wait-time keyword can be used for RPC to keep a "hole" opened in the firewall policy so that additional RPC connections are allowed between the same pair of hosts. By default, the wait time is 0 minutes, which prevents this hole from forming. You can adjust the wait time to minutes (0 to 35791 minutes).
For any of the inspection protocol commands listed in Table 11-3, you can add any of the keywords and functions documented in Table 11-4.
Table 11-4. Inspection Protocol Command KeywordsKeyword | Function |
|---|
alert {on | off} | Generate real-time Syslog alerts when any of these events are detected: Denial of service attack SMTP attack Java applets are blocked FTP attacks
Alerts are globally enabled by default. | audit-trail {on | off} | Generate a Syslog audit trail when UDP or TCP sessions are inspected and torn down. Audit trails are globally disabled by default. | timeout seconds | Override the global ICMP, UDP, and TCP idle timeout values for a specific protocol. |
If any of the CBAC inspections are configured to generate an audit trail (audit-trail on keywords are used), you must also configure CBAC to enable the audit trail output. You can use the following command:
IOSFirewall(config)# ip inspect audit-trail
| 3. | (Optional) Adjust application port numbers if needed.
The IOS firewall inspects applications based on predefined well-known port numbers. If you have applications that use nonstandard port numbers, you can adjust the firewall so that it still inspects that traffic properly. This feature is called Port-to-Application Mapping (PAM).
- a. (Optional) Identify the source addresses that are expecting nonstandard ports:
IOSFirewall(config)# access-list acl_num permit source
The standard IP access list numbered acl_num (1 to 99) is used to flag the source addresses of hosts that expect to use a nonstandard port assignment.
The source can be an IP address and wildcard mask (0 bits match; 1 bits ignore), host ip-address to identify a single host, or any to match any address.
- b. Define the nonstandard application port:
IOSFirewall(config)# ip port-map appl_name port port_num [list acl_num]
IOS firewall inspection for the application named appl_name uses port_num in addition to the predefined well-known value. You can define a nonstandard port for a specific set of users by applying the standard IP access list numbered acl_num (1 to 99).
Choose the application name, appl_name, from Table 11-5. The default or system-defined port number is also shown. Note that when you define a new application-port mapping, the original system-defined mapping still exists. In other words, the IOS firewall always inspects the protocols based on the well-known port numbers in addition to any that you define here.
Table 11-5. PAM Keywords for Applications with Nonstandard Port NumbersApplication Name | Default Port | Description |
|---|
cuseeme | 7648 | CUSeeMe protocol | dns | 53 | Domain Name Server (inspected with generic UDP) | exec | 512 | Remote Process Execution (UNIX "r" commands) | ftp | 21 | File Transfer Protocol | h323 | 1720 | H.323 protocol (such as Microsoft NetMeeting or Intel Video Phone) | http | 80 | Hypertext Transfer Protocol | netshow | 1755 | Microsoft NetShow | realmedia | 7070 | RealNetworks' RealMedia protocol | rtsp | 8554 | Real-Time Streaming Protocol | rtsp | 554 | | sip | 5060 | Session Initiation Protocol | skinny | 2000 | Skinny Client Control Protocol | smtp | 25 | Simple Mail Transfer Protocol | sql-net | 1521 | SQL-NET | streamworks | 1558 | StreamWorks protocol | sunrpc | 111 | SUN Remote Procedure Call | tftp | 69 | Trivial File Transfer Protocol | vdolive | 7000 | VDOLive protocol |
TIP You can also use PAM to define nonstandard port numbers for the Network-Based Application Recognition (NBAR) feature, which is not used in firewall functions. There are PAM application names other than those shown in Table 11-5. They don't have a corresponding CBAC inspection, so they have been omitted from the table. You can repeat the ip port-map appl_name port port_num [list acl_num] command to define more application port mappings. You can also repeat the command to define other mappings for the same application using different access lists.
TIP You can see the IOS firewall's table of application port mapping values with the show ip port-map command. Some of the applications listed in Table 11-5 are shown with no default port number. In fact, the firewall doesn't even list these until you define a port mapping. For example, the following IOS firewall has been configured with two standard access lists that are used to alter the port mapping for HTTP: IOSFirewall# show ip port-map Default mapping: dns port 53 system defined [output deleted] Default mapping: telnet port 23 system defined Host specific: http port 8080 in list 20 user defined Default mapping: rtsp port 554 system defined Host specific: http port 8000 in list 19 user defined [output deleted]
| 4. | Define inspection rules for the generic UDP protocol:
IOSFirewall(config)# ip inspect name inspection-name udp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Generic UDP inspection is performed on any UDP traffic that is not involved in specific application inspection. UDP is not connection-oriented, so the IOS firewall simulates connection inspection.
As soon as a UDP session is initiated through the firewall, subsequent UDP packets are allowed to return until no packets have passed between the pair of hosts for a timeout period. By default, UDP session entries are kept open until they have been idle for 30 seconds. You can change this with the timeout keyword to seconds (5 to 43,200 seconds).
| 5. | Define inspection rules for the generic TCP protocol:
IOSFirewall(config)# ip inspect name inspection-name tcp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Because TCP is connection-oriented, the IOS firewall can keep and inspect every aspect of a connection between two hosts. Generic TCP inspection is performed on any TCP traffic that is not being handled by a specific application inspection.
As soon as a TCP connection is established through an IOS firewall, it is allowed to continue until it is torn down by the pair of hosts. If the connection becomes idle, and no data passes between the hosts, the firewall deletes the connection after a timeout period. This is 3,600 seconds by default, but it can be adjusted with the timeout keyword to seconds (5 to 43,200 seconds).
| 6. | Define inspection rules for generic ICMP traffic:
IOSFirewall(config)# ip inspect name inspection-name icmp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Until Cisco IOS software Releases 12.2(11)YU and 12.2(15)T, the IOS firewall did not support any inspection for ICMP. If ICMP traffic must be allowed through a firewall, it must be explicitly allowed by permit statements in inbound and outbound access lists.
For IOS releases after these, ICMP inspection can be performed. The IOS firewall creates dynamic access list entries when initial ICMP packets are inspected. These ACL entries allow return ICMP packets from any source to the specific hosts that originated them, but they are deleted 10 seconds after the last ICMP packet has been sent from the originating host. You can adjust the idle time with the timeout keyword to seconds (5 to 43,200 seconds).
For example, the following dynamic ACL entries were automatically added after a host on the inside interface sent ICMP echo requests to a host on the outside of the IOS firewall:
permit icmp any host 172.19.100.10 time-exceeded permit icmp any host 172.19.100.10 unreachable permit icmp any host 172.19.100.10 timestamp-reply permit icmp any host 172.19.100.10 echo-reply (2 matches)
TIP You might be curious why the dynamic ACL entries allow any host, rather than specific ones, to send return ICMP traffic back toward the originator. This is to accommodate the full use of the ICMP messages as troubleshooting tools. For example, when you use traceroute to trace the path toward a destination, ICMP time-exceeded packets are returned by every router along the path. In other words, the source address of the return traffic isn't always known ahead of time. In fact, these tools rely on the ability to return messages from a variety of hosts. Therefore, return packets are allowed from any host, but only for a very brief time. After Cisco IOS software Release 12.3(4)T, dynamic ACL entries are not used. Instead, the firewall maintains a session state table as an efficient means of controlling the security of every inspected connection. This is called the Firewall ACL Bypass feature. | 7. | Apply the rule to the interface:
IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# ip inspect inspection-name {in | out}
The inspection rule named inspection-name is bound to the interface in the in or out direction. Always choose the direction that faces toward the less-secure side of the IOS firewall. For example, if inspection is done on the inside interface, it should be applied in the in direction. If you decide to inspect on the outside, apply it in the out direction.
| 8. | (Optional) Use an access list on the inspected interface to control traffic that originated there.
You can define a numbered or named access list (standard or extended) that permits only the types of traffic that are allowed to originate connections through the inspected interface. If NAT is in use, be sure to use local addresses rather than global (translated) addresses in the access list.
This access list is optional and is not involved in the CBAC inspection process. It limits only the traffic that can be inspected as it forms connections.
| 9. | Use an extended IP access list on any other firewall interface where traffic is expected to return.
- a. Define any unsolicited traffic to be allowed.
If you have resources connected to the inspected (more trusted) firewall interface, you can use permit statements to allow access from users on the less-trusted interface. Because these connections are initiated toward the inspected interface, they are blocked by default and are not inspected. You must explicitly allow them with the ACL.
If you are using NAT, you should use the global addresses in any ACL statements.
TIP If you decide to permit inbound connections initiated from the outside, you can also configure CBAC inspection on the outside interface. Only the permitted connections are inspected, and the return traffic coming back through the firewall and out of the outside interface is dynamically permitted. - b. Deny all other traffic.
You can deny specific traffic to block it, or you can rely on the implicit "deny all" at the end of the ACL. Remember that the CBAC inspection adds dynamic permit entries for inspected connections to the ACL automatically.
- c. Apply the extended ACL to the interface:
IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# ip access-group acl in
TIP By default, an IOS firewall interface sends an ICMP unreachable packet back to the originator when a packet is denied or blocked. If you want to make your firewall behave more silently, so that malicious users don't see evidence that it is actively blocking traffic, you must disable ICMP unreachables using the following commands: IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# no ip unreachables
To see if a firewall interface is generating ICMP unreachable packets, use the show ip interface type mod/num command. Look for a line similar to the one highlighted in the following output: IOSFirewall# show ip interface fastethernet 0/0 FastEthernet0/0 is up, line protocol is up [output deleted] Outgoing access list is not set Inbound access list is Outside Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent
| 10. | Tune the CBAC timeout values.
- a. Set the time to wait for an established connection:
IOSFirewall(config)# ip inspect tcp synwait-time seconds
CBAC waits seconds (1 to 2,147,483; the default is 30 seconds) for a TCP connection to be established after the SYN. After that, CBAC drops the connection.
- b. Set the time to manage a closed connection:
IOSFirewall(config)# ip inspect tcp finwait-time seconds
CBAC continues to manage a TCP connection for seconds (1 to 2,147,483; the default is 5 seconds) after the FIN handshake closes the session.
- c. Set the connection idle times:
IOSFirewall(config)# ip inspect {tcp | udp} idle-time seconds
CBAC continues to manage a TCP session (tcp) for seconds (1 to 2,147,483; the default is 3,600 seconds, or 1 hour) and a UDP "session" (udp) for seconds (1 to 2,147,483; the default is 30 seconds) after no further activity is detected.
- d. Set the DNS idle timeout:
IOSFirewall(config)# ip inspect dns-timeout seconds
After a DNS request is received on an inspected interface, CBAC keeps a DNS UDP session open for any replies that are returned for seconds (1 to 2,147,483; the default is 5 seconds) after no activity is detected.
| 11. | Tune the CBAC attack criteria.
When CBAC determines that the number and type of connections coming in indicate that an attack might be in progress, it enables its aggressive mode. During that time, it essentially reduces the number of half-open connections by deleting them as new connection requests arrive.
- a. Set the connection thresholds for aggressive mode:
IOSFirewall(config)# ip inspect max-incomplete {high | low} number
Aggressive mode is triggered when the number of incomplete or half-open TCP or UDP connections rises above high number (the default is 500 connections). Aggressive mode ends when the number of incomplete connections falls below low number (the default is 400 connections). Half-open TCP connections are not yet established, and half-open UDP connections have traffic in only one direction.
This command triggers aggressive mode based on the volume of half-open connections at any given time.
- b. Set the connection rates for aggressive mode:
IOSFirewall(config)# ip inspect one-minute {high | low} number
Aggressive mode is triggered when the number of incomplete or half-open connections within the last minute rises above high number (the default is 500 connections). Aggressive mode ends when the number of incomplete connections per minute falls below low number (the default is 400 connections).
This command triggers aggressive mode based on the rate of half-open connections at any given time.
- c. Set the thresholds for half-open TCP connections to the same host:
IOSFirewall(config)# ip inspect tcp max-incomplete host number block-time minutes
If CBAC detects more than number (1 to 250; the default is 50 connections) of half-open TCP connections to the same host, it begins deleting the half-open connections.
The block-time keyword is used to define how new connections are deleted. If minutes is 0 (the default), the oldest half-open connection is deleted for every new connection request received. If minutes is greater than 0, all half-open connections are deleted, and all new connections are blocked for minutes.
| 12. | (Optional) Tune the inspection table:
IOSFirewall(config)# ip inspect hashtable number
CBAC forwards packets based on a connection lookup in a hash table. The hash table holds 1024 connection entries by default. If your firewall has more than 1024 simultaneous inspected connections, the hash lookup process could become inefficient. Beginning with Cisco IOS software Release 12.2(8)T, you can adjust the hash table size to number (1024, 2048, 4096, or 8192) entries, which is closer to the maximum number of connections.
|
CBAC Example An IOS firewall is configured to inspect application protocols HTTP, RTSP, SMTP, and TFTP. Inside users also use other protocols, so generic TCP, UDP, and ICMP are inspected too. You want the fire-wall to generate an audit trail and alerts for everything but RTSP. HTTP must also be inspected over port 8080 to support some of the corporate servers. CBAC inspection is performed for inbound traffic on the inside firewall interface, FastEthernet 0/1. The inspection policy is named Inside. On the outside interface, FastEthernet 0/0, an inbound access list, Outside, is used. Inbound access to the e-mail server at 207.246.96.47 is always allowed. In addition, outside users can always initiate Telnet sessions to inside host 207.246.96.46. All other inbound traffic is denied or blocked, and logging messages are generated. The IOS firewall configuration commands that can be used to accomplish these goals are as follows: IOSFirewall(config)# ip inspect audit-trail IOSFirewall(config)# ip inspect name Inside http alert on audit-trail on IOSFirewall(config)# ip inspect name Inside rtsp IOSFirewall(config)# ip inspect name Inside smtp alert on audit-trail on IOSFirewall(config)# ip inspect name Inside tftp alert on audit-trail on IOSFirewall(config)# ip inspect name Inside tcp alert on audit-trail on IOSFirewall(config)# ip inspect name Inside udp alert on audit-trail on IOSFirewall(config)# ip inspect name Inside icmp alert on audit-trail on IOSFirewall(config)# ip port-map http port 8080 IOSFirewall(config)# interface FastEthernet0/0 IOSFirewall(config-if)# description Outside interface IOSFirewall(config-if)# ip access-group Outside in IOSFirewall(config)# interface FastEthernet0/1 IOSFirewall(config-if)# description Inside interface IOSFirewall(config-if)# ip inspect Inside in IOSFirewall(config)# ip access-list extended Outside IOSFirewall(config-ext-nacl)# permit tcp any host 207.246.96.47 eq smtp IOSFirewall(config-ext-nacl)# permit tcp any host 207.246.96.46 eq telnet IOSFirewall(config-ext-nacl)# deny ip any any log
Monitoring CBAC Operation When CBAC inspection is configured, you can monitor its activity in several ways. The most useful information comes from logging reports of connections that have been built, used, and then torn down. This gives you a record of the actual firewall activity in allowing and inspecting connections. You also can (and should) monitor the connection attempts that the IOS firewall blocks. At first, it might seem silly to waste time watching a trail of packets that were denied or connections that weren't allowed to take place. However, you can learn a great deal from watching the types of probing or attacks that malicious users attempt against your network. Tearing Down Connections You can monitor an IOS firewall as it tears down connections it has inspected. Be sure to add the audit-trail on keywords to any protocol inspections you have configured. Then look for logging messages that are labeled %FW-6-SESS_AUDIT_TRAIL, as shown in the following example: Mar 15 12:45:13.351: %FW-6-SESS_AUDIT_TRAIL: http session initiator (192.168.199.13:4519) sent 2678 bytes -- responder (172.17.99.10:80) sent 237 bytes Mar 15 12:45:15.035: %FW-6-SESS_AUDIT_TRAIL: udp session initiator (192.168.199.13:1119) sent 105 bytes -- responder (172.17.10.7:53) sent 999 bytes Mar 15 12:50:28.215: %FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.199.13:4529) sent 33 bytes -- responder (172.17.50.4:110) sent 116 bytes Mar 15 12:50:30.927: %FW-6-SESS_AUDIT_TRAIL: smtp session initiator (192.168.199.13:4530) sent 497 bytes -- responder (172.17.50.5:25) sent 240 bytes
Each of these logging messages represents an established connection that was normally closed or terminated. After the IOS firewall deleted the connection from its tables, it reported on the pair of hosts involved, as well as the protocols and port numbers. The total amount of data exchanged over the connection is also listed. Blocked Traffic To see what traffic the IOS firewall is blocking, you have to enable access list logging. Recall, for example, that inbound traffic on the outside interface normally is blocked by the ACL applied to that interface. As CBAC inspects outbound connections, it adds dynamic entries to the inbound ACL. However, it is the deny statements in that ACL that essentially block inbound traffic. To generate logging messages, add the log keyword to the deny ACL statements. As an alternative, you can use the log-input keyword to record the source interface and MAC address for the matched packet. You can't generate logging for the implicit deny all statement that is always present at the end of the ACL. Therefore, you can configure the final ACL statement explicitly, like this: IOSFirewall(config)# access-list acl-number deny ip any any log
or IOSFirewall(config)# ip access-list extended acl-name IOSFirewall(config-acl)# deny ip any any log
Be aware that enabling access list logging can increase the router CPU utilization. If a large volume of packets are being denied by an ACL, the router must process each one. The actual logging messages are generated with only the first packet that matches the deny statement and at 5-minute intervals afterward. Then begin looking for logging messages that contain %SEC-6-IPACCESSLOGDP. For example, the following named access list permits only one type of inbound traffic on the outside interface. Everything else is denied and logged. IOSFirewall(config)# ip access-list extended Outside IOSFirewall(config-ext-nacl)# permit tcp any host 172.27.1.100 eq smtp IOSFirewall(config-ext-nacl)# deny ip any any log IOSFirewall(config-ext-nacl)# exit IOSFirewall(config)# interface FastEthernet 0/0 IOSFirewall(config-if)# ip access-group Outside in
You can get an idea of how busy the firewall has been denying inbound traffic with the show access-list command. Look for the deny statements and their match counts to see how many packets have been blocked: IOSFirewall#show access-list Outside Extended IP access list Outside permit tcp host 172.30.1.100 eq 5190 host 172.27.1.54 eq 1566 (195 matches) 5 permit tcp any host 172.27.1.100 eq smtp (54 matches) 20 deny ip any any log (370 matches) IOSFirewall#
Recall that the first ACL statement in the preceding example is one that CBAC dynamically created for an outbound connection. That ACL entry doesn't have a line number associated with it, because it is dynamic in nature and always appears before any manually configured statements. In addition, if you are using Cisco IOS software Release 12.3(4)T or later, this information is unavailable. Instead, the firewall maintains the dynamic permit mechanism in a session state table, which is more efficient than generating and evaluating access lists. When inbound packets are blocked, the logging messages look like this: Mar 15 13:16:06.847: %SEC-6-IPACCESSLOGDP: list Outside denied icmp 61.83.1.111 -> 172.27.1.190 (8/0), 17 packets Mar 15 13:16:15.723: %SEC-6-IPACCESSLOGP: list Outside denied tcp 172.29.30.17(1169) -> 172.27.1.100(80), 81 packets
|
