WIRESHARK- LOOKING INTO THE PACKET 1 Wireshark- Looking into the Packet Henry A. McKelvey, MIS Blacks in Technology
WIRESHARK- LOOKING INTO THE PACKET 2 Wireshark- Looking into the Packet Protocol Analysis is one of the best methods for troubleshooting network problems in and out of the cloud. Having designed, created and implemented technology for analyzing the cloud network. I think it is time to look at ways of defining the cloud from the inside out. One of the most interesting things about networks is that they usually tell you if there is a problem. Three basic issues occur with networks; slow throughput, no throughput, and corrupted data. Many things cause these issues to occur, and many events may occur because of these three issues, but these are the core. Incorrect configuration of switches/routers may cause these issues to occur. Incorrectly configured servers may also cause these issues to occur. The important thing is to be able to tell what is happening and why. This is where protocol analysis comes in. Protocol analyzers allows the network, or systems administrator to see what is occurring on the network, or what their systems are responding to and how. For instance, the protocol analyzer divides the transaction of packets up into usually 5-6 divisions of function based on the TCP/IP protocol stack.
WIRESHARK- LOOKING INTO THE PACKET 3 The Background First, you have Frame data (bytes on the wire) which constitutes the information linked to the Frame (Interface ID, Encapsulation Type, Time data, Frame Number, Frame Length, Protocols in Frame, etc...) This data can be used to help troubleshoot Layer 1 issues and situations if the network (Physical Layer) baseline is known. Second, you have the Data Link Layer data (Based on Encapsulation Type) which constitutes the information linked to the data link mode of your system, usually Ethernet, but can include Frame Relay, ATM, or other Layer two technologies. The sections covered in Ethernet are Source Media Access Control Address, Destination Media Access Control Address. Information gathered from Address Resolution Protocol (Source MAC Address, and Destination Internet Protocol Address linked to MAC Address, Source and Destination LG and IG bits used to show globally unique address and individual address positions (Extracted from the MAC Address) and then the Ether Type for Ethernet, this is 0x0800.
WIRESHARK- LOOKING INTO THE PACKET 4 Third, you have the Internet-working Layer data. This section includes the IP Version (4 or 6), header length, Differentiated Services, Explicit Congestion Notification (ECN), total length of packet, packet identification, flags (Reserved bit, Don t Fragment, More Fragments, Fragment Offset, Time To Live, Protocol (TCP/UDP), header checksum, checksum data, source and destination domain to IP link.) Fourth, you have the Transmission Control Protocol layer data, which gives you the source and destination port data, sequence number, acknowledgement number, header length, flags (reserved, nonce, congestion window reduced, ECN-echo, urgent, acknowledgement, push, reset, synchronization, and finish), window size, checksum, and analysis of sequence and acknowledgement length. Fifth, you have the data, which is sent or as it is called the payload. The data also includes its Now, you might ask, What is this review of the protocol stack for? Well it is to show you, the reader, that the protocol analyzer can contain data that you need to complete your work or at least tell you where a problem may exist. For instance, I was working on a project and one of the programmers was having a problem getting her program to run. The young woman was a pure programmer with no knowledge of network or other data resources experience. She knew how to program and that was it. Therefore, it was no surprise when she made a call to a process to execute a command on another system her program would fail. She traced the fault to a
WIRESHARK- LOOKING INTO THE PACKET 5 command that made a system call using a socket (IP Address: Port). She was told by her project manager to talk to one of the network people (me) about the issue, so what did I do. On her system, I installed a protocol analyzer and looked at her interface, just as expected the program could not locate the asset online. Therefore, I told her that the program was working fine and that before the system call she should write some code to do a resource check that would either put the program into a wait condition with periodic checks or throw an exception that states that the resource is busy and to try again later. She wrote the code to do both and when the remote system was back up and running the program ran without a problem. This is one example of how protocol analysis can be used to aid in network troubleshooting that extends into the realm of programming. The program was making use of cloud assets, which permitted the use of a protocol analyzer. Why is this important? As more programming ventures into remote or virtual connections, as in connecting to virtualized and cloud-based systems, the use of protocol analysis will become more commonplace. A once ignored facet of network troubleshoot is going to become a widely used method of verifying network connectivity of virtualized and cloud based systems. There are many Protocol analyzers out there and they all function in and about the same. However, there is a complexity involved with using a protocol analyzer to troubleshoot network wide issues and events. I experienced this while working at Verizon. I was helping a colleague troubleshoot a network problem, which required the use of multiple protocol analyzers installed to provide data as to correlate network events with network problems, using the multiple analysis
WIRESHARK- LOOKING INTO THE PACKET 6 systems was easy but correlating the data was not, because the units were not synced up and the data was captured at different times. It was during this comedy of errors that an idea emerged, that leads to a method being developed to provide correlation to the protocol analysis/ capture process. After some time and effort, we (Jimmie Peterman, Rosa Underwood, Emory Young, and I) developed a way to capture, and correlate data that could be used on Enterprise Networks to troubleshoot events in such a way a person could tell what was happening without having to have an extensive knowledge of the network. The method and device was the subject of patent application 20110317562 and the subsequent granting of United States Patent US8064350. Understanding the layout of the protocol analyzer is one thing, but looking at it for the data that can be harvested from a capture is the power of the analyzer. I have attached a file to this document to help you understand how read a protocol analyzer during a simple troubleshooting exercise that will be discussed in the latter part of this paper. For now let us discuss the technology of protocol analysis. The Technology To some of you this may appear to be a mundane exercise, but one thing I have seen consistently is the writing of programs for use on the Internet/Cloud and people having problems with the application of remote sockets. This is a problem made for the use of a protocol analyzer. There was a time where the protocol analyzer was used only for network troubleshooting. To use
WIRESHARK- LOOKING INTO THE PACKET 7 a protocol analyzer you had to invest in a system that may have cost thousands of dollars, but because of the open source movement, you now have a choice of free very well coded software based protocol analyzes such as Wireshark (I use this one so this will be about Wireshark). Like I had mentioned in the past your choices were limited to some very costly equipment such as the Hardware based Radcom Protocol Analyzer, Teledyne LeCroy Analyzer, and the HP/Agilent LAN Analyzer, on the software side you have EtherPeek and Agilent s analyzer software. The fact was to do protocol analysis you had to spend a lot of money, which put the proper troubleshooting of network problems out of the range of most small companies. Then the Security Administrator Tool for Analyzing Networks (SATAN) was invented. SATAN is a tool to help systems administrators. It recognizes several common networkingrelated security problems, and reports the problems without actually exploiting them (porcupine.org, 1995). SATAN permitted for the first time (open source tool wise) the viewing of network activity in response to network stimuli. This opened the door for other advancements such as Ethereal, which was the first full, featured open source protocol analyzer. Now, take into mind that it was not the first open source protocol analyzer, it was the first full featured protocol analyzer (there is a difference). Ethereal remained the number 1 free open source protocol analyzer for years, before finally being surpassed by Wireshark. Now, this is another gotcha Wireshark is Ethereal all grown up. Wireshark expanded on the feature sets of Ethereal and
WIRESHARK- LOOKING INTO THE PACKET 8 added a lot of support for other network technologies that were left out of the Ethereal feature set. Now since we all like free stuff, I am going to guess that Wireshark is looking good to you now as a possible alternative to the standard protocol analyzers. If so, go on line and download it. It will load two major pieces of code the first is the Wireshark package, which includes the analyzer and the protocol modules. The next piece of code is the subsystem that permits the capture of packets over the network interface, this code is called pcap (for UNIX/Linux) or to be more inclusive WinPcap (For Windows). I would be amiss if I did not discuss pcap and its role in the use of protocol analysis. Packet capture (pcap) is a command line tool that contains the APIs, which permit the capturing of packets over the network interface of a system. The program itself from what I know is written in C. This permits higher-level languages (Java, TCL,.Net, and other scripting type languages) to pass and receive variables/data-sets and to interact with the pcap program in an almost seamless fashion. In fact, on Linux and UNIX systems TCPDUMP uses the pcap library (libpcap) to provide packet capture output. *Note: The TCPDUMP group wrote pcap. Packet Capture (pcap) can be used as a standalone program or a wrapper (Ethereal, Wireshark) that permits GUI use of the library can access it. Many programs use the pcap library, which makes it one of the most used programs in the network arena.
WIRESHARK- LOOKING INTO THE PACKET 9 Now since we have discussed the histories of Wireshark and Pcap, let s get into the actual use technology embodied by these two programs. When used in unison the two programs are able to provide information as to the condition of the packets in a network. The next part of this three-part blog will be how Wireshark works. I will be examining a way of troubleshooting a web site problem using two Protocol Analyzers. This method will be based on a system that I helped design and was the topic of US patent # 7,899,323, MULTI-INTERFACE PROTOCOL ANALYSIS SYSTEM. Now take into mind that I will not be doing the full implementation of patent #7,899,323 just a subset that will permit me to show how to use Wireshark and TCPDUMP to troubleshoot problems in the cloud. The Application This is the fun part; first we need to know what a good web site session looks like using Wireshark. This paper has attached to it a file containing a Wireshark capture of a good web site session to www.google.com and other sites. The start of all troubleshooting begins with the development of a baseline capture to level-set readings. This is done to provide a comparison between a good reading and a possible bad reading. I will use a real life problem I experienced troubleshooting a problem on an executive s computer at a company where I use to work. Starting off here is an analog of a baseline capture file:
WIRESHARK- LOOKING INTO THE PACKET 10 To use this file you must first have Wireshark and WinPcap installed on your Windows machine. If you do not have it please install it now. If you have Linux it will come with your Linux distribution if not use one of the two methods of installation on the Wireshark web site to install Wireshark on your Linux or Windows machine. Once Wireshark and Pcap are installed. Click on the Baseline.pcap file. This will open the file up in you Wireshark program. At this point the output will look like this: (See Next Page) Figure 2
WIRESHARK- LOOKING INTO THE PACKET 11 Wireshark Capture without Network Layer Decode This will give you the raw TCP\IP data without decoding it for URL viewing. To allow network decoding to take place, follow these instructions: 1) On the menu bar item View 2) Select Name Resolution 3) Click on Enable for Network Layer 4) On menu bar click on Reload symbol The screen should now look like this:
WIRESHARK- LOOKING INTO THE PACKET 12 Figure 3 Wireshark Capture with Network Layer Decode Notice in Figure 2 on line 4 you have the IP address of 75.75.75.75, then on line 4 of Figure 3 you have the domain name of cdns.comcast.net this shows that the system decoded the IP Address into its domain name equivalent. This is vital in troubleshooting this problem. Since this is the baseline we can consider this file to be good in comparison to the next capture (The infected machine). (See Figure 4)
WIRESHARK- LOOKING INTO THE PACKET 13 The infected machine has the following problem. When the user selects www.google.com they are sent to a failsafe page for yahoo.com. This in and of itself is no problem but it denotes a possible issue with web site locals. The following is a lesson in how to use protocol analysis to solve this problem. The following is a copy of the infected.pcap file: From your machine open up the infected.pcap file Click on the infected.pcap file. This will open the file up on your Wireshark program. At this point the output will look like this: (See Next Page):
WIRESHARK- LOOKING INTO THE PACKET 14 Figure 4 Wireshark Capture without Network Layer Decode This will give you the raw TCP\IP data without decoding it for URL viewing. To allow network decoding to take place, follow these instructions: 1) On the menu bar item View 2) Select Name Resolution
WIRESHARK- LOOKING INTO THE PACKET 15 3) Click on Enable for Network Layer 4) On menu bar click on Reload symbol The screen should now look like this: Figure 5
WIRESHARK- LOOKING INTO THE PACKET 16 Wireshark Capture with Network Layer Decode If you notice what is happening on the wireshark screen it is telling you that the IP Address of 98.139.144.130 is connected to the yahoo.com site and not the google.com. By performing an nslookup on the infected machine you get this: Figure 6 nslookup of Google on the Infected Machine
WIRESHARK- LOOKING INTO THE PACKET 17 Taking into mind what is happening; here we can see that the nameserver lookup and the domain name that occurred as the result of the web search are not the same. In fact the IP Addresses to google.com are in the 75.125.131.xxx range. Performing nslookup on your machine you get: Figure 7 nslookup of Google and Yahoo on the Baseline Machine
WIRESHARK- LOOKING INTO THE PACKET 18 Using simple logic at this point you can surmise something other than the nslookup is supplying the errant IP Address, the question is what can do this? Granted this was a simple problem, but it shows the use of Wireshark in proving there was a problem within the system. In conclusion, it can be said that wireshark is one of the most useful tools in finding out what problems may exists on your network. However there are many features that Wireshark has which must be learnt to master this tool. Here is some suggested reading material and web sites for those who may want to develop further skill in using Wireshark: http://www.wiresharktraining.com/ http://www.amazon.com/s/?ie=utf8&keywords=wireshark&tag=googhydr- 20&index=aps&hvadid=21387143575&hvpos=1t1&hvexid=&hvnetw=g&hvrand=1041059935155915014 7&hvpone=&hvptwo=&hvqmt=b&hvdev=c&ref=pd_sl_2789p0sl8p_b Read and enjoy using Wireshark.