I recently did a hands-on-no-slides presentation at a very small security conference end of last year where I demoed some of the typical things I do when performing a network forensics analysis, using tshark, Wireshark and TraceWrangler. I’ll use these blog posts as a transcript of what I did, so that it’s easy to read up on the various tasks I performed.
Most network captures are recorded using SPAN ports, as we’ve seen in the previous part of this series. Now that we know what SPAN is all about, it’s time to find out what TAPs are all about, and why you would want (or need) to use them in network capture. TAP is an acronym for “Test Access Port” – it’s a device you add to the network with the purpose of giving you access to ongoing communication.
We have briefly covered SPAN ports in previous posts of this series, but there are so many things to consider that we have to look at the advantages and problems more closely. Even more so since it looks like there is a constant “battle” going on between SPAN and TAP supporters – some analysts will tell you “you need to use a TAP!” while others will say the opposite.
In many of those cases the person asking a question on the Wireshark Q&A site posts screenshots or ASCII dumps of the packet list, which is very hard to work with when you’re trying to help. It is much easier if you can get a PCAP or PCAPng file instead, but there are two major problems with that: how to share the file, and how to remove sensitive information first.
One of the most common answers that come to my mind when being asked questions during or after a talk at a conference is the famous phrase “it depends…”. This may sound unsatisfactory at first, but the problem with a lot of questions regarding network analysis (and packet capture) is that there are always so many things to consider. So when we’re talking about using a standard network card like they are built into most PCs and laptops these days, the answer to the question of “is it good enough to capture packets?” is – you probably guessed it already: “it depends”.
In part one of the playbook series we took a look at general Ethernet setups and capture situations, so in this post (as in all others following this one) I’ll assume you’re familiar with the topics previously discussed. This time, let’s check out how speed and duplex can become quite important, and what “drops” are all about.
We had an interesting question regarding SMB2 performance on the Wireshark Q&A forum recently. Upon request the person asking the question was able to add a couple of trace files (=”capture” files). The question and a link to the traces can be found here:
Since the question nicely fits into the scope my talk on Sharkfest Europe last week I have asked the attendees to take a look at the question. For the next days the number of views increased significantly. So, here are my 2 cents.
Capturing network packets is the first step in any kind of network analysis or network forensics situation. Few people ever consider this an important step, but this is really where the analysis result can be heavily distorted if you’re not careful. During Sharkfest 2016 I talked about how important the capture process and it’s preparations are, and decided to start a series of blog posts about how to do network packet captures. So here we go with the first one, starting with basic network capturing in a wired environment.