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