No matter how sophisticated networks become and the application layers that stack upon them, you’ll always need to know what’s going on under the waterline. If you’ve used Wireshark, then you’re probably be familiar with traffic capturing. The distinction here is that we’re not concerned with where to tap the wire (as our device is in the middle of the action); we only need concern ourselves with how to capture the traffic. In the spirit of It’s always the firewall, let’s look at Cisco’s Packet Capture tool.

The Capture

Let’s start with a realistic scenario where we want to see requests made to a specific external address. In this example the external host is this blog (http://slack.noctilus.net).

ASDM

Using the ASDM, we access the Packet Capture Wizard from the Wizards menu. The first thing we need to do is choose the ingress interface, or worded a different way, from which interface the traffic will be entering the firewall. We’ll leave the source as 0.0.0.0 so we capture any sources. For the destination we’ll use 66.228.61.143, the host for this website.

Next we specify the egress interface. As we’re only concerned with the destination we don’t need to make any changes.

In the Buffers & Captures dialog we’ll get the capture data every 10 seconds and use a circular buffer so that we don’t risk filling the ASA with capture data.

Once we’ve entered this information we’ll be prompted with the summary which also gives the CLI code.

Now we’re ready to capture some traffic! Hit the Start button to begin the capture.

Swapping now to our web browser we navigate to this website to generate traffic for the capture.

Back in the Run Captures you should see some traffic caught on both the ingress and ingress interfaces.

One feature of the ASDM is that with the Launch Network Sniffer Application button you can immediately pull up your pcap associated application (such as Wireshark) and have a deeper look into the packets.

CLI

If you’re like me and prefer the CLI you can find the same functionality. Using the syntax we saw in the Summary dialog we can duplicate our results from above.

ciscoasa(config)# capture cap_ingress match ip 0.0.0.0 0.0.0.0 66.228.61.143 255.255.255.255
ciscoasa(config)# capture cap_ingress packet-length 1522 circular-buffer buffer 524288
ciscoasa(config)# capture cap_ingress interface inside
ciscoasa(config)# sh cap cap_ingress                                                         
                                                                                             
319 packets captured                                                                         
                                                                                             
   1: 06:39:34.005172 802.1Q vlan#1 P0 172.16.0.10.59278 > 66.228.61.143.80: S 4292592632:42 
   2: 06:39:34.005584 802.1Q vlan#1 P0 66.228.61.143.80 > 172.16.0.10.59278: S 2991127668:29 
   3: 06:39:34.005721 802.1Q vlan#1 P0 172.16.0.10.59278 > 66.228.61.143.80: . ack 299112766 
   4: 06:39:34.005950 802.1Q vlan#1 P0 172.16.0.10.59278 > 66.228.61.143.80: P 4292592633:42 
   5: 06:39:34.006133 802.1Q vlan#1 P0 66.228.61.143.80 > 172.16.0.10.59278: . ack 429259301 
[cont.]

Like the ASDM we also have access to the pcap data which we can bring up in a browser:
[list]

http://ciscoasa/admin/capture/cap_ingress – Shows the same result as show capture command
http://ciscoasa/admin/capture/cap_ingress/pcap – Allows you to download the pcap data for analyzing through Wireshark

[/list]
Once you’ve found what you’re looking for don’t forget to stop the capture: no capture cap_ingress.

As you can see, capturing traffic with the ASA’s Packet Capture is very intuitive and anyone coming from a Wireshark background will feel right at home.

Access List

The Packet Capture tool really shines through the use of ACLs. Not only does that allow you to use existing ACLs, you can also take the time to design sophisticated rules to reuse down the road. Using the same example above let’s build an ACL to isolate just web traffic from specific internal hosts to the external site. So, what information do we need to collect?

Internal hosts

The first thing we need to determine is which hosts use this external site. Luckily for us, in this imaginary scenario, we already have an object-group containing the internal hosts. Good thinking.

object-group network AppHosts1
 description Hosts with access to external application
 network-object host 172.16.0.10
 network-object host 172.16.0.11

External host

In keeping with our theme, let’s assume that the external website is the one you’re reading.

object network WebApp
 description External Web App
 host 66.228.61.143

Protocol

As mentioned we’re interested in web traffic so we’re looking for port 80 and 443 traffic.

Interfaces

We also need to know how the traffic is entering and leaving the firewall. In this scenario we’ll be using our inside and outside interfaces. This is where I’ll contradict my opening statement and say that we need to know where the data is going so we can get our capture in the middle. Not only do we need to know about which interfaces are involved we have to be mindful of any NAT or PAT rules associated with the connection.

NAT rules can be a huge source of frustration when attempting to capture traffic. The best way to determine which rules you’re dealing with is to use the ASA’s Packet Tracer. This will quickly identify which rules are triggered without having to dig through your configuration (or worse still) rely on xlate to catch the traffic when it happens. I’ll be covering Packet Tracer in a future post.

Now its time to build ourselves a fitting ACL using the information we’ve gathered.

access-list cap-traffic_inside extended permit tcp object-group AppHosts object WebApp eq http
access-list cap-traffic_inside extended permit tcp object-group AppHosts object WebApp eq 443
access-list cap-traffic_inside extended permit tcp object WebApp eq http object-group AppHosts
access-list cap-traffic_inside extended permit tcp object WebApp eq 443 object-group AppHosts

Using the newly created ACLs we can deploy a new capture in the same fashion as before.

ciscoasa(config)# capture cap_ingress access-list cap-traffic_inside packet-length 1522 circular-buffer buffer 524288
ciscoasa(config)# capture cap_ingress interface inside
ciscoasa(config)# sh cap cap_ingress

126 packets captured

   1: 11:06:14.131539 802.1Q vlan#1 P0 172.16.0.10.64295 > 66.228.61.143.80: S 3276323655:3276323655(0) win 65535 <mss 1460,nop,nop,sackOK> 
   2: 11:06:14.131935 802.1Q vlan#1 P0 66.228.61.143.80 > 172.16.0.10.64295: S 3332438458:3332438458(0) ack 3276323656 win 5840 <mss 1380,nop,nop,sackOK> 
   3: 11:06:14.132378 802.1Q vlan#1 P0 172.16.0.10.64295 > 66.228.61.143.80: . ack 3332438459 win 65535 
   4: 11:06:14.132561 802.1Q vlan#1 P0 172.16.0.10.64295 > 66.228.61.143.80: P 3276323656:3276324039(383) ack 3332438459 win 65535 
   5: 11:06:14.132744 802.1Q vlan#1 P0 66.228.61.143.80 > 172.16.0.10.64295: . ack 3276324039 win 6432 
[cont.]

With this ACL we’ve successfully isolated the web traffic of our internal hosts to the external website. While the tool has a few more options allowing you to take a deeper look into the content of the packets, it’s probably best left for a packet analyzer like Wireshark, especially given the tight integration between the two. The strength of the Cisco ASA Packet Capture tool is you can use the flexibility of ACLs to design capture rules and quickly get the results into your favorite pcap software for analysis.

slack – noctilus

Cisco ASA – Packet Capture