Once again I was invited to join the group of delegates for Tech Field Day Extra at Cisco Live 2018 in Barcelona, with various presentations covering a number of new and improved Cisco technologies. One of them I had seen already last year at the same event in Berlin, but hadn’t had the time to cover it in a blog post: Cisco Tetration.
In the previous posts of the Capture Playbook series we discussed various approaches about how to record packets, but before going into more elaborate techniques of doing that we should talk about how a network troubleshooting project works, and especially how to plan a capture setup. In my experience this aspect of a troubleshooting is often neglected, which can be lead to problems during analysis. In the worst case scenario, a botched capture setup can make it impossible to find root cause in the packets that were collected.
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.