Don’t Install Wireshark on Your Windows Server

The other day, I was reading through the InfoSec Community Forums on the SANS website, and I came across an interesting article, titled: “No Wireshark? No TCPDump? No Problem!“. Personally, I thought the article had to be a joke. On many occasions, I have found myself in situations where I needed to troubleshoot a server, and the natural course of action was to install an application (like Wireshark) or think of an elegant troubleshooting method that added time to issue resolution and more complexity overall.

As server admins we should despise unnecessary complexity. Thankfully, there is a better way to troubleshoot: use network shell (netsh) and Microsoft Message Analyzer. Of course, this assumes you are using Windows Server 2008 R2 or higher and/or Windows 7 or higher – if you’re not, we have bigger problems. Let me walk you through my experience taking this solution on a test drive.

Within 10 minutes of reading the article, I downloaded the referenced Microsoft Message Analyzer application to my laptop (and only my laptop), and completed a netsh trace capture using native tools on a test server. Sure enough, the capture ran and I was able to copy the capture file to my laptop, open it up, and review it! Just an FYI, if you need to load the trace file into another application, it can be exported as a PCAP and loaded into another program.

So how does the process work? Let me give you some high level points:

Basic Netsh Trace Command

Pretty simple:
netsh trace start capture=yes

Scenarios/Providers

There are additional parameters called “Scenarios” and “Providers” that you can add to the netsh trace command (like pre-built filters) to troubleshoot specific issues. Using these parameters, the trace will only collect specific events/components of the network stack, for example, limiting the trace to items that only relate to Microsoft file sharing:
Scenario=FileSharing
I didn’t use Scenarios and Providers in my initial tests, but I can see clear benefits for future troubleshooting scenarios.

Ethernet Options

When running other packet capture apps in the past, I typically want to know a specific IP type and address, particularly when troubleshooting client/server connectivity issues. You can do that with the netsh trace command as well.

Ethernet Type and IP Address

Pretty simple:
Ethernet.Type=IPv4
IPv4.Address=xxx.xxx.xxx.xxx

Capture Interface:

The capture interface is used to identify the interface you want to capture traffic on, pretty straightforward.

To get the list of interfaces, and GUID’s (you can also use names), run:

netsh trace show interfaces

To specify interface you want to capture traffic on, run:

CaptureInterface='{GUID-WOULD-GO-IN-HERE}'

There are a handful of help commands in netsh, here are a couple I found useful:
netsh trace show CaptureFilterHelp
netsh trace show interfaces
netsh trace show scenarios
netsh trace show providers

To test this out, I wanted to run a packet capture against traffic from my test mail server and my laptop. Here are the basic steps:

1. 1. Open command prompt and run the command below:

netsh trace start capture=yes Ethernet.Type=IPv4 IPv4.Address=192.168.1.1 CaptureInterface='{321DSA-132D-3213-AA33-DFF123712D}'
*Note: replace the fake GUID and IP above with something applicable to you.

It will let you know the trace is starting, where the trace file will be, if it is appending to the file (Off = replacing it), how large the file can get, etc.

1. 1. After allowing the trace to run (and ensuring traffic over the interface), run:

netsh trace stop

1. 1. It will take a moment to compile the Microsoft-proprietary ETL (Event Trace Log) file type, but it will let you know when it is done:

Correlating traces ... done
Merging traces ... done
Generating data collection ... done
The trace file and additional troubleshooting information have been compiled as ...
File location = ... \NetTraces\NetTrace.etl
Tracing session was successfully stopped.

1. Navigate to the location mentioned in the output for the “NetTrace.etl” file and copy it to your laptop.
2. Open the Microsoft Message Analyzer app, open the .etl file and dig in.
3. After creating a few view filters, you can quickly determine what the problem is.

As with any new tool, it may take a minute to get used to the syntax. However, if you have installed something like Wireshark, you can easily figure this out. If you prefer, you can also run the capture, copy it over to Message Analyzer, Save As > Export (to a pcap file), and use Wireshark (or your application of choice) to review the capture and figure out what’s going on. Regardless, if you use this method, you don’t have to install anything on your production server and you can gather everything you need, quickly.

So can you install Wireshark on Windows Server? Of course you can, but why would you want to?