Well, here's the third part of the Ethereal Tutorial. I've decided to split the last bit up into two parts, as its a bit too much to take in all in one go! The final part (4) will follow later this week. Let me know if you have any questions or feedback! Zeb +++++++++++++++++++++++++++++++++++++++++++++++ In the first two parts of this brief tutorial, we looked at downloading and installing Ethereal, configuring your network interfaces, then made our first capture and performed some vary basic analysis of the traffic. This final two parts of the tutorial will show you how Ethereal can be useful for analysing something a bit more detailed than the basic PING session we examined in the previous lesson. It may be a little more difficult to follow along with this one, but even if you choose not to, this article should help show you how to put Ethereal to practical use. Ive chosen to show you an analysis of some web traffic specifically, opening your browser, running a search on Google than navigating to the site Googles search facility suggests best matches your search. Whilst not exactly mind-numbing in complexity, this analysis will give you a fair understanding of what it is Ethereal is capable of, and enable you to see how you might be able to put it to good use in other scenarios. First thing to do is to fire up Ethereal and start a live capture (refer to the earlier lessons for a refresher if you need it). Once Ethereal is running, open the browser of your choice and (if Google isnt already your start page) navigate to Google. Type in certforums.co.uk and hit return Google should throw up a single link click on this link to take you to the CertForums home page. Once youre there, you can stop Ethereal capturing live packets. Save the capture so that you can refer to it later if you want, then take a look at the capture in Ethereals main interface. As you can see from the screen capture above, there is a lot of information extraneous to what we are interested in. In order to eliminate this and make the capture easier to follow, I will implement a filter to show only the data we want to see. Filters are an invaluable weapon in Ethereals armoury enabling you to perform complex logical operations on an incredible range of traffic (over 42,000 separate protocols & protocol fields at the last count). Here, Ill implement a very simple one. Since Id like to see both how a website is requested and how that website is then displayed in my browser, Ill implement a filter to display only HTTP & DNS traffic. In order to do this in the filter dialog box (highlighted in red in the screencap below) I type in: http || dns. The two pipes are the logical representation of an or statement literally, this filter means show everything that is HTTP or DNS traffic. When I hit return, as you can see below, Ethereal now displays only the traffic I selected in my filter. Neat huh? One thing I should mention at this point the Time column in your capture will probably look different to mine. This is because, by default, Ethereal shows the time column as the amount of time that has elapsed since the first packet was captured. At the moment, how you display the time is purely a matter of preference. When Im looking at something as basic as this I prefer to see the time the capture was made, so I change this option in Ethereal. If you want to do the same, you can do this by going to View Time Display Format and selecting one of the options there. OK now that weve got the traffic that we wish to look at displayed correctly, lets take a look at it. From your basic networking knowledge you should know that, in order to display a website in a browser, you first need to find that website on the net. As you know, in order to do this, your browser makes a DNS request for the URL you specify. Here, Ive cheated a little bit. Since Google is set as my homepage, the DNS query is made as soon as I fire up my browser. As you can see from the first line in the capture, I made a standard query for the A record associated with the domain www.google.com. Drilling down into the protocol Tree window under IP you can see that the SOURCE of this request is the IP address 192.168.1.154 (my PC) and the DESTINATION is 192.168.1.102. Hands up anyone who knows what IP address my local DNS server is?  Underneath the IP tree you can see the UDP data associated with the packet. As you should know, DNS requests are made via UDP port 53. Here you can see that I have opened a local UDP port (1111 in this case) and made a connection to remote UDP port 53. Finally, lets open the DNS tree (remember that Ethereal displays packet data in order from lowest to highest as mapped to the OSI model therefore the DNS protocol, which operates at the Application layer, is at the bottom of the protocol tree window). Expanding the Flags and Queries branches, you can see the specific information related to DNS in the packet. Here, we see the ins and outs of the DNS query including the fact that the query is recursive, not truncated, and the query itself (the A record for the host www.google.com) You should already be able to see the benefits of running Ethereal in cases where DNS name resolution is problematic or intermittent examining the data from a capture filtered out to just DNS traffic would enable you to pinpoint where DNS was falling down. This could prove invaluable in troubleshooting DNS problems often a cause for consternation for many network admins! So there you go your first real world packet analysis. Now lets go a little bit further. Anybody know what the packet listed as 12 in my capture represents? I wont dissect that packet here Ill leave it as a bit of research for you. Suffice it to say that I find it an invaluable security tool for end users Ignoring packet 12 for now then, you can see the result of the DNS query in packets 13 & 15 - the IP address for the host www.google.com is 22.214.171.124 or is it? Well, actually, no this is still part of the homework relating to packet # 12 in fact, it might assist you if youre having trouble finding out what packet 12 represents! The real response to the DNS query comes in packet 15. As you can see, the DNS query returns a CNAME (Canonical Name) record for something called www.l.google.com, providing three separate IP addresses: 126.96.36.199, 188.8.131.52 and 184.108.40.206. Already we have discovered something interesting about Googles internal infrastructure. It seems that Googles nameservers are set to first return a CNAME in the form www.<letter>.google.com (where <letter> appears to be a different letter depending on where you are located or what time of day it is (try this yourself run two traces on a DNS lookup for Google a couple of hours apart youll see that the letter is probably different both times). It appears that a second query is then made, returning three different IP addresses associated with that CNAME. It doesnt take a genius to figure out that this is something to do with Googles fault-tolerance/load-balancing setup a massive organisation like Google synonymous with both all-pervasiveness and guaranteed uptime will obviously have data centres dotted all over the planet. What this DOES highlight, and very well, is that unless you were already well-versed in Googles internal structure, you probably already learned something new from using Ethereal and you havent even put the program to any practical use yet! In order to see the query responses in detail, expand the DNS branch in the protocol tree window and then expand all the entries under Answers youll see the CNAME first, followed by the three IP addresses associated with it On a more mundane level, you can see that the DNS query was returned via remote UDP port 53 to local UDP port 1111, from IP 192.168.1.102 to IP 192.168.1.154 indicating that the DNS query followed the same path as it did outbound, but in reverse. Of course, we cant see any other information relating to the DNS query in this capture since my DNS is configured to refer to a local DNS server which then does the upstream query for me. Your DNS queries may well be different you may see your ISPs DNS server if youre not sad enough to run your own local DNS like me! In the final part of the tutorial, Ill look at the HTTP traffic associated with browsing to a site, examine the DNS traffic again, and suggest ways you can experiment on your own to further your learning. Once again if you have any feedback, please let me know Im always glad to see it!