Monthly Archives: December 2013

Wireshark Skills Series 5 of 7

Hopefully by now you have drank the proverbial kool aid and think Wireshark is the best tool since… ever. Yes, it is awesome but there are some security concerns. If a hacker compromises your server as a very under privileged user, it may benefit them to already have a packet capture utility installed so they can just run it instead of being denied to install it. You can also use it to discover other computers on the network and start making some dangerous assumptions.

One of the neato tricks to do is take a lengthy capture, then do a string search for your password. If your password is going over the wire, I would recommend dropping whatever service it is that you are using that would send your password over the wire, unencrypted.

Standard FTP is one of those services that will send plain text passwords. I have downloaded a .vhd for server 2012 R2 and installed the IIS + ftp role and feature.


In the previous captures we haven’t limited the capture itself and instead we are filtering post capture. Instead of a post filter, lets apply a pre filter. Open up the capture options and filter on the standard FTP port of 21.


To test out the security of our authentication choice, open up the simple, built-in Windows FTP utility. Type at the command prompt: ftp [Enter] open or whatever your practice server is and pause a second to take a look at the capture. Nothing too crazy here, just a 3 way TCP handshake and then the FTP server responding with code 220 meaning it is “ready for new user.”


I chose Basic authentication and allowed all users to connect with no SSL. That means if I enter a Windows username and password I should be able to log in.


The login worked great! But I have also allowed my username and password to be compromised by someone capturing packets on the server.

Leave a comment

Posted by on December 17, 2013 in Network Admin



Wireshark Skills Series 4 of 7

In some of our HTTP requests there was something interesting going on that didn’t make the cut to be explained. The magic of Ethernet was fast at work furiously chopping up data at one end of the pipe and reassembling it at the other. Packets can be all different sizes but if they exceed a limit they will get sliced and diced.

Increasing the size of the packet reduces the amount of overhead needed to transfer your data. Both ends of the pipe and everything inbetween have to support the packet size that is being sent. If a switch or router doesn’t support it the connection may fail. If it is supported but not properly configured you could run into a silent problem where that intermediate device is fragmenting the packets. It is best to change jumbo packets at the intermediate switches and communications devices first, then at the endpoints. Also, some applications like Microsoft SQL Server need configured to send larger packets too.

To illustrate this process we are going to use the ping tool. Ping runs in ICMP which is on top of IP and Ethernet. Ethernet is the layer where the MTU setting resides. Before we change the MTU lets take a look at a large ping getting sliced up like the HTTP traffic we saw earlier. This command will continuously ping with 10,000 bytes of data. For this test I am running Wireshark on a Windows 2012 R2 server. (VHD 180 day Trial:

ping -l 10000 -t


If you squint really hard you can see 7 packets coming into the server and 7 packets going out of the server. Ethernet + IP require 36 bytes per packet so the overhead can add up quickly. If you look at the length, you will see no packet is over 1514 bytes in size.

Now we can try to make this more efficient. I’ll have to configure the vswitch and the virtual machine NIC to enable jumbo packets.




Now if we re-try that ping we should notice fewer packets.


Success right? Well yes in this case we made the process 340 bytes more efficient. However, since I enabled jumbo packets I broke other things. Most notably my blogging software :]

Leave a comment

Posted by on December 16, 2013 in Network Admin


Wireshark Skills Series 3 of 7

In my previous post on HTTP I used a tool called nslookup. It helps debug issues with DNS servers. Today I am going to inspect a few DNS requests in Wireshark.

Before we hit start, lets cover a few basics. DNS lives in layer 7 and operates on IP and UDP ( DNS is heavily cached so not all name lookups will end up in Wireshark. Hostnames are an example of private names. Today we are going to focus on public names that are served by the public internet.

In order to make for a good test, I am going to clear my DNS cache. At the command prompt type “ipconfig /flushdns”. If using chrome click the clear host cache button ( chrome://net-internals/#dns ). Next type ipconfig /all and take note of the primary dns server name.

Now we can start the capture. Apply the “dns” filter and visit this site Notice the address bar change. Not only did we get redirected to https, we also got redirected to .org instead of .com. This is a slightly more interesting site than normal and it’s why I chose it. Lets take a look at that in Wireshark.


DNS queries are quick, small and efficient. The first response is 107 Bytes and has two answers. The first answer is just a CNAME or pointer to the real HOST A record “”. The CNAME won’t ever have an IP but does have a Time to live of 1 hour which is much greater than the HOST A record. TTL instructs the client how long to cache the record before having to query for it again. Also, there doesn’t have to be an answer for no “www” there just usually is.

There isn’t anything in that first DNS query that directs us to .org. Based on the packet numbers, there were 7 things that happened that we have filtered out. Clear the filter to take a look at the missing packets. When you find that DNS response you will see what happens next.


The DNS query gave us an IP. Now we can do stuff :] In this next segment of the capture you see a TCP 3-way handshake. Once that is complete my browser makes a HTTP GET request. The HTTP 301 response redirects us and not DNS. Then we start this whole process again with another DNS query.


DNS is for convenience. Ain’t nobody got time to memorize all the IPs of websites they want to visit. In the example, we had to wait for 2 painful round trips just for dns in order to actually get the “doing stuff” point. Fortunately, this is only required for the first lookup and the rest is sent to the DNS resolver cache until the TTL expires. Had the first CNAME actually pointed to the host we need we could have saved some time.

Also in the example, you’ll notice that I haven’t changed any of my settings in my router or PC in regards to DNS. They are set to automatic, which means I went all the way to my ISP to figure out what DNS server to use and naturally they suggest themselves. Instead of Comcast, Google has another option and they claim it can be faster. Lets investigate by changing your DNS in your router, or just for your PC. Verify the settings took with ipconfig /all. With this configuration I’ll only have to use Comcast if both Google servers are down. The order is important because the first one you enter is your primary.

DNS Servers . . . . . . . . . . . :

If we test the same scenario, you can see in the capture that the Source of my dns responses are now Google. And, in at least very casual testing, the Google servers are faster this time.


Because of physics, the location of this server you are contacting is very important. How far is a millisecond? Well that is a curious question which could be answered by the speed of light which is 186 miles. Multiply that by the pieces of equipment in between you and that server and you will have a vague estimate of how long your DNS queries will take in a no contention, best case scenario.

Before you settle on a different DNS server make sure to test everything. Especially services with a content delivery network that Google might not be privy to (


The OSI model doesn’t do DNS justice. So many things depend on it’s operation that it is best to envision it lower in your stack. Understanding and tuning at the lower levels can cause exponential benefits in user experience.

Leave a comment

Posted by on December 15, 2013 in Network Admin


Wireshark Skills Series 2 of 7

One of the most fascinating things I did in my early years on the internet was click “View Page Source”. Down the rabbit hole I went, barely understanding what was going on or who to even ask for help.

Taking a network capture is much like viewing page source of the network traffic. Webmasters generally understand that their HTML source will be viewable if they post it. However, users don’t always understand that their web traffic is viewable by anyone with access.

For today’s exercise, lets open up Wireshark and start a capture. While that is running, clear your browser cache and check to see what is on


Lets grab the server name from the address bar and figure out what IP to filter on. We can do that with nslookup.


And filter…


Take a moment to imagine yourself troubleshooting a server problem. Our client side capture has a source and destination IP. If we ran Wireshark on the server, the source and destination IPs would not simply be reversed. The webserver’s local IP would be displayed and my PCs public IP would be displayed. To find your local IP address use ipconfig (or ifconfig in linux). To find your public IP address search “IP Address” in google.

If we go back to our client based capture we can see a lot of chatter has happened. Lets filter than down a little bit more to only review the HTTP traffic. Add a second filter by using inclusive and logic. This filter syntax for AND is &&. That makes our filter “ip.addr eq && http”


Entering into the address bar produces a GET command 610 milliseconds after I started the capture. I know this because packet No.24 has a time of 0.6098. The next packet is the server responding with HTTP 200 which is a good response code. This packet was recieved almost 100ms after the request went out. If I ping the IP address I can see my network latency is about 40ms. Sending a slightly larger ping using the -l switch will let me know about how much time is server time and how much is network time. If packet 24 is sending 735 bytes and packet 95 responds with 1248 we can get a rough idea of latency by using ping -l 2083.


That first GET request gives my browser the HTML. In that HTML are several scripts and files I have to go request separately from the original request. Those are in packets 101-107. This happens quickly because it is in the HEAD tags in the HTML. You can drill into each packet and if you expand the data, you might recognize HTML source code which is what you see when you click “view source” in your browser.


There are lots of ways to go from here. Before you start analyzing HTTP in Wireshark, I would suggest checking out some other tools that are specifically designed for website debugging such as Fiddler.

Leave a comment

Posted by on December 13, 2013 in Network Admin


Wireshark Skills Series 1 of 7

Wireshark is a network protocol analyzer. It uses the WinPcap library to collect dumps of TCP packets and presents you with a load of features to help analyze the capture.

In this series we will generate common network traffic and then attempt to make some sense of it in Wireshark. Go grab yourself a copy and start a quick capture.


Once you see the colorful lines start scrolling go try to access a network share. In my example I attempted to connect to a lan computer \\\ but then failed to login.

PRO TIP: Make sure you hit stop when done capturing. Displaying all the packets in the GUI will use up all of your ram eventually. Under capture options you can save on ram by unchecking “Update list of packets in real time”. This way you are limited by space on your drive instead of in memory.

The first challenge with a packet capture is weeding out all the crap. At the top there is a filter bar. It isn’t very intuitive but it is very powerful.

If we want to take a look at only packets with a destination of this would be the filter to apply: ip.dst eq
Another option would be to view any packets that match (source or destination) the ip ip.addr eq


The second filter can give us a better understanding of the back and forth conversation between computers. In my particular example I have already cut through hundreds of packets. The bottom status bar shows us how many packets and what percent we are displaying.

But we are still displaying 231 packets, ain’t nobody got time for that. Let’s go up to the Analyze menu and select “Expert Info”. Two tabs over to “Notes” and we found something interesting. Fault: nca_s_fault_access_denied in the DCERPC protocol. Access denied was the fake problem I created during the capture. Expand that note and click the packet, which will navigate us to that packet number in our main screen.


If we right click on that packet and select “Follow TCP Stream” the filter will change and show us the conversation that ended in heartbreak. Also, that maneuver got me down to 15 packets.

In order to make any sense of this packet capture we’ll have to learn about the DCERPC protocol. Fortunately for us, there is a wireshark wiki article on this protocol which shows some example traffic:

So that gives us a taste of what is going on with the protocol. Then if you feel like reading yourself to sleep you can view Microsoft’s implementation of protocols over here:

To review, we have installed WinPcap/Wireshark and gotten a feel for taking and filtering captures. In my next post we will take a look at a simile HTTP request.

Leave a comment

Posted by on December 10, 2013 in Network Admin