Wireshark - Ethereal Tutorial - Part 3

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

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.

I’ve chosen to show you an analysis of some web traffic – specifically, opening your browser, running a search on Google than navigating to the site Google’s 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 isn’t 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 you’re 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 Ethereal’s 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 Ethereal’s 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, I’ll implement a very simple one. Since I’d like to see both how a website is requested and how that website is then displayed in my browser, I’ll 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 I’m 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 we’ve 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, I’ve 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 won’t dissect that packet here – I’ll 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 ‘216.143.70.105’ – or is it? Well, actually, no – this is still part of the ‘homework’ relating to packet # 12 – in fact, it might assist you if you’re 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: ’66.249.93.99’, ’66.249.93.104’ and ’66.249.93.147’. Already we have discovered something interesting about Google’s internal infrastructure. It seems that Google’s 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 – you’ll 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 doesn’t take a genius to figure out that this is something to do with Google’s 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 Google’s internal structure, you probably already learned something new from using Ethereal – and you haven’t 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’ – you’ll 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 can’t 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 ISP’s DNS server – if you’re not sad enough to run your own local DNS like me!

In the final part of the tutorial, I’ll 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 – I’m always glad to see it!

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Thanks Zeb. This comes in handy at the right time. Quality stuff too.

 

That's brilliant, nice work Zeb. I trust that the guys at work are enjoying your tutorial as much as we are



What's next on the agenda, NSlookup

 

Haha - Well - the first little session went over OK, but - how can I put this mildly - there is a 'difference of experience' between the people I'm teaching - some of them are barely able to create a network share!

 

So the next lesson topic will be - how to create a network share without necessitating a complete server re-build

 

I'd be happy enough with 'how to create a network share without necessitating a call to my mobile on my day off..."

 

You mean that this is possible?? Since when? Why didn't anyone tell me.

 

Hello, Im wondering if someone can tell me how to filter just the traffic coming from those images in the webpages. Since I can filter the http traffic, I would like to get only the part coming from the img's

Thanks