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.
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://nullhaus.com).
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 188.8.131.52, 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.
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 184.108.40.206 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 > 220.127.116.11.80: S 4292592632:42 2: 06:39:34.005584 802.1Q vlan#1 P0 18.104.22.168.80 > 172.16.0.10.59278: S 2991127668:29 3: 06:39:34.005721 802.1Q vlan#1 P0 172.16.0.10.59278 > 22.214.171.124.80: . ack 299112766 4: 06:39:34.005950 802.1Q vlan#1 P0 172.16.0.10.59278 > 126.96.36.199.80: P 4292592633:42 5: 06:39:34.006133 802.1Q vlan#1 P0 188.8.131.52.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:
- http://ciscoasa/admin/capture/cap_ingress – Shows the same result as
- http://ciscoasa/admin/capture/cap_ingress/pcap – Allows you to download the pcap data for analyzing through Wireshark
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.
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?
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
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 184.108.40.206
As mentioned we’re interested in web traffic so we’re looking for port 80 and 443 traffic.
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.
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 > 220.127.116.11.80: S 3276323655:3276323655(0) win 65535 <mss 1460,nop,nop,sackOK> 2: 11:06:14.131935 802.1Q vlan#1 P0 18.104.22.168.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 > 22.214.171.124.80: . ack 3332438459 win 65535 4: 11:06:14.132561 802.1Q vlan#1 P0 172.16.0.10.64295 > 126.96.36.199.80: P 3276323656:3276324039(383) ack 3332438459 win 65535 5: 11:06:14.132744 802.1Q vlan#1 P0 188.8.131.52.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.