Wireshark Webinars

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. For more resources I recommend or to see the tools I've created, please look at my "Network Performance" drop-down menu at the top of this page. Here are links to their resources as sent to me in their follow-up email: Wireshark CLI tools & scripting (by Sake Blok) https://sharkfestus.wireshark.org/assets/presentations18/33.zip Presentation Video https://youtu.be/IZ439VNvJqo (1:11:14) TShark Command Line using PowerShell (by Graham Bloice) https://sharkfesteurope.wireshark.org/assets/presentations17eu/33.7z Custom LUA dissectors to the rescue in root cause analysis (by Sake Blok) https://sharkfesteurope.wireshark.org/assets/presentations17eu/21.pdf Review the SharkFest’18 EUROPE agenda and other information, For more "Packet Trenches"  resources, check out these links. Watch the replay...
Read More
Wireshark Profiles

Wireshark Profiles

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. Analysts can mold the tool into exactly what they need for their particular job. This is all done through the use of profiles. In fact, a single install can have multiple profiles. This is useful to tailor different profiles to specific protocols or troubleshooting scenarios. For example, one profile could be used for troubleshooting web traffic and another could be used for diagnosing wireless issues. I currently have about 10 profiles ranging from a minimalist view to one specifically for...
Read More

Problems After Updates?

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.7. The server, java, and app logs all looked ok and appeared to be running properly. Also, interestingly, the web app worked when accessed directly from a web browser. This sounded like a perfect opportunity for a quick packet capture and analysis. Here is what was produced:     *Note: In order to maintain the SSL session info I could not anonymize this, so I'm just using a screen shot instead of sharing the capture on CloudShark.   I've done quite a few...
Read More

Packet Threat Analysis

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. These are both great tools with similar, but also different purposes. At the time, I had SSH and web ports open along with a few other unused ports for various common services. The only true security measure in place was a few basic iptables rules. CloudShark What I Liked: Up front, quick severity level rating dashboard Brief descriptions of issues which helps puts everything in laymen's terms World map view Privacy settings External references to source data and additional information Ability to view the...
Read More
Case of the Named Pipes

Case of the Named Pipes

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 Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. (The stack trace is long and doesn't actually provide root cause either, so I omitted it to keep this post brief.) In this case, a web server was providing the error above after receiving a user request and attempting to connect to a backend database. Unless there are other dependencies, the problem is between the web server and database. Both ping tests and telnet tests to...
Read More
Case of the Tired Firewall

Case of the Tired Firewall

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. In this example, it's the case of the tired firewall. Problem It was a typical day in the office with users milling about drinking coffee, others happily working, and some furiously pecking at their keyboards with deadlines looming. For a small segment of users, though, things weren't normal. They were staring at their monitors with looks of puzzlement and confusion. Instead of working on their latest application update they were running tests with varying and unusual results. They found several symptoms, but were unable to pinpoint the root...
Read More

Case of the Rogue Server

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. It revealed clients frantically trying to connect but being rejected, dropped, and ignored. With everything down, something had to be done. The L3 VLAN was rebuilt and port security was removed. Nothing worked. An analyst at one point decided to clear the arp table. It helped momentarily, and then things fell back into disarray. That was the first real clue, though.   Viewing the ARP table showed the same MAC for several IPs including the client switch IPs. This MAC belonged to a device not managed by...
Read More
Capturing Light

Capturing Light

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". Networks range in size from small home networks with 1 PC to global corporations with many users and data centers, to the largest network (or collection of networks depending upon your definition) of them all, the Internet. While size, speed, design, and costs may vary, they all use the same signals to communicate. These signals may take the form of electricity (ethernet cables), light (fiber), and radio waves (wireless) across varying mediums. These...
Read More