Using Capture

You can define one or more capture sessions on a firewall, each operating independently. Captured packets are stored in a memory buffer and can be viewed much like a protocol analyzer or sniffer trace.

Defining a Capture Session

Two basic steps are involved in defining a capture session:

1. Configure an access list to identify the interesting traffic for capture.

2. Define the actual capture session.

An access list is used to pick out specific traffic passing through a firewall interface. You can set up a capture session that does not use an access list at all, but it then captures all traffic passing through.

You can configure the access list by entering one or more access control entry (ACE) statements with the following configuration command:

Code View: Scroll / Show All

Firewall(config)# access-list acl id [line line-num] [extended] permit protocol

{source addr source mask [operator sport] [destination addr destination_mask [operator dport]]

The access list is used to flag packets for capture—not to permit or deny them from passing through the interface. Therefore, only the permit keyword is useful here. An implicit deny statement is at the end of the access list, which causes all other traffic to pass without being captured.

The matched protocol can be ip (any IP protocol), tcp (6), udp (17), ah (51), eigrp (88), esp or ipsec (50), gre or pptp (47), igmp (2), igrp (9), ipinip (4), nos (94), ospf (89), pcp (108), pim (103), snp (109), icmp (1), icmp6 (58), or a number from 1 to 255.

Source and destination addresses can be explicit IP addresses or subnets, and the masks are regular subnet masks. If you need to specify addresses, be sure the addresses are relevant with respect to NAT. A capture session can monitor inbound traffic on an interface before NAT is performed, and it can monitor outbound traffic after NAT is performed.

If you need to match against a source or destination port number, you can add an optional operator: lt (less than), gt (greater than), eq (equal to), neq (not equal to), or range (lies between two port limits). The operator compares the port number to the value given by port (a single decimal number; for a range, give two numbers for lower and upper limits).

You might find it handy to include something like cap in the access list name, as in acl_cap_testprobe. This way, you can guess that the ACL has a special purpose just by looking at its name.

To define and start a capture session on a firewall interface, you can use the following privileged EXEC command:

Code View: Scroll / Show All

Firewall# capture capture name [access-list acl name] [ethernet-type type] [interface if-name] [buffer bytes] [circular-buffer] [packet-length bytes]

The capture session is named capture_name (an arbitrary text string). The access list named acl_name is used to identify packets to be captured. If an access list is not used or defined, all IP packets are matched. However, you should use an access list to specifically match traffic with respect to NAT.

You can define the protocol to capture in the access list. You can also specify an Ethernet type code in the capture command instead if you need to capture a protocol that the ACL does not support. By default, all Ethernet types are flagged for capture. You can specify one as type using one of these values: arp (ARP requests and replies), ip (TCP/IP), pppoe (PPP over Ethernet), pppoed (PPP over Ethernet Discovery), ip6 (IP version 6), ipx (Novell IPX), or rarp (Reverse ARP).

You should specify which interface the capture session will monitor with the interface keyword and the interface if-name (defined with the nameif command).

On a FWSM platform, the capture feature is somewhat broken until release 3.2. You can define a capture session and apply it to a VLAN interface, but the FWSM captures only packets coming into the interface—outbound packets are not captured at all.

You can also use an external protocol analyzer or "sniffer" to capture all traffic going to and from a FWSM interface. A VLAN ACL (VACL) capture is used on the Catalyst 6500 to intercept packets as they pass between the switch backplane to the FWSM. See the section ""Capturing FWSM Packets Inside the Switch" in this chapter for more information.

You can also make adjustments to the capture buffer. By default, the capture session buffer is 512 KB in the main firewall memory. With the buffer keyword, the buffer can be resized to bytes. By default, the capture session stops when the buffer is full. However, you can use the circular-buffer keyword to allow the capture to work continuously; when the buffer fills, the capture stores the next packet at the beginning of the buffer.

By default, up to 68 bytes of each captured packet are stored in the buffer. You can change this limit with the packet-length keyword to bytes (up to the MTU or maximum packet size). The default value gives enough information to include the IP and upper-layer protocol headers. Be aware that if you increase the packet length, you can view the contents of captured packets, including any cleartext user IDs, passwords, or other confidential information.

Beginning with ASA 7.0(1), you can add the type keyword to specify a type of data to capture. The following command syntax is used:

Code View: Scroll / Show All

Firewall# capture capture name type {raw-data | isakmp | asp-drop drop-reason}

[buffer bytes] [circular-buffer] [packet-length bytes]

The raw-data type is used in capture sessions by default, even when the type keyword is unavailable. In other words, raw IP packets can be captured. You can also capture certain VPN traffic by specifying type isakmp.

Another novel feature involves capturing packets that are dropped rather than forwarded through the firewall. This allows you to analyze the contents of dropped packets so that you can see exactly why the packet was dropped. No other capture filtering by access list or interface is necessary, because packets can be dropped for a wide variety of reasons.

You can use the type asp-drop keywords along with one of the drop-reason keywords listed in Table 11-12.

Table 11-12. drop-reason Keywords for the capture type asp-drop Command

drop-reason Keyword

Description

acl-drop

Flow is denied by the access rule

all

All packet drop reasons

bad-crypto

Bad crypto return in packet

bad-ipsec-natt

Bad IPSec NAT-T packet

bad-ipsec-prot

IPSec is not AH or ESP

bad-ipsec-udp

Bad IPSec UDP packet

bad-tcp-cksum

Bad TCP checksum

bad-tcp-flags

Bad TCP flags

ctm-error

Crypto Transform Manager (CTM) returned an error

dns-guard-app-id-not-match

DNS Guard application ID did not match

dns-guard-out-of-app-id

DNS Guard out of application ID

dst-l2_lookup-fail

Destination MAC L2 lookup failed

flow-expired

Expired flow

fo-standby

Dropped by the standby unit

ids-fail-close

IDS card is down

ids-request

IDS Module requested a drop

ifc-classify

Virtual firewall classification failed

inspect-dns-app-id-not-match

DNS Inspect application ID did not match

inspect-dns-invalid-domain-label

DNS Inspect invalid domain label

inspect-dns-invalid-pak

DNS Inspect invalid packet

inspect-dns-out-of-app-id

DNS Inspect out of application ID

inspect-dns-pak-too-long

DNS Inspect packet was too long

inspect-icmp-app-id-not-match

ICMP Inspect application ID did not match

inspect-icmp-error-no-existing-conn

ICMP Error Inspect had no existing connection

inspect-icmp-out-of-app-id

ICMP Inspect out of application ID

inspect-icmpv6-error-invalid-pak

ICMPv6 Error Inspect invalid packet

inspect-icmpv6-error-no-existing-conn

ICMPv6 Error Inspect had no existing connection

intercept-unexpected

Unexpected packet was intercepted

interface-down

Interface is down

invalid-app-length

Invalid application length

invalid-encap

Invalid encapsulation

invalid-ethertype

Invalid EtherType

drop-reason Keyword

Description

invalid-ip-addr

Invalid IP address

invalid-ip-header

Invalid IP header

invalid-ip-length

Invalid IP length

invalid-ip-option

IP option configured drop

invalid-tcp

Invalid TCP packet

invalid-tcp-hdr-length

Invalid TCP length

invalid-udp-length

Invalid UDP length

ip-fragment

IP fragment unsupported

ipsec-clearpkt-notun

IPSec clear packet with no tunnel

ipsec-ipv6

IPSec via IPv6

ipsec-need-sa

IPSec SA not negotiated yet

ipsec-spoof

IPSec spoof detected

ipsec-tun-down

IPSec tunnel is down

ipsecudp-keepalive

IPSec/UDP keepalive message

ipv6_fp-security-failed

IPv6 fastpath security checks failed

ipv6_sp-security-failed

IPv6 slowpath security checks failed

l2_acl

Fast Path (FP) L2 rule drop

l2_same-lan-port

L2 source/destination same LAN port

large-buf-alloc-fail

Fast Path (FP) large buffer allocation failed

loopback-buffer-full

Loopback buffer is full

lu-invalid-pkt

Invalid failover logical update (LU) packet

natt-keepalive

NAT-T keepalive message

no-adjacency

No valid adjacency

no-mcast-entry

Fast Path (FP) has no multicast entry

no-mcast-intrf

Fast Path (FP) has no multicast output interface

no-punt-cb

No registered punt callback

no-route

No route to host

np-sp-invalid-spi

Invalid SPI

punt-rate-limit

Punt rate limit exceeded

queue-removed

Queued packet dropped

rate-exceeded

QoS rate exceeded

rpf-violated

Reverse-path verify failed

security-failed

Early security checks failed

send-ctm-error

Send to Crypto Transform Manager (CTM) returned an error

tcp-3whs-failed

TCP failed three-way handshake

tcp-ack-syn-diff

TCP ACK in SYNACK invalid

Table 11-12. drop-reason Keywords for the capture type asp-drop Command

drop-reason Keyword

Description

tcp-acked

TCP duplicate and has been ACKed

tcp-bad-option-len

Bad option length in TCP

tcp-b ad-opti on-li st

TCP option list invalid

tcp-bad-sack-allow

Bad TCP SACK ALLOW option

tcp-bad-winscale

Bad TCP window scale value

tcp-buffer-full

TCP packet buffer full

tcp-conn-limit

TCP connection limit reached

tcp-data-past-fin

TCP data send after FIN

tcp-discarded-ooo

TCP packet out of order

tcp-dual-open

TCP dual open denied

tcp-fo-drop

TCP replicated flow packet drop

tcp-invalid-ack

TCP invalid ACK

tcp-mss-exceeded

TCP MSS was too large

tcp-mss-no-syn

TCP MSS option on non-SYN

tcp-not-syn

First TCP packet not SYN

tcp-paws-fail

TCP packet failed Protect Against Wrapped Sequence numbers (PAWS) test

tcp-reserved-set

TCP reserved flags set

tcp-rst-syn-in-win

TCP RST/SYN in window

tcp-rstfin-ooo

TCP RST/FIN out of order

tcp-seq-past-win

TCP packet SEQ past window

tcp-seq-syn-diff

TCP SEQ in SYN/SYN-ACK invalid

tcp-syn-data

TCP SYN with data

tcp-syn-ooo

TCP SYN on established connection

tcp-synack-data

TCP SYN-ACK with data

tcp-synack-ooo

TCP SYN-ACK on established connection

tcp-tsopt-notallowed

TCP time stamp not allowed

tcp-winscale-no-syn

TCP window scale on non-SYN

unable-to-add-flow

Flow hash full

unabl e-to-create-fl ow

Out of flow cache memory

unimplemented

Slow path unimplemented

unsupport-ipv6-hdr

Unsupported IPv6 header

unsupported-ip-version

Unsupported IP version

As a simple example, the following capture session is created to capture all packets that have been dropped by an interface access list:

Firewall# capture ACLdroptest type asp-drop acl-drop

An inbound SMTP session is attempted from an outside host, which is blocked by an access list applied to the outside interface. First, the following Syslog messages were collected for the failed session:

Code View: Scroll / Show All

Feb 08 2007 00:25:41 single_vf : %PIX-4-106023: Deny tcp src outside:172.21.4.48/3407 dst inside:172.16.1.5/25 by access-group "acl outside"

Feb 08 2007 00:25:44 single_vf : %PIX-4-106023: Deny tcp src outside:172.21.4.48/3407 dst inside: 172.16.1.5/25 by access-group "acl outside"

Feb 08 2007 00:25:50 single_vf : %PIX-4-106023: Deny tcp src outside:172.21.4.48/3407 dst inside: 172.16.1.5/25 by access-group "acl outside"

The denied packets can be correlated to the following packets in the capture session:

Code View: Scroll / Show All

Firewall# show capture test 3 packets captured

1: 00:25:41.114312 172.21.4.48.3407 > 172.16.1.5.25: S 352 0305660:352 0305660(0)

win 65520 <mss 1260,nop,nop,sack0K> 2: 00:25:44.026197 172.21.4.48.3407 > 172.16.1.5.25: S 3520305660:3520305660(0)

win 65520 <mss 1260,nop,nop,sack0K> 3: 00:25:50.122659 172.21.4.48.3407 > 172.16.1.5.25: S 3520305660:3520305660(0)

win 65520 <mss 1260,nop,nop,sack0K> 3 packets shown Firewall#

You can repeat these steps to define several capture sessions. You can assign multiple capture sessions to the same interface. You also can reuse an ACL in multiple capture sessions if needed. Each capture session is independent and captures its own data in a separate capture buffer.

You can use multiple capture sessions to troubleshoot difficult problems in which the firewall is not forwarding traffic for some reason. Configure one capture session on one interface and a similar capture session on another interface. Use the same access list in both capture sessions. Then you can see traffic arriving on one interface but not appearing on the other.

Aside from the normal traffic inspection engines, access lists, and service policies that might be dropping the packets, consider other information contained in the capture buffer. Be sure to look for packet-related parameters such as the do not fragment (DF) bit or the TCP maximum segment size (MSS) that could be causing packets to be silently dropped.

Getting Results from a Capture Session

After you have defined a capture session, you need to monitor it for activity and retrieve the captured data. If you have defined several capture sessions, you might have trouble remembering which one is performing a certain function. You can list the current capture sessions with the following command:

Firewall# show capture

For example, the firewall used in the following show capture output has three capture sessions defined:

Firewall# show capture capture Aserver-out access-list interface outside capture Aserver-in access-list interface inside capture A-trunk interface outside

Notice that one session is bound to the inside interface, and two other separate sessions are active on the outside interface.

You can display the contents of a capture session buffer at any time, even if the capture is still active. To view the buffer contents from a console, Telnet, or SSH session, you can use the following command:

Was this article helpful?

0 0

Post a comment