Wireshark Tutorial - part 4

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, this is it - the final part of a tutorial I have been promising for months. I've given classes to peeps at work on Ethereal a lot in the past six months or so and have finally started to knock together some notes to use in a formal presentation.

First up, I should probably start out by saying that Ethereal is (and has been for some time) now called Wireshark. Out of habit I STILL call it Ethereal from time to time - but as even I've got used to using the new name now I think the thread titles should be changed

Last time we looked at Wireshark we were concentrating on how it actually works - this time out we'll be looking at an example of a way you could put it to practical use 'on the job'.

As anyone who has ever worked in tech support will tell you, users are the bane of your life. The same maxim you would apply to small children and savage wild animals should be applicable to 'most users' and 'computers'. They should never be kept in the same room and, in a perfect world, would never come into contact with each other. Unfortunately, since your salary is usually dependent on cleaning up the mess these tards have made of your precious network - and management seem to think they are actually doing something useful with their PCs instead of playing games, sending colleagues who work twelve feet away stupid emails or looking for 'interesting' ways to breach your firewall and download malware, this is seldom an option in most workplaces.

Wireshark can truly be your friend when attempting to troubleshoot a potentially tricky network issue - it's ability to sneak a peek at the raw data travelling across your network can prove invaluable. it has, on many occasions, given me the answer to problems it might have taken me hours to diagnose in less than ten minutes.

Let's take a simple example. You have a user (let's call him 'Donut') on your network who regularly has to FTP to a machine elsewhere on your network to retrieve a file. The user is using a workstation with the IP address: 192.168.1.40, and the server is located at 192.168.1.151. This user is something of a luddite - he has been told how to logon and retrieve the file but nothing else about how FTP works. He also cannot interpret screen commands, read simple dialog boxes, copy down an error message reliably or keep windows displaying error codes open when requested to do so by first line support. Sound familiar?

This user complains that, 'every day' (lUser speak for 'about once a month') when he attempts to FTP to the address he has been given, he is unable to do so. He says that the connection 'just closes' and the command box 'just disappears'. Whilst you know that there must be a reason for this, and you could probably, (if you didn't end up smashing your head against your monitor in frustration first) tease the correct information necessary to allow you to make a diagnosis of the problem, you decide it will be:
a) more accurate
b) probably faster, and
c) definitely cooler
to fire up Wireshark and trace the connection in real time.

Being a good network admin, you've already got a box plugged into a span/mirror port on your switch that allows you to monitor all the traffic belting through that switch (you HAVE got a box like this, haven't you? so you fire up Wireshark and go through the capture process whilst the user is attempting his FTP connection. Just for good measure, you capture for five minutes before and after to see if there may be some symptoms of a problem with the FTP server knocking around.

I won't go through the tedious process of explaining how to use filters & stuff here - if you've got this far, you;re already familiar with filtering out extraneous information from capture files. Lets assume you have already filtered out all traffic that isn't related to FTP in your capture and have been left with something similar to the window below:



As you can see, this shows that, as well as the traffic associated with Donut's connection (from 192.168.1.40) there is a prior connection from another machine on the network (192.168.1.103).

As opening the FTP protocol traffic in the first frame (#32 in the capture) shows:



the FTP server was in a 'ready' state, awaiting connections when the earlier login was made. Packet 58 shows us that the user requested an anonymous logon:



and packet 59 shows that anonymous access is allowed to this server:



The previous user was requested to send their identity (suggested as an email address) for logging purposes, which the user subsequently did, in packet #70:



Finally, packet 71 shows that the user was successfully sent the FTP site banner that has been configured on the server:



(reps for anyone cool enough to know where that comes from!)

This proves that there is nothing fundamentally wrong with the FTP server that the user is attempting to connect to. However, the solitary packet associated with traffic from the user's IP address to the server concerned provides everything we need to know in one simple error code:



To be honest, we didn't need to go as far as opening the FTP traffic - we could have seen in the main Wireshark window that the error code was '421'. Armed with this information, plus the fact that an earlier user successfully logged into the server, we can deduce that it is likely the maximum number of sessions allowed on the FTP server has been reached.

This is an extremely simplistic view of what is possible with Wireshark. If you can think of any network-related problem that requires analysing, Wireshark can help. i have used it to sort out routing issues, incorrectly configured subnet masks, malware and worm activity analysis, messenger traffic logging, troubleshooting HTTPS problems, logging portscan activity and hundreds more useful things. It truly is the swiss army knife of any network admin, and learning it should be de rigeur for anyone who wants to further their career in the field.

 

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. Quality stuff as always.

 

An excellent diagnosis Doc Zeb!

So where do the the earlier 3 tutorials live?

 

They're in this forum under Ethereal tutorials. Ethereal became Wireshark some time ago, same program, different name, and it works better than Ethereal did (bugs fixed).

 

Brilliant tutorial Zeb, thanks.

 

Excellent!

 

Great tutorial - 'course, once I read it, I had to go and have a play.
Left it running for about 3 minutes....

Err, if you'll excuse me, I have to go now, and lie down in a dark room for a while...



My passwords.... it showed all my passwords.......

 

LOL - that's what WireShark or Snort newbies call a 'moment of clarity'. From now on, your life will never be the same...

 

Very good tutorial Zeb, much appreciated.

 

Yes this is great stuff and a real eye opener i am sure for many here including me

 

Great tutorial for newbies like me.

Thanks.. Looking fwd to more tut from you.

 

Hats off to you, great job, Zeb.



Is it possible for novices like me to download your sample capture



files illustrated in your tutorials?



Glenn