Monitoring Network Access Control

The show commands provided by Cisco ASA are extremely useful in checking the health and status of the hardware and in isolating network-related issues. The necessary show commands to manage network access control are discussed in the following two sections.

Monitoring ACLs

Cisco ASA provides the show access-list command to determine if the packets are passing through the configured ACLs. When a packet is matched against an ACE, the security appliance increments the hitcnt (hit count) counter by one. This is useful when you want to know if traffic is hitting a configured ACE. It is also useful to check if packets are allowed or denied if there is a new virus outbreak in the network that might be sending traffic from spoofed addresses. Example 5-28 shows the configuration of an ACL called outside_in. If object groups are used and the show access-list outside_in command is executed, Cisco ASA displays all the ACEs that are otherwise grouped into protocols, networks, and services. As evident from this example, the security appliance processed 1009 packets that were denied and logged by the ACE.

Example 5-28. Output of show access-list outside_in

Chicago(config)# show running-config access-list outside_in access-list outside_in remark ACL to block inbound traffic on the outside interface access-list outside_in extended permit tcp any object-group DMZ_Web_Servers eq www access-list outside_in extended permit tcp any object-group DMZ_Email_Servers eq smtp access-list outside_in extended deny ip any any log Chicago(config)#exit Chicago(config)# show access-list outside_in access-list outside_in; 6 elements access-list outside_in line 1 remark ACL to block inbound traffic on the outside interface access-list outside_in line 2 extended permit tcp any object-group DMZ_Web_Servers eq www access-list outside_in line 2 extended permit tcp any host 209.165.201.10 eq www (hitcnt=9) access-list outside_in line 2 extended permit tcp any host 209.165.201.11 eq www (hitcnt=100) access-list outside_in line 2 extended permit tcp any host 209.165.201.12 eq www (hitcnt=24) access-list outside_in line 3 extended permit tcp any object-group DMZ_Email_Servers eq smtp access-list outside_in line 3 extended permit tcp any host 209.165.201.20 eq smtp (hitcnt=3) access-list outside_in line 3 extended permit tcp any host 209.165.201.21 eq smtp (hitcnt=199) access-list outside_in line 4 extended deny ip any any log informational interval 300 (hitcnt=1009)

To reset the hit-count counters, you can issue the clear access-list <ACL_name> counters command, as shown in Example 5-29, in which the counters for the outside_in ACL are being cleared.

Example 5-29. Resetting Hit-Count Counters with clear access-list counters

Chicago(config)# clear access-list outside_in counters

If a UDP, TCP, or, optionally an ICMP packet is allowed to pass through the security appliance, a connection entry is created, which can be shown by using the show conn command, as displayed in Example 5-30. The first column of the connection entry displays the protocol used followed by "out" to indicate IP address of the outside host and then "in" to display the inside hosts' IP addresses. It also shows the source and destination Layer 4 ports. The security appliance shows the idle timer per connection in hours, minutes, and seconds. The most important information to look at is the flags counter, which has the information about the current state of the connection. Table 5-11 lists and describes all the flags. The TCP entry has flags set to "UIO" to indicate that the connection is up and is passing traffic in both inbound and outbound directions.

Example 5-30. Output of show conn

Chicago# show conn 3 in use, 17 most used UDP out 209.165.201.10:53 in 209.165.202.130:53376 idle 0:00:01 flags - TCP out 209.165.201.10:23 in 209.165.202.130:11080 idle 0:00:02 bytes 108 flags UIO ICMP out 209.165.201.10:0 in 209.165.202.130:15467 idle 0:00:00 bytes 72

Cisco ASA can act as a sniffer to gather information about the packets passing through the interfaces. This is important if you want to confirm that traffic from a particular host or network is reaching the interfaces. You can use an ACL to identify the type of traffic and bind it to an interface by using the capture command.

In Example 5-31, an ACL, called inside-capture, is set up to identify packets sourced from 209.165.202.130 and destined for 209.165.200.230. The security appliance is using this ACL to capture the identified traffic on the inside interface using a capture list named cap-inside.

To view the captured packets, use the show capture command followed by the name of the capture list. The security appliance captured 15 packets that matched the ACL on the inside interface. The highlighted entry shows that it is a TCP SYN (shown as S after the destination port) packet sourced from 209.165.202.130 with a source port of 11084 and it is destined for 209.165.200.230 on destination port 23. The TCP window size is 4128 while the Maximum Segment Size (MSS) is set to 536 bytes.

Example 5-31. Packet Capturing

Chicago(config)# access-list inside-capture permit ip host 209.165.202.130 host 209.165.200.230 Chicago(config)# capture cap-inside access-list inside-capture interface inside Chicago(config)# show capture cap-inside 15 packets captured 1: 02:12:47.142189 209.165.202.130.11084 > 209.165.200.230.23: S 433720059:433720059(0) win 4128 2: 02:12:47.163489 209.165.202.130.11084 > 209.165.200.230.23:. ack 1033049551 win 4128 !Output omitted for brevity 15 packets shown

Note

When the capture command is enabled, the security appliance allocates memory right away. The default memory allocation is 512 KB. The security appliance can overwrite content from the beginning in this buffer space when it is full. The capture command has minimal CPU impact and therefore it is one of the most important troubleshooting tools available in Cisco ASA.

Tip

The output of the capture command can be exported into pcap format, which can be imported into a sniffing tool such as Ethereal or TCPDUMP for further analysis.

Monitoring Content Filtering

If the security appliance is set up to filter traffic by inspecting the URLs, you can view the packet-filtering statistics to ensure that nonallowed traffic is denied. Use the show url-server statistics command to check how many packets have been allowed and dropped based on the responses from the URL server (such as Websense). In Example 5-32, the security appliance has denied 9000 URL (HTTP) attempts due to restricted or blocked content, whereas it has allowed 161,302 requests. The status of the Websense server is up which indicates that there is a bidirectional communication channel between the server and the security appliance.

Example 5-32. Output of show url-server statistics

Chicago# show url-server statistics URL Server Statistics: ---------------------- Vendor websense URLs total/allowed/denied 170302/161302/9000 HTTPSs total/allowed/denied 1765/876/889 FTPs total/allowed/denied 10/8/2 URL Server Status: ------------------ 209.165.201.50 UP URL Packets Sent and Received Stats: ----------------------------------- Message Sent Received STATUS_REQUEST 496908 482321 LOOKUP_REQUEST 170694 170603 LOG_REQUEST 0 NA -----------------------------------

If URL caching is enabled, as in the case of the deployment scenario, you can collect statistics such as allocated memory for this purpose. In Example 5-33, the security appliance shows that the total maximum number of cached URLs is 171, the total number of active URLs in the cache is 100, the total lookups it performed is 456, and the number of packets that matched the cached URLs is 306.

Example 5-33. Output of show url-cache statistics

Chicago# show url-cache statistics URL Filter Cache Stats ---------------------- Size : 100KB Entries : 171 In Use : 100 Lookups : 456 Hits : 306