A secure data center can save your business from costly downtime and risks from outside sources.
The traversal of packets across a given network carries with it a certain risk that must be addressed to some degree by every person that brandishes the title of security professional.
On any given day, network packets enter enterprise networks by the millions, and it is the responsibility of the security professional to parse through the flood of network traffic in an effort to block or otherwise mitigate malicious packets. Numerous methods have been developed in an effort to automate the above-mentioned parsing, such as intrusion detection systems, intrusion prevention systems, Web application firewalls, etc. These methods, when deployed properly, can be quite effective at real-time interception of malicious traffic.
However, many times, network attackers successfully scale the walls of these previously mentioned defense mechanisms, and all too often these successful penetrations are not discovered until well after the fact. It is at this point in the dance between attacker and defender that the defender must be well-versed in the art of Wireshark analysis.
Step one: Set up capture points
One method the enterprising security professional might try as a means of verifying the effectiveness of their firewall involves starting a Wireshark capture in two different places on the network. First, start a Wireshark capture in promiscuous mode on some type of pass-through device within the demilitarized zone. This will allow for the capturing of all nonfiltered packets attempting to enter the network. Next, start a Wireshark capture on a device immediately behind the firewall. Depending on the network topology, a monitor port might require provisioning. After a predetermined amount of time, save the capture and begin analysis.
Step two: Did something happen?
Compare the two packet captures mentioned above in conjunction with the rules that were set up in the firewall and examine the data for any discrepancies. For example, many firewalls are set up to block any and all Telnet traffic on TCP port 23. One could attempt to make a Telnet connection to an internal network device from outside of the network boundary. Examine the externally placed Wireshark capture to ensure that Telnet traffic was definitely sent in the direction of the firewall. Then, examine the internally placed Wireshark capture and type "telnet" in the Filter field. Run the filter, and if any Telnet traffic has been captured, it's time for a serious examination of the firewall configuration.
The vigilant security professional should keep in mind that the above-mentioned Telnet test is very basic and therefore not likely to display any results, because even the least-sophisticated among modern-day firewalls easily block the traditionally unsecure protocols, such as Telnet and FTP. However, in the interest of getting one's feet wet, the test mentioned above is a good start. So, after beginning another Wireshark capture on the two network devices, begin to delve deeper into the packets.
Step three: Batten down the network ports
After a predetermined amount of time, stop the Wireshark captures and save the PCAP files. If the network running the two captures has any Internet presence at all, then the number of packets within the respective captures will quickly reach into the thousands.
Most businesses want some type of Web presence, which establishes two probabilities: The business has a Web server, and that Web server most likely has TCP port 80 open. Since HTTP traffic over port 80 does not require any type of authentication, many attackers find that the manipulation of the HTTP packets themselves is an easy method of walking through the front door and stealing all of the valuables. Simply put, HTTP packets are allowed to pass through most firewalls, so it stands to reason that many attackers attempt to piggyback on these authorized entries as a means of walking through the front door.
For example, a malicious user could manipulate an HTTP packet in a way that causes the Web server to respond with excess amounts of sensitive information that the user is not authorized to view. More specifically, a malicious user could insert a path name with a wild card character at the end that instructs the receiving node to send the malicious user all files in a given directory. For example, a malicious HTTP GET method could look like the following:
GET /complete_table/*.html HTTP/1.1\r\n
If the firewall is not configured to conduct deep-packet inspection on all Web traffic, the above-mentioned string could allow the end user to retrieve all HTML files within the /complete_table/ directory. With the internal Wireshark capture still open, type the following in the field entitled Filter:
http.request.method==GET && http.request.uri=="/complete_table/*"
Replace /complete_table/* with the path containing the files that are accessed via HTTP. If the Web server is Linux-based, then the path may look something like the following:
The specific entry following the http.request.uri field will obviously vary from network to network, but the point is to look for any wild card characters such as * that look out of place. If any are spotted, delve deeper until a logical explanation is found.
Firewalls and other such network defense solutions vary greatly. Some devices are high in quality, highly configurable and high-performing. Others are more of a stopgap measure until a more viable solution can be worked into the budget. Whatever defense mechanisms are chosen by an Internet connected organization, the need for human intuition in the way of network packet analysis will be a constant for the foreseeable future.
About the author:
Brad Casey is an expert on network security with experience in penetration testing, public key infrastructure, VoIP and network packet analysis. He also covers system administration, Active Directory and Windows Server 2008, with interest in Linux virtualization and Wireshark captures. He spent five years in security assessment testing for the U.S. Air Force.