Preparing for the Capture

Packet captures give us a very detailed and in-depth look at network traffic. They can be used to establish baselines, discover network devices, diagnose application and performance issues, or identify security threats. The previous post described what packets are and their function at a high level. It also gave an overview of the process used to capture them. Once you have identified your purpose for performing a capture, you can begin preparing for it. Caution: This is where things get technical pretty fast. A good knowledge of basic networking concepts will help from this point forward. This post will also be a little lengthier.

Preparing for a capture follows the same basic process regardless of the purpose, albeit a few tweaks here and there:

1. Select the capture point(s)
2. Choose the capture method
3. Apply the appropriate filter(s) and configuration_**Post-prep actions**_
4. Begin the capture
5. Perform the task to generate target traffic if needed
6. Stop and save the capture
7. Analyze the packets

1. Select the Capture Point(s)

This first step is one that does vary a bit depending on the purpose of the capture, network and application architectures, and technical limitations. The most basic setup is to capture on a PC (or server, tablet, laptop…) to watch traffic to/from itself. This is useful for anything pertaining to that 1 device, or practice, or training. This is the setup we will focus on for simplicity’s sake. A list of the various setups include (but aren’t limited to) capturing on a:

• local device – what this post is demonstrating
• network device (switch, router, firewall, load balancer, wireless access point)
• remote device – utilizing remote Wireshark functionality, SPAN, ERSPAN, or a Network Tap
• centralized packet broker – device that collects traffic from multiple sources, uses filters and rules, and passes select traffic to various tools. Gigamon is a company in this space where I have personal experience with their products.
• monitoring or security appliance – some appliances monitor traffic continuously and allow you to export packets based on specified criteria.

For those that are more visual, here is a high-level sample graphic of depicting a few of the options.

[][2]

For performance and security issues, the general rule of thumb is to capture as close to the symptomatic client as possible. We want to see what the end-user is experiencing and work from there. Sometimes this may be a local/user’s PC. Other times, admin rights may not be granted, so a capture point is needed at the next hop. Still yet, there may be too many clients identified, so a common shared point is necessary. Multiple capture points along a path are also sometimes required; allowing a packet to be followed throughout the network. Explaining when you would use each of these strategies in detail is too much for this post, but it might be worth writing about some time in the future. Also, please know the strategy chosen might contribute to or exaggerate the problem by adding traffic to an overwhelmed device or link. Please be cautious!

2. Choose the Capture Method

Now that we know why we want to capture, what we want to capture, and where in the architecture we want to capture, we need to choose how we want to capture.  There are various methods to choose from with some key differences. I’ll provide a list again and leave out the long-winded technical descriptions for later posts. This isn’t exhaustive, but serves as a good basic list to get started.

• Wireshark – industry standard graphical application (what this tutorial will use)
• Riverbed SteelCentral – Graphical application whose strength lies in reporting and large captures
• Microsoft Network Monitor – Graphical Microsoft utility
• tcpdump – industry standard command-line tool
• dumpcap – Wireshark command line utility great for long-running captures
• windump – Windows Wireshark command line tool
• tshark – command line utility specializing in exporting fields
• rawcap – command line utility excellent for quick, lightweight captures without requiring admin rights
• many other vendor-specific or specialized tools

3. Apply the Config and Filters

Every utility has varying configurations and filter syntax, but the concepts are the same. Configuration options include a one-time user-led capture, a one-time capture limited by file size or time, an ongoing capture with rolling files, or captures only exporting text or information instead of full packets. Make sure your network card is in promiscuous mode if you are capturing traffic that isn’t specifically to/from the device. Monitor mode is also crucial for wireless captures. Wireshark’s capture options look like this:

[][3]

Filters (both capture and display filters) can be quite extensive, but commonly include IP addresses, ports, protocols, MAC addresses, or packet size. Of course, wireless captures will include more specific filters to wireless technologies. These filters will reduce your file size and save your disk space. They will also help narrow the traffic down making analysis easier. However, too much filtering may also limit the ability to effectively analyze the capture due to removing the desired traffic. Please use capture filters sparingly. Display filters are usually more desirable. They are applied on the saved capture, but still allow access to view all of the traffic. Wireshark’s capture filter window looks something like this:

[][4]

As you can see, you’ll have to learn and know the filters or save them as a bookmark.

At this point, everything is set and ready to start capturing. Before the start button is pressed; however, the decision has to be made as to when to start the capture. Is this something that can be started immediately? Does it need to wait for a testing or problem window? Either way, if possible, the capture should be started and completed just before and after the target traffic.

For more information, refer to Wireshark.org’s guide here.

<< Intro           Performing a Capture >>