At its root, effective network security is about packet analysis: the ability to distinguish between good packets and bad packets. Obviously many additional layers of complexity must be considered when performing packet analysis, but prudence dictates that security admins interested in strictly adhering to network security essentials should be well-versed in the most important of network analytic tools.
Wireshark is to security as a screwdriver is to home maintenance.
In the spirit of security fundamentalism, let's take a look at one of the most capable network packet-capturing tools available today, Wireshark, along with the most important security issues that four of Wireshark's features can help enterprises address.
Every so often, a system administrator may feel the need to ensure that his or her enterprise's firewall is blocking what it is supposed to be blocking. Or, it may simply be necessary to double check the accuracy of a firewall configuration. For example, virtually no plausible excuse exists for the allowance of telnet traffic into any enterprise network; most firewalls are set to block TCP port 23 by default. However, an admin should occasionally verify that this is indeed the case.
To use Wireshark to check the validation of an enterprise firewall regarding telnet traffic, system administrators can run a capture on a node that is internal to and in-line with the gateway firewall. Type the following filter into the filter display at the top of the Wireshark graphical user interface:
Next, log into a node external to the firewall and attempt to make a telnet connection with a node internal to the firewall's network. If any telnet traffic begins to appear within the Wireshark capture, the system administrator should double-check the firewall configuration; it likely indicates an improper configuration. If the configuration is correct, then a much more serious problem exists, and the vendor should be contacted immediately.
Most enterprise networks contain some sort of logging and alerting mechanism used for the sole purpose of network awareness. These mechanisms may be used in conjunction with an intrusion detection system (IDS) or as part of an all-encompassing security information and event management system (SIEM). These types of products depend almost entirely on proper packet capturing, and if an administrator were curious with regard to what exactly occurs in certain segments of the network, he or she could configure a monitor port on one of the Layer 2 switches within the network. Assuming that the network has a subnet of 10.0.0.1/24, the following Wireshark display filter should be used:
All packets that fall within the above-specified subnet will appear within the Wireshark capture, and the system administrator can adjust as appropriate. For example, the admin can get more protocol-specific by typing in the following:
ip.addr==10.0.0.1/24 && ssl
This filter is useful for detecting encrypted traffic within a specific IP range. Because certain types of malware use SSL as an encryption mechanism, this may help administrators more accurately pinpoint which hosts are infected with SSL-enabled malware.
Many times during the course of an intrusion event, small and medium-sized businesses have little in the way of IDS visualization outside of the basic command-line output offered by the open source IDS Snort. Various third-party vendors have made valiant attempts at creating a GUI for Snort, but I prefer the poor man's way of visualizing Snort capture data: Wireshark.
To create a GUI for Snort, system administrators simply have to save the Snort data to a .pcap file and then open the file with Wireshark. At this point, analyzing the various TCP streams within Wireshark should make for a riveting afternoon, but in all seriousness, it's often a more insightful way to analyze Snort data.
When a network is connected to the Internet long enough, it is generally accepted that malware infections -- no matter how advanced the enterprise security strategy -- will inevitably occur. Therefore, a properly staffed enterprise network should always have a malware analyst on hand to quickly sort through such infections and perform initial diagnoses. However, some organizations cannot afford such a luxury; this is where Wireshark features come into play.
More info on Wireshark
Catching network traffic with Wireshark
Wireless sniffing best practices using Wireshark
Top 10 reasons to learn Wireshark, the open source network analyzer
Cloud monitoring tools: Troubleshooting with Wireshark in the cloud
When a piece of malicious or suspicious code penetrates the network boundary, it is imperative that a copy of the executable is quarantined from the rest of the network in a virtual environment. With a Wireshark capture running inside the virtual environment, the system administrator should run the executable and look at any and all traffic that begins to move across the screen. If the environment is completely quarantined from the rest of the network and DNS attempts to strange-looking URLs begin to appear on the screen, the administrator should quickly record the IP address and DNS information and immediately place a correlating block on the firewall. This should serve as a temporary fix until a more in-depth analysis can be performed.
These four Wireshark features are the tip of the iceberg when it comes to the product's full line of capabilities. I believe Wireshark is to security as a screwdriver is to home maintenance. Its use cases are many and the need for it is constant. From simple network awareness to malware triage, Wireshark has proven to be a must-have in any security professional's tool belt.
About the author:
Brad Casey holds a Master of Science degree in information assurance from the University of Texas at San Antonio and has extensive experience in the areas of penetration testing, public key infrastructure, VoIP and network packet analysis. He is also knowledgeable in the areas of system administration, Active Directory and Windows Server 2008. He spent five years doing security assessment testing in the U.S. Air Force, and in his spare time, you can find him looking at Wireshark captures and playing with various Linux distributions in virtual machines.
This was first published in February 2014