Atutorial For Sniffers For Windows

A Tutorial on Sniffer for Windows By Bit_Logic [email protected] “To those who dare to learn.”

Disclaimer Consider this electronic book (eBook) literary freeware. It may be transferred, reproduced, and viewed with no limitations so long as the following two conditions are maintained without exception: 1. This document may not be modified in any way, in part or in whole. 2. Under no circumstances may you accept payment for redistribution of this eBook, either electronically or in print. And of course, the author cannot be held responsible for anything foolish you decided to do. This document is provided solely for educational purposes.

“Information wants to be free.” - Bruce Sterling

SYN I get a lot of requests from people to teach them how to use Sniffer. Sniffer, as you probably know since you’re reading this tutorial, is a Windows-based GUI network packet sniffing application. Essentially, it captures all data frames and/or packets [Note 1] going in and out of your network card. Why would anyone care to view these packets? There are actually a lot of reasons. Sniffing is used primarily to monitor network performance, but of course much more devious uses can be applied to it. For example, if you configured a switch to send all network traffic through your computer by means of SPANing (Switched Port ANalysis) a certain switch, you could monitor every bit of data sent and received by everyone on your LAN. The main goal of this tutorial is not to teach you to spy on your coworkers (well, maybe a little), but to teach you how to capture and view packets using Sniffer, so that you can in turn learn more about networking in general. As Sniffer is Windowsbased, we’ll be dealing almost exclusively with TCP/IP Ethernet traffic. If you haven’t installed Sniffer yet, now is a good time to do so. The installation process is relatively straightforward, and shouldn’t take more than a few minutes, plus a reboot. If you have any problems getting it to run, consult the Sniffer readme file. Once you have it working, it’s time to capture our first frames!

Getting Started When you run Sniffer for the first time, you’ll notice a main window with a button toolbar at the top, and a child window titled “Dashboard”. Close the dashboard for

now, and let’s focus on the main toolbar for a moment. Here’s a rough list of each function available in the toolbar: Capture Controls – These first few buttons allow you to start, pause, stop, and view captures. Filters – You can define and apply packet filters with the “Define Filter” button and drop-down list. Open/Save – You can save captured packet lists and open them to view later. Print – Take wild guess. Dashboard – The dashboard displays real-time traffic going in and out of your network card. Host Table – The host table lists all recorded hosts on your LAN that have sent/received data to/from your computer. Matrix – That’s right, it’s not just a movie. The matrix has a whole bunch of traffic summarization tools. You can choose to view traffic in a list or graphical format. These are neat when you have at least a couple dozen computers on your LAN. Application Response Time – You can see exactly – and I mean exactly - how long it takes for a certain webpage to load, or how high the delay on your domain controller is, for example. History – Here you can find a summary of just about any packet category, represented in just about any graphical format. Protocol Distribution – See how different protocols stack up to each other in use on your network. Global Statistics – Displays the rarity of different frame sizes. Alarm Log – Problematic frame transmissions (collisions, fragments, etc.) should show up here. Capture Panel – Displays real-time capture statistics. The detail tab provides a nice clean overview of the entire process. Address Book – Sniffer will usually auto-detect hostnames and other identities, but you can manually add specific addresses to the address book. Sound like a lot of features? You haven’t seen half of them yet. Now, the moment you’ve been waiting for; we’re going to capture a minute or so of typical network traffic. Back at the far left of the toolbar, click the “Start” button. You should see the “Expert” window pop up. This window provides a real-time summary and diagnostic of network traffic. There are three gray buttons at the bottom of the left column. “Diagnoses” and “Symptoms” list packet errors or other indications of poor network performance. “Objects” offers a more interesting survey of all known devices, protocols, connections and more.

We’ll discuss the Expert window more in-depth (probably a lot more in-depth than you ever wanted to go) later. For now, open up your web browser and go to a web site. Any web site, it doesn’t matter; our goal here is to generate some traffic for us to sniff. A single hit to cnn.com should give you a healthy few hundred frames. When the page has finished loading, go back into Sniffer. You can view the number of captured frames in Sniffer’s status bar at the bottom of the screen. There are two ways to stop sniffing. The “Stop” button will simply abort the capture. This means you will not be able to save anything. The “Stop and Display” button, however, will allow you to save your capture, and view saved statistical information too. It also opens up the ability to view and edit raw data frames. Click “Stop and Display”. I know at first it doesn’t look like much, but you have actually captured a great amount of data. In the top window bar, go to File > Save As… Rename the file to MyFirstSniff.cap and save it to a directory of your choice. Congratulations! You have just captured and saved real live network traffic.

Viewing Raw Frames If you don’t understand exactly what Sniffer is doing yet, that’s okay. This next section should provide a good insight to the actual process of frame capturing. First, you need a stopped frame capture open. You can create a new capture or open an existing one, just make sure you have a stopped capture, as you can’t view raw frames in real-time. In your completed capture window, you should see a row of tabs along the bottom of the window (Expert, Decode, Matrix…). Click on the “Decode” tab to switch to the raw frame view. At this point, you will be presented with an enormous amount of information; try not to explode. (Note: You may find it easier to maximize the Sniffer and Decode windows to take up the entire screen.) The decode view is divided into three horizontal panes, each taking up a rough third of the screen. Each pane has a separate degree of detail: Summary Pane This top window lists every captured frame in chronological order. columns that you can resize, move, or hide as you see fit:

It has several

Selection – The leftmost column contains a checkbox for selecting individual frames. More on this later. Number – The frame’s chronological ranking (No. 1 is the first frame captured). Status – Any special status of the frame, usually none. You’ll notice the first frame is marked with “M”. Source Address – The protocol address or hostname of the transmitting station. Destination Address - The protocol address or hostname of the receiving station.

Summary – Shows the identified protocol, and any available specifications unique to that protocol (such as the destination and source ports for TCP). Don’t worry if you don’t understand any of it. Length – Frame length measured in bytes. Relative Time – Time since the capture started, presented in the format Hours:Minutes:Seconds.Milliseconds. Delta Time – Time since the last frame was captured, presented in the format Seconds:Milliseconds:Nanoseconds. Absolute Time – Time of capture as indicated by the system clock, presented in the format Month/Day/Year, Hour:Minute:Second, AM or PM. Most of these are self explanatory, with the possible exception of the summary column. First, the text in this column will be colored according to what protocol the frame is. For example, generic TCP is pale green, DNS is brown, HTTP is pink, etc. The first item listed in the summary field is the detected protocol. Then, it will display certain key values corresponding to that protocol. For example, TCP will show the source and destination ports, SYN/ACK/FINs, a sequence number, and so on, whereas HTTP will instead show the source port and HTTP request. Individual frames can be selected or deselected by checking or unchecking the box in the leftmost column. You can also right-click anywhere in the summary pane and click “Select Range…” to specify a range of frames to be selected or deselected. Also found in the right-click context menu is the “Save Selected…” option. This will copy all selected (checked) frames to a completely new capture window. (Note: This will not affect your current capture in any way; it simply opens an additional window.) If you switch to “Decode” view in this new window, you’ll see that only the selected frames have been copied into the new capture. Try it out to get the hang of it, then return to your original capture. Detail Pane The detail pane provides a very convenient frame overview, broken into a hierarchy of information corresponding to the OSI Model [Note 2] layers. An example HTTP packet contains four such levels: DLC, IP, TCP, HTTP. All Ethernet frames will have a DLC (Dynamic Link Control) layer, followed by the network/transport layer protocol(s) and finally the application protocol(s). The DLC header is short and sweet, with only three fields. (Note: The first line (“Frame XXX arrived at…”) is only a summary of the frame added by Sniffer – it is NOT data contained within the frame itself.) The source and destination MAC (Media Access Control) addresses are displayed here with one notable difference: the first three bytes of the address may have been changed to read as the card manufacturer’s name. For example, instead of “00B0D0”, it would say “Dell”. For more information on MAC addressing, see [Note 3]. Last is the Ethertype, usually IP or IPX. The next protocol will vary depending upon what type of network you are on. The majority of Windows/*nix LANs run TCP/IP Ethernet. At the time of this writing, Sniffer is only available on Windows platforms, so the next few examples will assume

you’re capturing on a TCP/IP stack. For more information about TCP/IP, see [Note 4]. Next comes the IP header (remember, this is assuming you’re running TCP/IP). The IP header contains a good deal of information about the packet, but most of it is outside the scope of this tutorial. For now, all you might need to be concerned with are the source and destination addresses. After IP, you’ll usually see TCP. (Yes, there are other IP based protocols (like UDP and ICMP), but this is a Sniffer tutorial, not an RFC. Give me a break.) Again, this header contains a whole lot of information, but we usually just don’t care about it. The most useful fields are the source and destination port numbers, which can often help you identify a protocol if Sniffer cannot detect it automatically. After this, you’ll see any number of higher protocols. The most common are detected automatically by Sniffer, but there are thousands of them. [Note 5] lists all officially mapped protocols and their ports. Hex Pane This last pane is the real down-and-dirty, byte-for-byte view of a frame. You can’t get anymore close up and personal than actual hex (except maybe flat out binary, but that would drive you to insanity). To learn more about hex, see [Note 6]. You’ll notice every hex byte is color-coded to match its corresponding data layer. A series of black zeroes at the end of a very short frame, called padding bytes, are used to enlarge a frame to its minimum length. Every row of bytes begins with its row number, also represented in hex. There are sixteen bytes per row, along with each byte’s ASCII representation at the right (invalid ASCII values are indicated by a dot – not to be confused with the actual ASCII value for a period, “2E”). Clicking on individual bytes will highlight the series of bytes it belongs to in both the summary and hex panes.

Transmitting Frames Sniffer isn’t only limited to sniffing, believe it or not. It also has the ability to send raw data frames onto the network. This is an invaluable tool, as you can easily retransmit a frame or list (known as a buffer) of frames to sort of recreate network traffic. To send a single frame, right-click it in the summary pane, and select “Send Current Frame…”. Here you can specify the number of times to transmit the frame, as well as the delay between transmissions. You can also edit the raw hex values in the frame; more on that later. You can view the current count of transmitted frames in Sniffer’s status bar at the bottom of the screen. One important note about firewalls: Certain firewalls interfere with the transmission of raw frames, whether Sniffer is allowed to access the network or not. This results in one of those lovely blue screens and a full system reboot. My advice is to temporarily disable your firewall before you attempt to transmit a raw frame. You can also retransmit an entire capture. Remember how to select frames in the summary window? Select the frames you want to send, and save them to a new capture. In this new capture, right-click anywhere in the summary window and click

“Send Current Buffer”. Here you can only adjust the number of transmissions; the delay is specified by the individual frames’ delta times.

Editing Frames You can also edit raw frames to save or retransmit. Unfortunately, editing some frames correctly, like TCP packets, is close to impossible because of the checksum and length limitations. Editing is possible, though. To edit a frame, right-click anywhere in the hex window, and select “Edit…”. The “Hex Edit” window will pop up, and you can alter raw hex value, four bits (half a byte) at a time. As you edit the hex, the ASCII representation to the right will change to match the new values. When you’ve finished editing, click “Re-interpret” to save the modified frame back into the capture buffer.

Capture Filters Sniffer is installed with the “Default” capture filter, which is set to capture all frames. On a normal LAN, this means quite a bit of traffic. If you’re only looking to monitor a certain type of packet (for example, HTTP requests), you can define and apply a filter to do so. Start by clicking the “Define Filter” button at the top toolbar. Here you will see a window with several tabs. This is the default filter definition. Let’s say you suspect that a rogue user has been pinging down one of your servers at random times. Being the savvy network administrator you are, you decide to run Sniffer to get some hard evidence (I know this example sucks, but bear with me). But wait, we don’t want to monitor the traffic of the entire LAN; that would result in thousands of frames after just a few minutes. Instead, we want to define a filter to capture only ICMP packets from a certain workstation. In the “Define Filter – Capture” window, click the “Profiles…” button at the bottom right. This will allow you to create new filters. Click “New…” and type in the name “Pings Only”. Leave the other options as they are – this will copy the default filter. Hit “OK”, and then “Done”. Now you should see the highlighted “Pings Only” filter listed beneath “Default” on the right. Next, we need to define the filter. There are five tabs along the top of the window: Summary – This window provides a brief overview of the current filter. Address – You can opt to only include or exclude certain MAC, IP, or IPX addresses. Data Pattern – Allows you to match frames by a certain data string. Advanced – Include only certain protocols, sizes, and types. Buffer – You can set the capture’s buffer size. This the amount of data held in memory during a capture. When the buffer is full, it can be set to dump or save to a file.

Returning to our example, assume we only want to capture ICMP packets from the workstation 192.168.14.183. Under the address tab, specify “IP” as the address type, leave the mode as “Include”, and type “192.168.14.183” in the first box under “Station 1”. (Note: By including only certain workstations, all others are excluded.) Next, click on the “Advanced” tab. Scroll down the list until you find “IP”. Click the plus sign next to “IP” to expand the list. Find “ICMP”, and check it. You can now hit “OK” and start capturing. When you stop and view your capture later, you’ll notice only ICMP traffic (if any) was captured. (Note: Make sure the “Pings Only” capture is selected in the toolbar at the top, not “Default”.)

Triggers Sniffer has the ability to automatically start and stop capturing frames based on user-defined conditions called triggers. Select “Capture” from Sniffer’s top window menu (not the buttons), and click “Trigger Setup…”. You can define separate start and stop triggers, as well as enable/disable “Repeat Mode”. Both triggers need a trigger and capture filter, but the stop trigger also has the option to set a delay of X number of packets. To define a start trigger, first enable it. We’ll leave the capture filter to default (all frames). Click “Define…” to set the trigger. We’ll create a new trigger called “Work Days”, so click “New…”, enter “Work Days” in the prompt, and click “OK”. Check the “Date/Time” filter and set it to 7:00 AM, and unselect (click) the Saturday and Sunday buttons. You can also set predefined alarms and make your own trigger filters (which are made the same way as capture filters) if you need to. Click “OK” to return to the trigger setup window. You could also set a stop trigger the same way you just set a start trigger, but we’ll leave it disabled for now. This means it will keep capturing until a human user stops it (or the capture filter tells it to stop when the buffer is full). (Note: Once you’ve become familiar with triggers, make sure you disable all triggers until you want to use them.)

FIN You may still be far from becoming a sniffing pro, but you should have the basics of Sniffer down. There are a few trivial areas I didn’t go into detail on, but you should be able to find them should you come to need them. I hope this tutorial has helped you understand the raw data transfer behind computer networking, and that you continue to study the field. There’s no better way to understand the TCP/IP threeway initial handshake then by actually viewing those three packets byte for byte in plain text on the screen in front of you. You may also want to experiment with sniffing on different platforms and networks. There are sniffing utilities for just about every OS out there. Remember, no matter how much you know, there’s always more to learn. - Bit_Logic

[Note 1] Frames are the datagram unit for the OSI Media Access Control layer (layer 2), whereas packets apply to the Network layer (layer 3). See [Note 2] for more information. [Note 2] The OSI (Open System Interconnect) model is a seven-layer network specification detailing what operations take place at what “layer” of a network. Further information can be found at: • http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm • http://www.thelinuxreview.com/howto/intro_to_networking/c4412.htm • http://www.learntcpip.com/OSIModel/default.htm (With video for the excessively lazy) [Note 3] MAC (Media Access Control) addresses are unique burnt-in hardware addresses found on every network card. For more information, see: • http://compnetworking.about.com/library/weekly/aa062202a.htm • http://howto.lycos.com/lycos/step/1,,26166+25845+18045,00.html [Note 4] The TCP/IP protocol stack is the most commonly used system for network communication in use on LANs (Local Area Networks) and the Internet today. For more information, see: • http://www.ipprimer.com • http://www.cisco.com/warp/public/535/4.html • http://www.protocols.com/pbook/tcpip.htm [Note 5] Most common protocols, such as DNS, HTTP, and SMTP, have well-known port numbers. For a complete list, see • http://www.iana.org/assignments/port-numbers. [Note 6] Hexadecimal math is used as a sort of shorthand method for representing binary value (from 0 to 255). For more information, see: • http://www.southwest.com.au/~jfuller/binary/binary7.htm.