My first experience with Wireshark!

So during the programme, one of the stretch goals was to read a TCPdump file in Wireshark. But knowing it's going to be an essential tool for troubleshooting in the future I thought I'd start Chris Greer's Wireshark Masterclass YT playlist. Most important is he takes the time into how to capture packets using just the CLI, a good sign indeed. 

I have to say, during my first capture, I was blown away by the amount of information. I saw my wifi-extender sending out broadcast packets, I saw Youtube and even Blogger packets on the way! It was pretty impressive. I had, with no basis at all, always expected things to be far more static.


For practice and just to cement my learning, I have also installed Centos 9 on a VM and just issued a tcpdump command just to see how I'll be exploring networking issues in AWS after all. Even from the screenshot I could notice that the network traffic goes through the virtualised hardware and even shows my ISP!


Chris introduced the concept of Taps, not that useful for AWS of course, but did introduce me to the idea of SPAN ports. SPAN ports are simply ports within switches duplicate the traffic being sent on within the network - the idea being to log data across different points in the network, to provide a more detailed insight when troubleshooting. This led me to a quick little Google search and indeed, the VPC service has a traffic mirroring service! So some key learning points for me;

  • If you can use SPAN ports/Traffic Mirroring (AWS), do so, we want to be capturing network information as close as possible to the access point on the client side and ideally on the switch of the server side.
  • If the above isn't possible, try to simultaneously collect information from the client and server side, starting with the former, to give yourself the best opportunity to identify what the issue might be.
  • If you're dealing with a breach, you want to get as close to the pipe coming into the network.
  • But be wary of the capacity of your resources when running these data collection processes!
  • Where you deploy Wireshark depends on what issues we're having.
Another good tip I learnt was using the DNS resolving option, it made things far less obtuse as you can more quickly identify what's going on. Plus it's really fun to open a website side by side to Wireshark and see the packets show up in real time. Another handy tip is using the time column - if you right click on a packet, you can set it as the reference time, then allowing you to easily see the time taken for the corresponding packet you're looking for took to arrive. Once you're done using the time reference, two clicks and you're back to normal (Edit > Unset Time References).

Chris also emphasised using the Timestamps function when assessing a packet. The reason for using the Timestamp function is that it puts the time into greater context. If we're just using delta time column the main capture screen won't distinguish between different/simultaneous TCP handshakes happening at the same time. But by using the Timestamp function in a column (simply by right clicking and using the add as a column function) it puts the timing responses by the packets in context. Straight away I understood that this makes it a valuable tool when assessing network connectivity issues. Chris is also kind to mention, need to be aware that at the end of a conversation we might have a timeout or some idle time too. 

Chris also bought into play the usefulness of the statistics tab, letting us easily see conversations in the different types of network protocol. In the screenshot below, I'm filtering the conversation which had the most amount of bytes passed through. Unsurprisingly, this was Google as I'm watching Youtube.


What's most interesting however is when I saw the results of this filter, the protocol was something I've never heard of - quic. Being curious, as I  expected  HTTP or HTTPS, I gave it a quick Google to find out.
QUIC — Quick UDP Internet Connections — is a relatively new transport layer network protocol designed and implemented by Google. Despite being around since 2012, it's only recently become ubiquitous and is now used in most connections between Google Chrome to Google's servers.
Thankfully this adds up as I am using Chrome! The masterclass is concluded with GeoIP, which is about using IP's to map geographic locations, which is always the nearest network switch. I'm less impressed with this though as I was aware of this functionality. However, the extraction of objects from PCAP files did impress me! I can already guess how this might be useful in cybersecurity concerns. All in all, a fun evening, but I feel like this has been awfully superficial. Chris has two lectures on TCP/IP I've put on my watch list, but... I feel like the next step is to really try some traffic analysis labs out for a more hands on feel before this.

Popular posts from this blog

Network Fundamentals for the Cloud

Familiarizing with the Command Line Interface

Security Fundamentals for the Cloud

CLI Fundamentals for the Cloud

DataDog, a Cloud Analytics & Monitoring application

A brief introduction to Databases and MySQL

AWS CodeCommit + Creating a CI/CD pipeline

Future Orientation: Tips from a AWS re/Start Graduate

A brief introduction to AWS Cloud Adoption Framework (CAF) and Well-Architected Framework (WAF)

Building a VPC in AWS