CloudShark released a new packet capture challenge for this Christmas season! Unfortunately, I don’t have the time to participate right now, but I wanted to reshare this for those of you that do. I also wanted this to serve as a reminder for me to come back to it later. Good luck!
Well, Tom and the team at CloudShark have put together an excellent packet capture challenge on their blog once again. It has actually been awhile since I’ve dug into a capture due to my recent shift in focus to Amazon Web Services, so this was a lot of fun for me. I feel like once you’re a “packet junkie” you are always one! <span style="color: #ff0000;">*SPOILER ALERT*</span> The rest of this post describes the challenge and the process I followed for solving the challenge.
I have attended multiple Wireshark webinars presented by Riverbed and leaders in the field. They title this series “Return to the Packet Trenches” with some sort of variation or subtitle for the different sessions. I always walk away with something new. This latest webinar was no exception. It reviewed several CLI options for creating, analyzing, and editing packet captures. I highly recommend attending these webinars if you have any interest in Wireshark and staring at packets.
One of the great things about Wireshark is the completely customizable interface. Users can change the layout, column settings, protocol decode options, add/remove buttons, change colors, add/remove filters, and more. There is a lot of documentation on how to even write new protocol dissectors. Due to its open source nature and the active development community, one can modify the code and/or participate in its official development. What this means is no two instances of a Wireshark install have to be the same.
One of the most common problems any IT admin faces is a software update. While software updates are generally considered a good thing, because they patch security flaws, fix bugs, try to improve performance, and more, they are also a common source of problems. Every admin knows to be ready for calls after a scheduled maintenance window. This issue was no different. A ticket came in stating users could not access a web app through the backend system after an upgrade to Java 1.
Everyone needs to do some housekeeping at different points, and I figured it was time I did some a basic security sweep of my setup. To get started, I performed a quick packet capture on the very server that hosts this blog. I decided to give one of CloudShark‘s newer and more distinct features a spin with my recently created account; their Threat Assessment tool. I thought it would be interesting to pit this against PacketTotal as well.
Problem I have come to expect vague error messages that seemingly blame the network. This one is no different. Server Error in ‘/’ Application. The network path was not found Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.ComponentModel.Win32Exception: The network path was not found
Have you ever had a nightmare where you are being chased and you can’t just seem to run away fast enough? No? Well, maybe you’ve tried running through snow up to your knees or swimming while wearing jeans. All of those examples point to situations that feel like something isn’t quite right. Cases where there could be better performance if only something was changed or improved. Sometimes this same thing happens to network devices.
Several hundred users lost network connectivity. They went down randomly, one by one, and over a short period of time. Some users had intermittent connectivity. All of the network devices were online and functional. Users were roaming the halls and getting bored. This called for a packet capture, but with clients offline it had to be done on a network switch. In this instance, the capture was performed at the distribution switch on the layer 3 VLAN.
How do you go about catching the one of the fastest things known to man (light) at a specific point in time with pinpoint accuracy over and over again? With a little patience and your network card, of course! This post is an introduction to the process of capturing network traffic (aka “sniffing” or “tracing”). With most of my blog being dedicated to network performance analysis, a post like this is foundational, and will help you understand the basics moving forward if you are new to “sniffing the wire”.