Performance monitoring is two-fold. There is proactive performance monitoring and reactive investigation. The majority of my posts and case studies reflect the latter. This post is more related to the former. Services on premise typically rely on SLAs, NetFlow, scripts, synthetic transactions and more to provide monitoring and alerting. While some of this is possible in the cloud to keep track of specific pieces, you first need a good foundation by knowing if the underlying technology by your cloud provider is operating as expected.
The phrase, “I can’t access my shared drive” was intermittent, but becoming common for a remote location connected via an MPLS circuit. Without hesitation the finger was pointed at the network and my phone rang. People connect to shared drives everyday, but it is one of those things they take for granted. Behind the scenes there are many layers of technology, protocols, and devices working together to make those connections happen.
As mentioned in this post, you can create and share custom profiles. However, that is not the extent of profile management. Another great way to utilize these files is to synchronize Wireshark profiles between systems. In this day and age you probably have more than one computer (laptop, VM, home desktop??). Also, if you’re like me you probably have Wireshark installed on anything you can get your hands on! It can be a bit of a pain to keep your favorite Wireshark settings such as protocol options, coloring rules, and saved display filters up to date with each Wireshark installation.
As mentioned in this post, Wireshark is easy to customize and even provides the ability to share custom profiles. Just about everything that can be modified can be shared. I outlined several of those items in the linked post. Wireshark uses files to store the config items located in a couple of key places. The ones I have shared below are all contained in the “Personal configuration” directory. To get sharing right away follow these steps:
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.
I’ve helped many users who say Fiddler has “fixed” their issue. Unfortunately, this is a bit deceptive. Fiddler is an excellent debugging tool for web apps, but it does not permanently resolve problems. What it does do is act as a proxy with its own connection settings. This allows it to act as a “man in the middle” and even decrypt the traffic to provide better more insight into application behavior.
Just because you can do something doesn’t always mean you should. One such example of this is using large HTTP headers. While the HTTP specification itself doesn’t set boundaries, most web servers have default limits around 8 KB. Other devices in the path such as firewalls/WAFs, proxies, and load balancers also have similar limits. Problem The application testers were receiving a reset error. Their application and web server logs did not show any problems.
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