Time always flies at Sharkfest, the annual Wireshark conference, and the 2017 edition – being the 10th Sharkfest in the US – has been no exception. On Friday Sake and me talked about how fast the 3 day conference had felt and we both agreed that “hm, it seems just to have started moments ago and it’s already time to go back home”. I don’t know about you, but for me and him that’s a sure sign of a good conference. Not a single boring moment.
During Tech Field Day Extra at Cisco Live Europe 2017 one of the presentations we attended was from Paessler, about their PRTG monitoring tool. I had only seen it once before, during a penetration test I performed at a customer site – and since it was running with default credentials it gave a very nice insight into the IT setup they had. But so far all my monitoring I had setup myself had been via Nagios or Icinga. So after the presentation I wanted to check out PRTG myself and installed a test version. After letting it run for a while I had seen enough to write a blog post about it.
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:
https://ask.wireshark.org/questions/55972/slow-writes-even-slower-reads-spanning-wan-to-netapp
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.
Recent Comments