Wireshark - Ethereal Tutorial - Part 2

Discussion in 'Networks' started by zebulebu, Aug 12, 2006.

  1. zebulebu

    zebulebu Terabyte Poster

    3,748
    330
    187
    Here's part two - just finished writing it up for my trainee geeks at work :biggrin

    As before, let me know if you have questions or want any help with it.

    Capture Analysis

    In the first part of this tutorial we saw how to install Ethereal, configure your interfaces and begin capturing data. This part of the tutorial will cover the basics of analysing your capture files, giving you a basic understanding of how to use the interface, what each window shows and providing pointers to further learning. In the final part of the tutorial, I’ll show you how to analyse a capture of something a little more exciting than the PING probe you made earlier.

    For now, let’s stick with the PING capture you performed in the first part of the tutorial. Providing you followed my advice and stopped capturing straight after your PING probe was complete, you should have no difficulty locating the packets that represent the PING session – they will be at, or near the bottom of the uppermost pane in the Ethereal interface. Helpfully, you’ll notice that Ethereal colour-codes packets according to protocol. Your colour for ICMP packets may be different, but as you can see, mine is a lovely shade of violet.

    The Ethereal interface

    Before we go any further, lets take a closer look at the Ethereal interface so you can familiarise yourself with the different elements it contains. Right at the top of the screen is the traditional menu bar, with the equally traditional toolbar situated just underneath it. These contain commands & options just like any other program. Directly underneath the tool bar there is a series of three windows, displaying the data you have captured. The top window is called the Summary Window. This displays a single-line summary of each packet captured by the program. Underneath this is the Protocol Tree Window – which displays the packet in much more detail. The final pane is the Data View Window. This is where the raw data comprising the packet is displayed. OK – with that explanation out of the way, on with the analysis.

    Understanding the analysis procedure

    To begin with, let’s examine the first packet that represents the start of your PING session. (Now don’t get pedantic, I know that there are probably two ARP packets directly above requesting the MAC address of the IP you pinged that represent the REAL start of the PING probe – but we’re only interested in the actual ICMP packets themselves at the minute – but give yourself a pat on the back if you were about to raise an objection, it shows you understand basic networking!)

    If you highlight the first packet in your PING session by clicking on the row representing it in the Summary Window, you’ll see this packet turns a dark blue colour – alerting you to the fact that it has been selected. You’ll also notice the Protocol Tree Window now shows a different set of data than it did – this is the packet information for the first packet in your PING probe. This is where the meat of the information about the particular packet being examined is located. Whilst the Summary Window provides you with a basic idea of what a particular packet contains, the Protocol Tree Window shows you all the information contained in the packet, including headers, protocol information and payload.

    So let’s take a closer look at the Protocol Tree Window. All packets contain a set of information that both describes the packet and the data it contains. This information varies from protocol to protocol, but can contain things such as a sequence number, date/time information, source address, destination address, protocol type, MAC addresses and any of a whole host of other things – as well as the data itself. This can make the process of examining each packet a pretty complex and time-consuming task. Luckily, we’ve chosen an ICMP packet here, which are relatively easy to understand. The easiest way to look at the Protocol Tree Window is to see each packet as a collection of fields and subfields. You’ll see the ‘+’ signs on the left-hand side – if you expand one of these you’ll find information related to the particular element of the packet that it represents. In our case, the following elements are present:

    The packet’s ‘descriptive’ data, or ‘Meta’ Data

    [​IMG]

    This is data that describes the packet and includes Time/Data received, the Frame number, Frame length and a list of the protocols contained within the frame. In the case of this capture, we can see that the Frame Number is 17, that it was transmitted on August 11th at 21:47:26, it is 74 bytes and that the entire frame was captured (74 bytes on wire, 74 bytes captured). Note here that sometimes not all data in a packet is captured, for various reasons. Looking at the MetaData frame is a good way to ensure you have captured the entire packet.

    A brief note is necessary here on the layered methodology of network communications. You’ll recall from your basic networking training that network communication is a layered affair. Ethereal adopts a top-down approach to displaying the data at various layers of the OSI model – with the top entry in each packet captured being the lowest level of information (the DataLink layer), rising to the highest layer (the Application layer). Since the Packet MetaData is not part of the actual packet– it just describes it – this information should not be considered part of the packet capture itself

    The DataLink (Layer 2) information

    [​IMG]

    Underneath the MetaData information is the information pertaining to the DataLink layer which, as any student of the OSI model knows, is the layer representing physical assembly of packets on the wire. In our case, this is the Ethernet II standard – you may also see other types such as Token Ring & FDDI, but the vast majority of the time you will be capturing over Ethernet. As you can see, expanding this layer in our capture shows two more expandable entries – one designating the Destination address, the other showing the Source address. This is an excellent example of the hierarchical nature of Ethereal – to begin with, all you can see for each entry is the description of the interface and it’s MAC address, but if you expand the node you will see more information. In this case it isn’t that much more exciting – just letting you know that the frame is a Unicast frame as opposed to a Broadcast or Multicast. It does, however, serve to highlight that there can be information in a capture that isn’t immediately apparent. Always expand the ‘+’ signs!

    The Network Layer (Layer 3) information

    [​IMG]

    Now we start to see something a little more worthy of analysis. Since the Network layer protocol is much more interesting than the DataLink layer, there is much more information to be found here. For instance, we see that the Layer 3 protocol in use here is the Internet Protocol (IP). We can deduce from our capture that the two IP addresses assigned to the source & destination addresses are 192.168.1.154 and 192.168.1.10 respectively. We can also see that none of the various flags available in IP have been set, and that the TTL is set to 128. Finally, we note that the protocol that the IP encapsulates is, in this case, ICMP.

    As you can see, there is far more to see in this layer. The Network layer information is often extremely revealing and investigation of this particular area of a packet can often lead to diagnosing the cause of network errors and discovering & analysing unauthorised network access (e.g. from Trojans)

    Since ICMP is not actually a part of the Network Layer, but is a feature of the IP protocol, it is displayed below in a separate entry. You can see here the information relating to the ping probe itself – ever wanted to know what type a PING request was in ICMP? Now you know – type 8! You can also see here that the PING was assembled correctly, and view the Sequence Number – this could be very handy for seeing whether transmissions are being received out of order.

    Other Layers (Layer 4 and above)

    Since our capture here is just to illustrate the features of Ethereal and demonstrate how to use it, we haven’t got anything more exciting to look at. However, above Layer 3 sit the higher levels of the stack – Transport, Session, presentation and Application. In the final part of the tutorial, we’ll look at capturing an HTTP request, where data pertaining to more layers of the stack will be captured.

    For now though, this concludes the information to be found in the Protocol Tree Window. In the final part of this tutorial we’ll look at the raw data that makes up the packet itself.

    Raw Data

    [​IMG]

    As you know, computers deal in raw data. The Data Window allows you to take a peek at the actual raw data making up a packet. If you highlight any of the rows in the Protocol Tree Window, you will see, in the bottom pane of Ethereal’s interface, the raw data comprising that information. This will not often be easy to understand – to use a good example, let’s look at the actual raw data of the PING request. If you highlight the ‘Data’ field in the ICMP tree within the Protocol Tree Window, you will see the raw data pertaining to this data in the Data View Window. As you can see – a series of Hexadecimal numbers is highlighted. This is the actual data of the 32 byte data field within the ICMP PING request. If you look to the right, you will see the data (again highlighted for you) represented in ASCII format. Did you know that PING requests contained a series of 32 characters in ascending order? Now you do!

    That pretty much concludes the basic overview of capture analysis. If you want to, go ahead and have a look at the other packets ion the PING session, and play around with looking at other types of packets you may have captured.

    In the final tutorial we’ll look at a capture which is more useful practically than a simple PING probe.
     
    Certifications: A few
    WIP: None - f*** 'em
  2. Boycie
    Honorary Member

    Boycie Senior Beer Tester

    6,281
    85
    174
    :clap. Thanks again, looking forward to the final chapter.

    Si
     
    Certifications: MCSA 2003, MCDST, A+, N+, CTT+, MCT
  3. Bluerinse
    Honorary Member

    Bluerinse Exabyte Poster

    8,878
    181
    256
    This is really great stuff Zeb 8)
     
    Certifications: C&G Electronics - MCSA (W2K) MCSE (W2K)
  4. Rik

    Rik Nibble Poster

    79
    1
    14
    This is great stuff.

    Many many thanks.

    If anyone wants to delve into this more there is a Syngress Ethereal Packet Sniffing Ebook available.
     
  5. Mr.Cheeks

    Mr.Cheeks 1st ever Gold Member! Gold Member

    5,373
    89
    190
    sweet man! ...Does this mean you are officially our tutor in Network Security?
     
  6. zebulebu

    zebulebu Terabyte Poster

    3,748
    330
    187
    hahaha

    Not quite - but I can probably help out on a lot of security-related things - officially and 'un'officially :ninja

    :twisted:
     
    Certifications: A few
    WIP: None - f*** 'em
  7. Theprof

    Theprof Petabyte Poster

    4,607
    83
    211
    This is some interresting stuff Zeb, good job.
     
    Certifications: A+ | CCA | CCAA | Network+ | MCDST | MCSA | MCP (270, 271, 272, 290, 291) | MCTS (70-662, 70-663) | MCITP:EMA | VCA-DCV/Cloud/WM | VTSP | VCP5-DT | VCP5-DCV
    WIP: VCAP5-DCA/DCD | EMCCA

Share This Page

Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.