Chris Sanders

In the past when folks had asked me if I was aware of any type of packet capture file repository in the Internet, I had pointed them towards OpenPacket.org. The site never really seemed to take off, and I just saw this post on Bejtlich’s TaoSecurity blog. That being the case, I will now be recommending Pcapr from Mu Dynamics. I’ve just now been made aware of it, but it already seems to have quite a bit of good content. I hope to contribute some files from my lab to it as well.

The date has been set for my first ever online Wireshark training. This will be held live on Thursday, December 11th at 2 PM Central Standard Time. The training will be taught via Go2Meeting and the slides and capture files used will be made available after the presentation. The cost for attending is $150. The only prerequisite is a basic knowledge of computer networking and an interest in the subject. Here is a breakdown of the curriculum:

Hour 1

Benefits of Packet Analysis
How a Packet Sniffer Works
Installing Wireshark
The OSI Model
Types of Traffic on the Wire
Analyzer Placement on the Cabling System
Basic Wireshark Features
Advanced Wireshark Features
Wireshark Statistics

Hour 2

Display/Capture Filters
Common Protocols (TCP, HTTP, DNS, DHCP, ARP, TELNET, FTP, POP, SMTP, etc)
Troubleshooting Performance Problems
Network Baselines
Wireless Packet Analysis

Hour 3

Additional Wireshark Tools and Resources
Useful Websites and Other Learning Resources
Q&A

I already have quite a few people signed up and will be limiting the number of attendees so that I can answer as many questions during the Q&A as I can without leaving anybody out. If you are interested, e-mail me at chris@chrissanders.org and reference the class. Payment is accepted via check (must have it very soon so it can clear in time for the training) or PayPal (info will be provided when you e-mail me).

Wireshark is a great way to monitor Internet traffic when the need arises. In situations where some type of proxy server isn’t in place to monitor Internet traffic, Wireshark is a great substitute. Whether you capture the target computers traffic via port mirroring or ARP cache poisoning, Wireshark has a simple interface you can use to view the HTTP traffic going across the wire. In order to do this, capture the appropriate traffic and select Statistics from the drop down menu, select HTTP, and choose the Requests option. You will be presented with the option to filter the traffic. Once you create a filter if you choose to, click the Create Stat button and you will see a window like the one below that will give you a breakdown of the HTTP requests captures on the wire.

One important note…make sure that when you are capturing this traffic you filter out any HTTP requests that may be occurring on your analysis computer. Although you may not be browsing to the Internet interactively, that’s not to say your computer is generating HTTP requests due to Antivirus updates, Windows updates, etc.

One of the coolest newer features of Wireshark is the ability to automatically generate firewall ACL rules based upon a packet you may be viewing. As an example of this, take a look at the following packet:

If you look at the data portion of this packet you can see that this is packet generated by the infamous blaster worm. Notice the destination port is 4444 which is the standard port used by blaster. In the case, let’s say we want to create a firewall ACL rule that blocks anything with a destination port of 4444 on an iptables firewall. If we select this packet, go to Analyze > Firewall ACL Rules on the standard toolbar, we will get a dialog that will let us build custom firewall rules based upon the contents of this packet. In our scenario here, we would select Netfilter (IPTABLES) from the vendor drop down box, and select TCP Port 4444 in the filter box. This will output the exact command you need to enter in your iptables configuration to enact this firewall rule. If you play around with this feature you will see that there is quite a bit you can do with it.

This feature is very new and doesn’t support a lot of different vendors, but this should develop over time.

One of the first windows you may often want to view when analyzing a capture file is the capture summary window. You can access this by opening a capture file and going to Statistics in the drop-down menu and selecting Summary. The wireshark summary window gives us a few really useful things. First of all, it gives us a time reference as to when the capture was taken as detailed in the first packet and last packet fields. Second of all, and one of the things I find most useful is the throughput fields displayed in this window. Here you can see the things such as the average packet size, total bytes captures, and the average Mbytes per second. I often will use the Mbit/sec to determine congestion on the wire. You can compare this number with the line speed on the network (100 Mbit/sec, 1 GB/sec, etc) to determine if you are seeing congestion that might cause packet loss.

Unfortunately, sniffing packets isn’t always as easy as plugging into an open port and firing up Wireshark. In fact, it is sometimes more difficult to place a packet sniffer on a network’s cabling system than it is to actually analyze the packets. In the grand ole days of packet analysis when everybody used hubs you could plug in and sniff all of the traffic on a network segment. As most of you know now however, the advent of switched networks prevents this. When you plug a sniffer in to a port on a switch, you can only see broadcast traffic and the traffic transmitted and received by your machine. Because of that we have had to come up with a few alternative techniques to getting the traffic we need.

The three most popular techniques for doing this are port mirroring, hubbing out, and ARP cache poisoning. The goal of this article is to give a brief overview of port mirroring and hubbing out, which are very commonly used, and then to give a detailed explanation of ARP cache poisoning, the least well known of the trio.

The Common Techniques

Port Mirroring is probably one of the easiest ways to capture the traffic you are looking for. Also called port spanning, this is a feature available on most managed network switches. This is configurable by accessing the command line or GUI management for the switch the target and sniffer systems are plugged in to and entering commands which mirror the traffic of one port to another. For instance, to capture the traffic of a device plugged in to port 3 on a switch, you could plug your sniffer into port 6 and enter a vendor specific mirroring command that mirrors port 3 to port 6.

Hubbing out is a technique in which you localize the target device and your analyzer system on the same network segment by plugging them directly in to a hub. In order to do this, all you need is an old hub and a few network cables. Simply go to the switch that the target computer resides on and unplug it from the network. Plug the targets network cable, along with the cable for your sniffer, into the hub, and then plug the hub into the network switch. This will put your sniffer and the target machine on the same broadcast domain and allow you to see all of the packets going to and from the target machine, as well as yours. Since this does involve a brief moment of connectivity loss, I do highly recommend letting the user of the target system know that you will be briefly disrupting their connectivity, especially if it is someone in management!

Poisoning the ARP Cache

The ARP protocol was designed out of necessity to facilitate to translation of addresses between the second and third layers of the OSI model.  The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communications happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”. I’m not going to go into detail on the whole ARP process here, but I highly recommend reading my Packet School 201 write up on it here in order to better understand this process.

ARP cache poisoning is a more advanced form of tapping into the wire on a switched network. It is commonly used by hackers to send falsely addressed packets to client systems in order to intercept certain traffic or cause denial of service (DoS) attacks on a target, but ARP cache poisoning can still serve as a legitimate way to capture the packets of a target machine on a switched network.

ARP cache poisoning, sometimes referred to as ARP spoofing, is the process of sending ARP messages to an Ethernet switch or router with fake MAC (Layer 2) addresses in order to intercept the traffic of another computer.

Using Cain & Abel 

When attempting to poison the ARP cache, the first step is to download the required tools and collect some necessary information. We’ll use the popular security tool Cain & Abel from Oxid.it (http://www.oxid.it). The installation is pretty straight forward so I won’t go through that here.

Once you have installed the Cain & Abel software, you need to collect some additional information including the IP addresses of your analyzer system, the remote system you wish to capture the traffic from, and the router that the remote system is downstream from.

When you first open Cain & Abel, you will notice a series of tabs near the top of the window. (ARP cache poisoning is only one of a variety of Cain & Abel’s features.) For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.

Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol, and click OK.

The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.

At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.

Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.

Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of the target computer whose traffic you wish to sniff. This will result in the right window showing a list of all hosts in the network, omitting the target machine’s IP address. In the right window, click the IP address of the router that is directly upstream of the target machine, and click OK.

The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the target system and its upstream router.

You can now fire up your packet sniffer and begin the analysis process. When you are finished capturing traffic, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.

A Final Note

As a final note on ARP cache poisoning, you should be very aware of the roles of the systems you implement this process for. For instance, do not use this technique when the target device is something with very high network utilization, such as a fileserver with a 1Gbps link to the network (especially if your analyzer system only provides a 100Mbps link). When you perform this rerouting of traffic, all traffic transmitted and received by the target system must first go through your analyzer system, therefore making your analyzer the bottleneck in the communication process. This can create a DoS-type effect on the machine you are analyzing, which will result in degraded network performance and faulty analysis data.

That is all there really is to ARP cache poisoning. This technique has always proved significantly useful in packet analysis experience and I hope it does in yours as well.

As many of you who are trying to buy a copy of PPA have probably noticed, it is sold out pretty much everywhere. This is because the first printing was in such high demand that it sold out completely. As with most technical books, there were some errors that didn’t get caught in the technical editing phase, so we have been waiting on those to get fixed before reprinting the book. Those are now fixed and the book was sent back to the printers the early part of this week. This means that the book should be back on the shelf in 4-6 weeks. Thanks to all of those who have bought or plan on buying a copy!

The ARP protocol was designed out of necessity to facilitate to translation of addresses between the second and third layers of the OSI model.  The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communications happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”.

How it Works

The basic idea behind ARP is for a machine to broadcast its IP address and MAC address to all of the clients in its broadcast domain in order to find out the IP address associated with a particular MAC address. Basically put, it looks like this:

Computer A – “Hey everybody, my IP address is XX.XX.XX.XX, and my MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP address XX.XX.XX.XX, but I don’t know what their hardware address is. Will whoever has this IP address please respond back with their MAC address?

All of the other computers that receive the broadcast will simply ignore it, however, the one who does have the requested IP address will send its MAC address to Computer A. With this information in hand, the exchange of data can being.

Computer B – “Hey Computer A. I am who you are looking for with the IP address of XX.XX.XX.XX. My MAC address is XX:XX:XX:XX:XX:XX.

One of the best ways I’ve seen this concept described is through the limousine driver analogy. If you have ever flown, then chances are when you get off of a plane, you have seen a limo driver standing with a sign bearing someone’s last name. Here, the driver knows the name of the person he is picking up, but doesn’t know what they look like. The driver holds up the sign so that everyone can see it. All of the people getting off of the plane see the sign, and if it isn’t them, they simply ignore it. The person whose name is on the card however, sees it, approaches the driver, and identifies himself.

The Packet Level

Understanding the basic concept of ARP, we can take a look at some packets to see how it actually functions. Here we will step through the entire ARP process, start to finish. In this scenario Computer A needs to communicate with Computer B. you can download this sample capture file here.

Step 1: Computer A Generates Broadcasts an ARP Request Packet

The packet details window of the first packet in the capture file is very straightforward. The computer at 192.168.0.114 needs to communicate with the computer at 192.168.0.1, but doesn’t know its MAC address. Notice that the target MAC address here is 00:00:00:00:00:00. This being the case, it sends a packet with the destination address ff:ff:ff:ff:ff:ff, in turn broadcasting that packet to everything on the current network segment. This is the basic ARP Request packet, as stated in the Opcode field.

Step 2: Computer B Receives the Request and Broadcasts an ARP Reply Packet

The second packet is our reply from 192.168.0.1. This device received the ARP Request in step one, and generated this reply addressed to 192.168.0.114. Notice that this reply contains the information that 192.168.0.114 needs to communicate properly. This is the sender MAC address in this second packet. You can tell immediately that this is an ARP reply by looking at the Opcode field. 

Step 3: Communication Can Begin

Once the device at 192.168.0.114 receives the ARP Reply it can then take the MAC address of 192.168.0.1 and put it in its ARP table for future use. With this new information, ARP can successfully translate between layer two and layer three so that communication can move on to the physical medium.

Homework

ARP is by far one of the simpler protocols you will see, which is why I chose to use it for our first session of Packet School 201. Take a packet capture of your network and you are bound to see some ARP packets flying across the wire every now and again. See if you can pinpoint some of these and isolate the requests and replies. If you really want to learn a bit more about ARP, and how it can be used for malicious purposes, do some reading on ARP cache poisoning.

I have had several people ask about the layout of the chapters in the upcoming book, so now that I have something formal typed up, here ya go:

Chapter 1: Packet Analysis and Network Basics
What is packet analysis? How does it work? How do you do it? This chapter covers the very basics of network communication and packet analysis.
Chapter 2: Tapping into the Wire
This chapter goes through the different techniques you can use to place a packet sniffer on your network.
Chapter 3: Introduction to Wireshark
Here, we’ll look at the basics of Wireshark—where to get it, how to use it, what it does, why it’s great, and all of that good stuff.
Chapter 4: Working with Captured Packets
Once you get Wireshark up and running, you will want to know the basics of interacting with captured packets. This is where you’ll learn.
Chapter 5: Advanced Wireshark Features
Once you have learned to crawl, it’s time to take off running with the advanced Wireshark features. This chapter delves into these features and goes under the hood to show you things that aren’t always so apparent.
Chapter 6: Common Protocols
This chapter shows what some of the most common network communication protocols look like at the packet level. In order to understand how these protocols can malfunction, you first have to understand how they work.
Chapter 7: Basic Case Scenarios
This chapter contains the first set of real-world case scenarios. Each scenario is presented in an easy-to-follow problem, analysis, solution format. These basic scenarios deal with only a few computers and involve a limited amount of analysis—just enough to get your feet wet.
Chapter 8: Fighting a Slow Network
The most common problems network technicians hear about generally involve slow network performance. This chapter is devoted to solving these types of problems.
Chapter 9: Security-Based Analysis
Network security is the biggest hot-button topic in network administration. Because of this, Chapter 9 shows you the ins and outs of solving security-related issues with packet analysis techniques.
Chapter 10: Sniffing Into Thin Air
The last chapter of the practical section of the book is a primer on wireless packet analysis. This includes what is different about wireless analysis as opposed to wired analysis, as well as a quick case scenario involving these techniques.
Chapter 11: Conclusion and Further Reading
The final chapter of the book sums up what you have learned and includes some other reference tools and websites you might find useful as you continue to use the packet analysis techniques you have learned.

Release date is less than a month away! Get your copy purchased now before the price goes up!

Purchase Here At Amazon.com!

Now that the book is very nearly complete and we have managed to get a lot of the particulars squared away I figured now would be a great time to give everyone the low-down on the book and why it would be a good addition to your book shelf.

First of all, the book has finally been titled. Unfortunately it wasn’t one suggested by a reader, but it is a good one none the less. The final title of the book is:

Practical Packet Analysis
“Using Wireshark to Solve Real-World Network Problems”

As for a description, here is what we figured up for the books tipsheet:

“Wireshark (formerly called Ethereal) is the world’s most popular “packet sniffer,” allowing its users to uncover valuable information about computer networks (whether theirs or others). Rather than simply take readers through Wireshark’s tools, Practical Packet Analysis shows readers how to use the software to monitor their own networks. The book is aimed at network engineers and systems administrators, but its clear enough for even Wireshark newbies. The author begins by discussing how networks communicate and builds from there to give readers a solid understanding of how packets travel along the wire. The second half of the book contains real-world examples and case scenarios that help readers apply the knowledge they learn to their own networks. Includes a bonus CD with example trace files that readers can explore on their own as well as videos that show packet analysis in action.”

Rephrased in my own words:

Basically, this book is aimed at anybody who works on, around, or with a computer network. If you do any of those things then if you ever hope to be REALLY good at it you are going to have to learn how things work at the packet leve, and this book is your guide to do that.

I like to think of the book as being divided into three real sections.

The first section starts with a primer on network communication. This means the OSI model, TCP/IP, Ethernet, addressing, network hardware, routing, and all of that good stuff. It doesn’t go into a whole lot of detail..just gives you enough to get started and understand the rest of the book. I do make sure to point to outside references however so you can learn more about each specific thing if you so please.

The second section of the book is the “Intro to packet analysis and Wireshark” part. Here I talk about what packet analysis is, how it works, and how to do it. The later half of this section is devoted to going over the basic and advanced features of Wireshark itself all the way from downloading and installing it to using its graphing and trending feautres.

The last section is what I like to call the money section. If you are going to buy the book this is the part you are going to be paying for. This section, consisting of four chapters is what gives you the knowledge you will need to understand the packet analysis process. The first chapter is devoted to looking at common protocol at the packet level. This means you will actually see what TCP/IP, HTTP, FTP, ARP, MSNMS, ICMP, etc look from the view of a packet analyzer. From this point there are three more chapters dedicated completely to case scenarios and situations. Divided into chapters for basic scenarios, security scenarios, and slow network scenarios you will go through several dozen scenarios all the way from the users initial complaint to analysis to solving the problem. You may never see these exact problems on your network but using the techniques given you will have the ability to properly analyze any situation that comes up.

Lastly, along with the book comes a CD with LOADS of goodies on it. The main thing the CD will be used for is all of the trace/capture files. Any time I mention a trace or capture in the book you will be able to pull it off of the CD and look at it yourself. Heck, you may even see some things in the capture files that I managed to miss! Along with these capture files I there will be included some video analysis of some capture files and one VERY special feature that I can’t quite talk about right now…but trust me..it’s going to be HUGE.

Other Bonuses

A couple other great things start with the fact that this book is being technically reviewed by none other than Gerald Combs, the author of the Wireshark program. If you are going to buy any book about Wireshark then you are going to want the one that is technically endoresed by the guy who made the program. Along with Gerald, Laura Chappel from the packet analysis institute has so graciously provided me with a bulk of the capture files being used for examples in the book. This means that along with my analysis you will also see shades of hers.

There isn’t a date yet on when it will be released but you can figure on it costing about $39.95 USD. Also, I plan on giving away a couple of autographed copies to readers of the site, so look for that soon!

** Disclaimer to all new readers – This blog post is VERY old and not really representative of my current work. I’ve just left it up here for historical purposes. If you are interested in learning more about packet analysis I’d reccommend reading some of my newer posts or looking at my book, Practical Packet Analysis. **

After a couple weeks of down time I finally have completed the next installment of Packet School 101! In this section we are going to turn towards the security side of things and look at a couple trace files of what effects a port scan and a denial of service attack can look like.

Port Scan

One of the first steps a hacker is going to take when determining whether or not he can break into your computer is to perform a port scan on it. As most of us are aware, every form of network traffic that enters or leaves your computer does so through the use of a port. Most services use a standard port, and with this being the case potential intruders can often identify what services are running on your computer in an attempt to exploit them. A port scanner is the primary tool used to identify these ports and services. These tools usually have a predefined range of ports and will scan a target computer to see if those ports are open.

Examining the Scan

Click here to download the sample trace file (<5 KB)

This trace file is very small and to the point. In this scenario, we are concerned that someone from within our network may be trying to remotely compromise another workstation. In order to get a better understanding of what is going on we take the trace of the suspected target computer and the suspicious activity we have found is what is in the sample trace file. What we see is a lot of communication happening between 10.100.25.14 (local machine) and 10.100.18.12 (remote computer). If you look a little closer at these packets you will see exactly why they are so suspicious.

Most packet analysis programs will show the port that the communication you are witnessing takes place on. Wireshark is no different and does so exactly the same in the “info” column. What we see in our trace file shows us that every single packet that is being transferred from the remote computer is being sent to a different port number. Not only this, but these port numbers just happen to be commonly exploited ports. We see ports such as telnet, microsoft-ds, ftp, smtp, etc. Anytime you see something like this where a remote computer is sending packets to commonly exploited ports such as these you can typically assume something is up, and that something will usually lead you to piece of port scanning software.

Denial of Service Attack

Eventually in dealing in network administration and security you will encounter hackers who have malicious intentions in mind. One of the methods commonly used in a malicious manner is a Denial of Service (DoS) attack. During these attacks, a remote computer will flood another computer with a continuous amount of data in order to slow it down to the point that it fails to provide service to its legitimate users. To complicate things even more, remote computer can often be teamed together in this effort to perform what is called a Distributed Denial of Service (DDoS) attack in which more than one computer attempts to flood another with data. Going one step further, a DoS or DDoS attack can target an entire network as well as an individual computer. These applications send out a continuous stream of broadcast packets on the network, which are then sent to every node on your network (we will talk more about broadcast and multicast packets in the next installment). In our sample trace file we will look at an example of a DoS attack aimed at an entire network segment.

The Packet Level

Click here to download the sample trace file (<10 KB)

In our scenario we have noticed a major network slowdown that has virtually stopped all network activity on a particular segment. Upon physical observation of the switches we can see that all of the port activity lights are blinking furiously in unison. This information alone is enough to know that we have some type of broadcast traffic coming from somewhere.

Once we begin to look at our trace file we see a whole bunch of the same thing. It appears we have packets being sent out at a blistering rate to every node on the network. Our first reaction would normally be to look at the source IP address of this traffic and begin tracking it down. However, in this case we can see that no two packets are coming from the same IP address. This is because unfortunately, sometimes attackers think of things before we do, and in this case the program that is being used to generate this traffic was designed to spoof fake IP addresses to send the data from. So how can track down the source of this attack? Well, there is a technical and a non-technical solution to this.

The technical solution to this problem will require you to have some type of software that is integrated into your switches/routers that allows you to view the amount of inbound and outbound traffic coming from each particular port. With this method you can find the port that is amassing a lot of outbound traffic and take a visit to that machine. The non-technical solution is to go to your wiring closet and start unplugging ports one by one until the lights on the switches stop flashing repeatedly and in unison. If you have your ports labeled properly you should then be able to track down the physical location of the machine and take further action. The non-technical solution is something probably left better for after business hours.

Homework

It is obvious that examining things at the packet level can be a security analysts best friend. You will not find a successful network security analyst who doesn’t have a good understanding of how things function at the packet level and how to interpret the things they see when doing packet analysis. Sniffers can be used for simple security issues like the ones we looked at as well as more complicated scenarios such as looking for hidden data injected into packet headers or analyzing complex network worms and viruses. To get a better grasp on the security aspect of packet analysis you may want to try running a couple of different types of port scans on your test network. In the next and final section of Packet School 101 I will be answering your questions. I have already gotten a lot of questions but am looking for more so feel free to e-mail them to me at chris@chrissanders.org.

I have just signed my second book deal, this time with No Starch Press (distributed by O’Reilly). The book will be called “Hacking Packets with Wireshark” and will be based on my Packet School 101 series. My scheduled completion date is around February and I am looking at something along the lines of 250-300 pages. This being said, what do you guys want to see in this book? I am open to any and all suggestions so don’t hold anything back!

** Disclaimer to all new readers – This blog post is VERY old and not really representative of my current work. I’ve just left it up here for historical purposes. If you are interested in learning more about packet analysis I’d reccommend reading some of my newer posts or looking at my book, Practical Packet Analysis. **

In this segment of Packet School 101 we are going to take a look at the trace files of a computer infected with spyware and one suffering from an application fault.

Spyware Infection

In our first sample scenario, a user has called complaining that her computer is dropping its network connection three minutes or so after booting up. When this happens the computer also maxes out its processor utilization. After making some calls you verify that everybody else is running as they should be, so the problem is just isolated to this one computer. When looking at the computer, it is apparent that her problem does exist as told. So what do we do? We fire up our sniffer of course!

Examining the Packets

Click here to download the sample trace file (< 1MB)

In examining our trace file there are a lot of problems with many things going on but we are only going to focus on the one client machine we are looking out down. It’s IP address is 172.16.1.10. The first thing we notice at the beginning of the capture is that an outside IP address keeps trying to make a connection to our computer on port 26452. Our client doens’t know what to do with this traffic since it is not expecting it, and therefor sends repetitive RST packets effectively ending the communication. This obviously should not be happening, however it continues to do so until we get to packet 70 and see the client requesting a copy of a file called analiz.exe from this rogue IP address via TFTP. This file begins to download, and ironically enough, that is when the computer starts experiencing problems

The Resulting Analysis

After spending some time actually on the physical computer the process analiz.exe was found to be running. After terminating this process and removing the file via an autmated spyware scanning utility the computer began to run normally. What was happening in this case was that after a computer would boot up it would try to make a connection to the rogue IP address associated with this spyware. After a certain amount of time the client would then download an updated copy of this spyware file via TFTP and run it on the system.

This brings up several good security points to remember. The first one of these is the most obvious and that is to education your uses about spyware and how to avoid it. However, another key point to mention is that this infection did a lot of its dirty work through TFTP which is a UDP based protocol. A lot of the time when configuraing firewall filtering rules most administrators will completely ignore UDP and only focus on TCP. You can not neglect UDP protocols when doing this, as a lot of spyware will use this weakness to completely hammer your netork.

Application Fault

The next file we are going to examine is the trace of an appliciation fault that is causing a client computer to run incredibly slow. In this scenario we have a client who is complaining that their application is not working because the network is running to slow.

Digging Deeper

Click here to download the trace file (< 1MB)

When we open our trace file we can determine several things by looking at the first fewpackets. The first thing we see is communication taking place between our client and server machines. Looking at the packet times we can see those requests are happening at rates of less than a millisecond so that indicates that there shouldn’t really be any latency on the wire itself. Also, we see that the client and server are sending their data back at more than adequate rates so there shouldn’t be an issue with either of them acting sluggish.

When we get to packet 5 however, we begin to see something interesting. Our client machine is making a NetBIOS request to our server, and then in the following packet, our server (which is NOT running NetBIOS) returns an ICMP Destination Port Unreachable packet. So what is causing this NetBIOS traffic from our client? Well Wireshark provides a great interface for viewing data contained within a stream of data. In order to utilize this you will need to right click on packet number 4 and click “Follow TCP Stream”. This will show us the data contained in that stream of communication, including upper layer protocol information.

When we look at this stream of data it is clear to us what is going on. The user is attempting to use the AIDA32 application. Not only do we find out this information, but we can also see that they are doing this under the “Chadwick” user account which is in the administrators group of the local machine.

The Verdict

After looking at this TCP Stream data it is clear to see that the network is not at fault. What is happening is that the application is making a NetBIOS request to the server, and since the server isn’t running NetBIOS it responds to the applications request by saying it is busy. In the design of the application which is being used, there is no formal mechanism in place that lets the user know that the server is not accepting its communication. This means that the application is just sitting there doing nothing waiting for valid response, which it will never get. This being said, the proposed solution to this type of problem would be to enable NetBIOS on the server which the program is connecting to or find a program that uses an alternate means of communication.

Homework

Today we have analyzed to more trace files that have given us a further understanding of more packet related troubleshooting techniques. If you manage any type of network I would be willing to bet that you have problems with spyware on occasion. This being the case, the next time you see a computer with a spyware problem, sniff it’s communication. You would be amazed to see how often various spyware applications will silently “phone home” to download updates to the infection and perform various other tasks. In the next installment of Packet School 101 we will take a look at what a trace file looks like when a computer is the target of a port scan and attempted denial of service attack.

**UPDATE**

Enjoy Packets School 101? Check out Packet School 201!

You can have online degrees from well reputed institutions all over the world. Different constraints like; money, distance etc. will no more restrict you from getting valuable IT diplomas and certifications from any online university. Demand for professionals having MS 70-290 certifications has been increasing day by day. Presently, Microsoft is offering MS 70-536 certifications for the people interesting in learning the essentials of IT and MS 70-554 is more advance certification in this field.
 

After the success of my Packet School 101 series I was approached by Gigamon Systems about doing a Podcast on the subject. The PodCast is entitled “Packet Sniffing Using Ethereal/Wireshark”. It is a really basic overview of what packet sniffing is and the Ethereal/Wireshark program itself. If you liked my previous packet analysis articles you will surely enjoy this as well. It is avaliable via the link below and also via iTunes.

http://www.gigamon.com/QuickTime.php?id=GU06071003PacketSniffingUsingEthereal

If you or your company are interesting in a podcast, webcast, or technial writing piece on Wireshark, packet sniffing, Virtual Server, or general network administration, feel free to contact me at chris@chrissanders.org.

** Disclaimer to all new readers – This blog post is VERY old and not really representative of my current work. I’ve just left it up here for historical purposes. If you are interested in learning more about packet analysis I’d reccommend reading some of my newer posts or looking at my book, Practical Packet Analysis. **

I just wanted to make a couple of quick notes before I published the next section in Packet School 101. I have been in touch with Gerald Combs, who as many of you know is the original developer of Ethereal, and he has informed me that due to copyright and legal restrictions that Ethereal HAS been rebranded as the Wireshark project. I had heard this from several sources but wanted to make sure it was legitimate before I posted anything about it. This being said, Wireshark is basically the same program as Ethereal so all of the previous tutorials I have posted should still be valid. Also, from here on out I will no longer refer to the program as Ethereal, and all of the screenshots will also reflect the Wireshark program. You can learn more about Wireshark at http://www.wireshark.org.

Also, I want to thank you guys for all of the comments anad questions you have sent. Towards the end of the series I am going to devote one whole section to nothing but questions, so keep sending them my way.

Be sure to check back in the next couple of days for Packet School 101 – Part 4!