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.
Another Sharkfest has come and gone, and once again it has been a great conference. If you’re into packet analysis, network forensics or network troubleshooting there is no other event that has the same density of information. It’s really a “specialist” conference, in a very open and friendly way, and newcomers are always welcome.
During Sharkfest 2015 I put up a challenge that was different from the usual challenges offered. The pcap files are a lot bigger, the task to solve less specific, and the answer not a simple “easy to verify” answer. I promised to put up my solution a few months after posting the challenge to this blog, but then some things got in the way. And then… some more got in the way. Sorry for that, but sometimes it can’t be helped.
After detecting a network breach it is a good idea to scan the network for further Indicators of Compromise (IoC) to check for further malicious activity. The IoCs are usually derived from forensic investigations into network packets and compromised hosts, and can be quite unique when it comes to more sophisticated attacks (let’s avoid mentioning the APT buzzword here… oh, wait… darn!).
When capturing frames from a network there is more information recorded into the capture file than just the bytes of each frame. If you have ever looked at the PCAP or PCAPng file format specifications you have seen that each frame has an additional frame header containing important information that wasn’t part of the frame itself.