Wireshark 101 – Sending And Analyzing An ICMP Ping, Part 1

/in /by

Welcome, readers! In the last Wireshark 101 article, we installed Wireshark and got introduced to the interface. This time we are diving in and analyzing our first packets! I’m using Windows 7 in this tutorial, so following along will be easiest if you are using Windows yourself. Also noteworthy is the fact that I’m using a computer plugged into an Ethernet II network. If you are using wireless or a different layer 2 wired technology other than Ethernet II (unlikely, but possible), you’ll have a different experience than what is depicted, but feel free to follow along anyway! Go ahead and fire up Wireshark and start a new live capture by choosing your capture interface and clicking the green shark icon. Once the capture’s going, open up cmd.exe by pressing Windows Key+R, typing “cmd.exe” without the quotes, and pressing enter. Now type the following command to send 4 ICMP (Internet Control Message Protocol) packets to 8.8.8.8, Google’s public DNS server:

ping 8.8.8.8

This command will send 4 ICMP Echo Request (“ping”) packets to the IP address 8.8.8.8. Your screen should look pretty much like the window below.

pinggoogle

After the pings have been sent, minimize cmd.exe, pull Wireshark back up and stop the capture by pressing the red stop button just beside the green shark fin. Now let’s go back to the cmd.exe window so we can discuss our results. A ping is a low level network packet that, among other things, is often used to test basic connectivity to a network device. Each echo request ping packet is a humble request that the receiving device respond back. The fact that you received a response to your pings is a confirmation that we have a path from your computer to 8.8.8.8, a path from 8.8.8.8 back to your computer, and that the device that responded is being nice and not ignoring or blocking our pings. The ping does not tell us who 8.8.8.8 is or where it is located or what services it offers. We just happen to know in advance that this is Google’s Public DNS server (with that in mind, please don’t spam the server by sending more pings than are necessary for the purposes of this tutorial).

In the cmd.exe window, we are given some information about the response back from our pings. The first line after our command tells us which IP address we are pinging and how many “bytes of data” are being sent in each packet. The next four lines detail the responses we received from each ping packet. The address where the reply originated, the amount of data bytes that were received, the amount of time it took for the response to return in milliseconds, and the TTL (Time to Live) value for each packet are seen in each line, from left to right. At the bottom of our window, we see some summary statistics.

Let’s switch back over to the Wireshark window. If any applications on your computer were sending network traffic while you performed your packet capture, or if there were noisy broadcasting devices on your network, you’ve likely got extra packets besides the 8 we are looking for in your trace file. The filter field is going to help us solve this “needle in the haystack” issue. Simply type “icmp” without quotes into the filter field and press enter. As long as there were no other ICMP packets sent during your capture, you should now have a window very similar to this:

4pings

Wow, this is much easier to deal with! Notice that the filter field turns green since we have typed an appropriate display filter pattern. Alright, so what are we looking at here? Each row in the packet list pane corresponds to a single packet. Currently, and for reasons we’ll explore later on, each packet is colored pink (the top packet is blue since it is selected). Follow along by referencing the first packet in the list (No. 583, the blue one). The columns in the packet list pane denote the following pieces of information:

No.: The number of the packet within the capture file. Wireshark counts packets in the order that they were received, starting with number 1. Packet 583 would be the 583rd packet that Wireshark saw since beginning its capture. The packet numbers in this picture aren’t sequential because we have applied a display filter to only show ICMP traffic. It just so happens that other packets were received between the pings, and the pings began after 582 packets were already captured.
Time: The time that the packet was received in seconds after the capture was started. A time value of 8.246 indicates that Wireshark received this packet 8.246 seconds after the capture began.
Source: The source IP address of the packet. This first packet originated from 192.168.1.100, which happens to be the internal IP address of my home computer. Wireshark captured this packet as it left the computer.
Destination: The destination IP address of the packet. This first packet was addressed to be delivered to 8.8.8.8.
Length: The length of the packet in bytes. Each of these packets is 74 bytes in length.
Info: Some relevant information about the packet depending on what protocol is being used. In this instance, Wireshark has determined that these are ICMP ping packets, and has displayed whether each packet is an ICMP echo request or reply, the id and sequence values of each packet, the TTL value for each packet, and the packet number of the accompanying reply (if it’s a request) or the packet number of the accompanying response is (if it’s a reply).

ethernetframe

Let’s dive further into this first packet. With the first packet highlighted in the packet list pane, we’ll move our attention to the packet details pane in the middle of the screen. Each row corresponds to a layer of the packet and essentially, a particular protocol. The first layer (Frame xxx…) corresponds to the physical layer of the OSI model. The only important thing we need to know about the layer 1 information is that Wireshark received a string of bytes called a preamble indicating that an Ethernet II frame header was coming up. Feel free to investigate this layer, but we won’t be discussing it–we’re going straight to layer 2! Click on the the little plus sign to the left of “Ethernet II…” to expand the Ethernet II header. What we see is a destination and source address, and a “Type” field. These destination and source addresses are known as Media Access Control (MAC) addresses, and they are used to identify devices at layer 2 of the OSI model. Each MAC address is 6 bytes or 48 bits in length and corresponds to a particular hardware interface. The first 3 bytes (the first half) of the MAC address is known as the Organizational Unique Identifier (OUI) and identifies the name of the organization which manufactured the network interface card (NIC). There’s an option in Wireshark to check OUI’s against a database and display the name of the company that manufactured the NIC–that’s why in my capture file we can see “Asiarock” and “Cisco-Li” (Cisco-Linksys). The non-interpreted MAC address is shown in full in parenthesis to the right of the interpreted addresses. The Type field designates what type of protocol will be coming up after the Ethernet II header. In my case, it is IP (Internet Protocol version 4), which you can confirm by looking at the layer directly beneath the Ethernet II header.

If you select a line from the packet details pane, the corresponding bytes will also be highlighted in the the packet bytes pane. I’ve just realized that the default setting for the packet bytes pane is to display the bytes in hexadecimal, and I’m viewing mine in binary. To switch between the two views, right click anywhere in the packet bytes pane and choose “Bits View”. In the picture above, I have selected the entire Ethernet II header by clicking the text on the line rather than the plus symbol (see the blue line in the packet details pane in the picture above). By doing this, we can see every byte and bit that comprises the Ethernet II header and it’s ASCII interpretation (which isn’t that interesting for this part) in the packet bytes pane highlighted in blue. As expected, the Ethernet II header is 14 bytes in length (14 sets of 8 bits, or one hundred and twelve 1’s and 0’s–go ahead, count them yourself!). It all adds up considering we know that there is a destination MAC address (6 bytes), a source MAC address (6 bytes) and a Type field (2 bytes). You could also select any of these fields to see their corresponding bytes in the packet bytes pane. In the picture below, I’ve selected the Destination MAC address and the corresponding 6 bytes are highlighted:

destinationmacbytes

If you understand how to convert binary to hexadecimal, you’ll see that the binary and hexadecimal do indeed match up. And even if you don’t know how to convert binary to hexadecimal, you can switch to hexadecimal view in the packet bytes pane. Keep in mind that the bits we see in the packet bytes pane are the result of the actual electrical signals sent across the wire which correspond to 1’s and 0’s. Wireshark applies dissectors to these bit streams in order to know which bits and bytes correspond to particular pieces of information. For instance, when we evaluate the first six bytes of the Ethernet II header, we see that we can convert it to hexadecimal as 00:22:6b:80:56:0d. There is nothing in these bytes that translates into the text “Destination” or “Cisco-Li_”. Wireshark knows that this is a destination MAC address because it has applied a dissector which specifies that the first 6 bytes of the Ethernet II header are to be interpreted as a destination MAC address. This same group of bytes would be interpreted differently if it were located in a different place in the packet. Likewise, “Cisco-Li_” is the OUI which is supplied by Wireshark after checking an OUI dictionary. There is no information located within the bytes themselves that would provide this knowledge. Additionally, Wireshark knew to apply it’s Ethernet II dissector to this section of the packet due to the preamble it received indicating that an Ethernet II header was coming up. This is one of the beautiful things about Wireshark. You are able to quickly access a ton of information without having to know the protocols inside and out and without having to manually compute what each bit and byte means.

Whew! This is shaping up to be a two-parter. Go ahead and save your Wireshark capture by choosing File > Save As… and choosing a place to save the file. Next week we’ll use this same file to examine the rest of the packet. Thanks for reading!

How To Get DNS When Internal DNS Servers Are Down

/in /by

A few months ago, a coworker and I had to come in on a Saturday and replace a line card in our core Cisco switch. Of course the card that went down was the one connecting our VM infrastructure, so all of our core services went down with it (maybe there shouldn’t be a single point of failure for this…food for thought?). We were able to quickly restore connectivity up to the Internet, but our DNS servers were all VMs which had been knocked offline, and DNS is very handy to have when you’re interested in using Google services, Cisco articles and blogs to research information you need to get the network back online. My solution was to use Google’s public DNS server, which is located at the conveniently memorable IP address 8.8.8.8 (there’s a backup at the slightly less memorable 8.8.4.4). If your DHCP server is still running (ours wasn’t), you can just change the DNS servers on the clients without disturbing the IP address lease like in the screenshot below.

googlednssettings

Notice that I haven’t disturbed the radio button for “Obtain IP address automatically” but that I’ve set static DNS server entries with the “Use the following DNS server addresses:” radio button. Hopefully you won’t have to do this for everyone in the office, but those critical staff members who need to browse immediately (you know…the person paying you) can be set up this way temporarily. Another option you have if DHCP is still running is to change the DNS servers option in your DHCP scope so that 8.8.8.8 and 8.8.4.4 are being offered first, then force a DHCP Request from the clients. The command to do this from the client side is:

ipconfig /renew

So you could run that via whatever client management software you’re using, or have your intern type it in manually on all the workstations if you don’t have that capability. If you lack an intern and have users who aren’t tech savvy enough to confront the terrifying gray and black text window, you could just tell them to restart their computer and that should force a DHCP Request as well. If your DHCP server isn’t running, you’ll need to set a static IP address for computers that haven’t held onto a lease in addition to setting the DNS servers client-side. Hopefully one of these band-aid fixes will at least be enough to make someone happy or make your life easier while you’re working on bringing the internal DNS server back up. Best of luck!

Wireshark 101 – The Interface

/in /by

Welcome back to Wireshark 101! Last week I wrote an article that hopefully got you interested in Wireshark, and this week I’ll walk you through installing it and getting some exposure to the interface. Recall my caveat about not using Wireshark at work, school or any other place where you aren’t explicitly permitted to do so. With that in mind, let’s install Wireshark and take a short tour.

The latest version of Wireshark can always be downloaded from www.wireshark.org. We’ll be using Wireshark 1.12 which was released on July 31, 2014. The download link should be at the bottom left of the page. Just grab the version that’s appropriate for you–I’m using the 64-bit version of the Windows installer for this article. If you’re running Mac OS X, your interface will look a little different but for the most part it’s pretty similar. Upon running the installer, you’ll be faced with some check boxes on the “Choose Components” window. I’m leaving everything checked except “Wireshark 2 Preview”. On the following windows, “Select Additional Tasks” and “Choose Install Location”, we can use the default settings. Leave “Install WinPcap 4.1.3” checked on the “Install WinPcap?” window and then choose “Install”. Another installation process will be launched for WinPcap and “Automatically start the WinPcap driver at boot time” can be left checked. After that WinPcap is done, Wireshark will finish up installing and you’ll have the option to go ahead and run it!

wiresharkinitial

You’ll be greeted with a screen that looks pretty much like the screenshot above. The section titles speak for themselves here. We have a capture section, a capture help section, a files section and an online help section. You won’t normally spend much time on this window, so let’s continue on and get to the real interface that you’ll come to know as home! Under “Capture”, choose the “Local Area Connection” interface and then click the green shark fin just above it. Note: if you’re on a laptop, you’ll need to select a wireless interface. I am not sure how they are differentiated. If all went as planned, you’ll be taken to a new interface similar to the one below.

capturewindowcolors

Oh no, information overload! Depending on how noisy your computer or network is, you should start seeing a list of rows with different numbers and colored backgrounds fly by pretty soon. If your window doesn’t look something like mine after about 30 seconds, you might have chosen the wrong capture interface or maybe you just aren’t generating any network traffic. My suggestion is to try minimizing Wireshark and browsing to a webpage, something like www.google.com. When you come back, you should have some packets. If you don’t, you need to select a different capture interface by clicking the “List the available capture interfaces…” icon which is two icons to the left of the green shark fin at the top of the window. Check the box for a different interface than the one that’s selected and click “Start” and “Continue without saving”.

Once you’ve got a few packets captured, press the red stop button to the right of the green shark fin icon near the top. Now we can take a look at each part of the user interface at our leisure. The top section with the columns such as “No.”, “Time”, “Source” and “Destination”, as well as the rows for each packet, is known as the packet list pane. As you might guess, it lists the captured packets along with some specified details of each packet in the columns. The middle section is known as the packet details pane. This is where you can get an in-depth examination of one particular packet once it’s selected in the packet list pane. The pane at the bottom with all the 1’s and 0’s is the packet bytes pane, and it shows you the actual binary data as well as an ASCII interpretation of the bytes for the currently selected packet. That means if we were looking at raw HTML from a webpage, for example, we could see that in the packet bytes pane in the ASCII column. With no particular reasoning behind the choice of colors, I’ve outlined the packet list pane in blue, the packet details pane in red, and the packet bytes pane in green in the image above. These panes can be resized if you’d like to adjust the layout–just hover your mouse cursor between two panes until your cursor icon changes, then click and drag to the desired size.

Congrulations! You’ve completed your first packet capture! You can save it if you like by choosing File > Save and choosing a destination, but we won’t be using it anymore. That’s all we are doing for this article! To exit, just click the red “X” at the top right of the window. I know it looks like a lot to take in right now, but we will take it nice and slow while building up our Wireshark skills. In the next article we’ll send some ICMP ping packets, examine one of them from beginning to end and get a handle on how all this information is organized and how we can organize it further.

How To Lock Your Screen On Mac OS X Mavericks

/in /by

You really should lock your workstation when you’re away, regardless of your position or how much access you have to internal network resources. Windows makes this pretty simple by giving you access to the Windows Key + L shortcut which you can throw at any time to put your computer into password protected mode. With OS X 10.9 / Mavericks, it’s slightly more of an annoyance, but still possible.

Mac OS X Security & Privacy

First we’ll choose Apple > System Preferences > Security & Privacy. Then you’ll want to make sure the box beside “Require password [immediately] after sleep or screen saver begins” is checked. At this point there’s a keyboard shortcut you can use to put your display to sleep immediately, and that is Control+Shift+[Power or Eject Button]. Because we set the option to require a password immediately after sleep begins, this doubles as a lock screen.

Mac OS X Hot Corners

Another option you have if you want something even faster and easier is using something called a “Hot Corner”. If you choose Apple > System Preferences > Desktop & Screen Saver > Screen Saver tab > “Hot Corners…”, you’ll have the option to choose a corner of your screen and a corresponding action for OS X to perform. The option we want is “Start Screen Saver”. I have a hot corner set at the bottom right of my screen to start the screen saver, so when I move my cursor to that position the screen saver starts automatically and my screen is locked with a password because of the option we set previously. All things considered, I think this is my preferred method of locking my computer, even though I do it accidentally on occasion.

Wireshark 101 – Introduction

/in /by

Wireshark is my favorite networking tool and I have used it pretty much on a weekly basis over the past couple of years. Not only has it saved me multiple times at work as I investigate various issues, it’s also allowed me to expand and solidify my knowledge of networking. It’s a wonderful troubleshooting tool and an invaluable learning resource. That’s why I think you should use it whether you’re already working in the networking field or learning the basics as a student.

So, what is Wireshark? Wireshark is a network packet analysis tool. That means we need to define what packets are before we can understand why analyzing them with Wireshark is helpful. Allow me to launch into a long-winded explanation. It turns out that everything your computer sends or receives across a network or the Internet is actually a stream of 1’s and 0’s. That means every picture, every streamed song, every video, and every bit of data that goes into making online computer games work are all comprised of just 1’s and 0’s and nothing more. It might seem a little implausible if you haven’t been exposed to this concept before, but it’s true. The trick is that we use a lot of 1’s and 0’s. For instance, a picture I have saved on my computer that was taken by my cellphone is made up of 2,838,456 1’s and 0’s. Programs that have the capability to render pictures on your computer are able to process that stream of nearly 3 million digits and turn it into something that’s appealing to the eyes.

Now, let’s expand our terminology a little. From now on, we’ll refer to a single 1 or a single 0 as a ‘bit’, and we’ll call any combination of 8 bits a ‘byte’. A byte is a sort of special length of bits that you will see over and over again. A byte can be any combination of bits. Each of these numbers separated by commas are examples of a byte: 00000000, 11111111, 11001100, 11110000, 10101010, 10011010, 01101010. Each of these strings of bits is a byte simply because the definition of a byte is that it is 8 bits in length. There’s also a designation for the length of 4 bits, and it is somewhat humorously referred to as a nibble (it’s half of a byte…get it?).

Groups of bytes that are sent across a computer network are referred to as packets–we finally made it to the definition of a packet, whew! Inside a packet, there may be different sections of bytes for different purposes. For instance, when downloading a picture from a website, the bytes that ultimately make up the picture itself are of course present in the packets. But there are other bytes in the packets as well, for example bytes that are used to make sure that the packet arrives at the correct location (like your computer), and bytes that are used to make sure the packets are reordered correctly once they are received (so your picture isn’t a jumbled mess of pixels). In other words, there are different layers to each packet–packets aren’t just comprised of the data they are trying to convey.

The bytes in each layer of a packet define information based on what protocol is being used at that layer. As an example, let’s look at something called Ethernet protocol. Unless you are on a wireless connection, your computer is likely is plugged into a network using a Cat5 cable (they are typically blue cables with a tabbed connector on the end, although the color doesn’t actually matter). That being the case, there’s a 99.99 percent chance that your computer attaches Ethernet protocol information known as an ‘Ethernet header’ to the front of every packet it sends. Ethernet is a pretty simple protocol used to provide a source and destination address for packets on a local network. It also defines the protocol of the bytes that are following directly after the Ethernet header. Because Ethernet is strictly defined, we know that the first 6 bytes of data will be interpreted as a destination address, the next 6 bytes following will be interpreted as a source address, and the next 2 bytes following will be interpreted as a statement of the protocol type of data following the Ethernet header. So, the Ethernet header is 14 bytes in length and has 3 pieces of important information.

Did you think I had forgotten that this was supposed to be an article about Wireshark at this point? Well, I haven’t! The beauty of Wireshark is that it automatically interprets all of this information from many different protocols and displays it in a hierarchy for you for each packet. If you were looking at the raw data for a packet and wanted to interpret the Ethernet header portion, you’d be examining the blue stream of bits below.

wiresharkbits

That looks like fun, doesn’t it? Anything look familiar to you? Maybe it’s the fact that there are 14 groups of 8 bits, or 14 bytes outlined in blue. Remember that 14 bytes is the length of the Ethernet header which is placed at the beginning of a packet. Now we’ll look at Wireshark’s interpretation of this information.

wiresharkethernet

 

Whoa, hey! Are those English words in that picture? Why yes, they are! As you can see, we have selected and expanded the Ethernet header portion of a packet and we can now see that the destination address is “00:22:6b:80:56:0d”, the source address is “00:19:66:ec:ee:ab”, and the type of protocol that is coming up next in the packet is ARP or Address Resolution Protocol.

But Cameron, you might say, that still looks like nonsense to me! How the heck does “00:19:66:ec:ee:ab” tell me anything more than “00000000 00100010 01101011 10000000 01010110 00001101”? Well, honestly, it won’t just yet if you don’t understand what a source and destination address are used for in the Ethernet header and how it is derived into human readable text from the bits themselves. But in the future, when you do know, Wireshark gives you the capability to quickly find this information in every packet.

And remember when I said it takes a lot of 1’s and 0’s for our enjoyment of computer networks? Well, Wireshark can prevent the “needle in a haystack” issue of searching for problematic packets among the thousands or millions that you might capture in a single capture session by providing efficient search options. For example, even if I have captured a million packets in a single capture session and I wanted to find the one packet with a destination address of “00:19:66:ec:ee:ab”, I can create a display filter in five seconds which will allow me to find that packet and analyze its contents. You could create a filter which will show you all traffic to a particular computer, or all traffic for a particular service (port), or all traffic which contains a specific value of a particular protocol, or any combination of these (e.g. all traffic to a computer which is sent to a particular port and contains a particular value), and many, many more.

There are a multitude of other reasons to use Wireshark, but I hope this article has at least piqued your interest. As a student, I found it difficult to relate to the information I was seeing in Wireshark and didn’t realize the potential for learning until after many grueling and tedious Wireshark sessions. Now I love this thing because it actually helps me fix issues.

A final disclaimer about Wireshark: don’t use it on any network that you don’t have explicit, preferably written permission to do so. You can get into some legal trouble or get fired from your job if you aren’t careful about where you capture packets.