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.
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!).