In the previous part of this article series, I demonstrated that even a simple network capture can result in hundreds of packets that you don’t really need. I also showed how to filter out these “noise” packets so that you only see the packets that are really of interest to you. Now, I want to continue the discussion by showing you how to dissect the remaining packets so that you can view the data that they contain.

At the conclusion of the previous article, our filtered set of captured packets looked like what you see in Figure A. As I explained at the beginning of this series, I captured the data shown in the figure by starting the capture, executing a PING command, and stopping the capture. My purpose in doing so was to keep things as simple as possible. If you look at Figure A, you can actually see where the ICMP packets were transmitted, and where replies were received.

Figure A: It is usually useful to filter out unimportant packets

If this were a real life capture, there usually wouldn’t be any need to delve any deeper into the data, because you can tell exactly what is going on just by looking at the Description column. In the real world though, things are rarely this simple. Determining exactly what is going on within a trace often requires looking inside of the individual packets.

There really isn’t anything particularly meaningful that I can show you inside of an ICMP packet. That being the case, let’s take a look at some of the LDAP packets that were captured. As you probably know, LDAP stands for Light Weight Directory Access Protocol. LDAP is the protocol used to read information from and write information to the Active Directory.

There are two reasons why I want to show you how to analyze an LDAP packet. First, in real world traces of Windows networks, LDAP packets are very common. Being that LDAP packets are so common, you may find yourself needing to decipher their meaning.

The second reason why I want to show you how to look inside of an LDAP packet is because LDAP packets contain human readable data. This will make it easier for you to understand what the packet is actually doing. The techniques that I am about to show you can be used to look inside of any packet; it’s just that not every packet will be meaningful unless you happen to be a protocol expert.

Looking Inside of a Packet

Let’s begin by looking inside frame number 284. The description simply says that this frame is a search request. The fact that a machine is issuing an LDAP search request doesn’t really tell you a lot. The only way to tell what the search request consists of is to look inside of the packet.

Before you open the packet, click the icons to toggle the details pane and the hex pane on. Once all three panes are displayed, select the packet that you want to look at. When you do, you will see a screen similar to the one that’s shown in Figure B.

Figure B: This is what a packet looks like

The first thing that I want to show you is the details pane. If you look at this pane, you will notice that there are several different expandable containers (Frame, Ethernet, IP, TCP, and LDAP). The reason for the various containers is because packets are typically hierarchical in nature. The packet that we are looking at is an LDAP packet, but computers don’t natively speak LDAP. LDAP is actually based on the TCP protocol. TCP in turn is a subpart of the IP protocol. Each container in the details pane represents an individual layer of encapsulation.

If you look at the hex pane, you will see a hexadecimal representation of the individual bytes that make up the packet. Notice that each byte is highlighted in black. The reason for this is because the bytes highlighted in black correspond to the part of the packet that is selected in the details pane. In this particular case, the FRAME container is selected. This container represents the entire frame, which is why the entire frame is highlighted in black. If I were to select the LDAP container, then only the bytes corresponding to the LDAP data are highlighted in black, as shown in Figure C.

Figure C: The hex pane highlights the currently selected portion of the packet

You have probably noticed that each container is expandable. By clicking the plus sign next to a container, you can drill down further and further into the packet. It is often possible to see exactly what the packet does by looking further inside the frame. If you look closely at Figure C, you can pick out some readable words from within the ASCII representation of the hexadecimal data that is selected. However, this “readable” data tends to be rather difficult to read. Words start on one line and end on the next, and are often separated by cryptic symbols. The black highlighting also tends to make this section difficult to read, because of the strain that the contrast places on your eyes.

A better way of looking inside of the packet is to expand the LDAP portion of the packet from within the Detail pane. Expanding the LDAP container reveals that this particular packet is an LDAP search request, as shown in Figure D. This means that the packet was sent in an effort to query the Active Directory.

Figure D: Expanding the LDAP portion of the packet reveals that the packet is an LDAP search request

OK, so now we know what the packet’s purpose is, but we still don’t know what the packet is really doing. An LDAP request is an attempt to retrieve information from the Active Directory, but what information is it trying to retrieve? If you expand the LDAP: Protocol0p = SearchRequest container, you can see that one of the sub containers is labeled Attribute Description List, as shown in Figure E. If you look at the figure, you will notice that Attribute Description List corresponds to the more legible portion of data that is displayed in the hex frame.

You will also notice in the figure that the Attribute Description List container is expandable. If you expand this container, you can see that the Network Monitor displays exactly which LDAP attributes the frame is requesting data for, as shown in Figure F.

Figure F: Network Monitor displays a list of the attributes for which the LDAP query is attempting to retrieve data

Conclusion

In this article series, I have gone through the basics of using the Network Monitor. Microsoft will soon be releasing version 3 of Network Monitor, but everything that I have shown you in this article series will still work when the new version is released.

If you would like to read the previous articles in this series please go to:

Featured Links

Read Next

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Latest Podcast

Featured Freeware

Recommended

Follow Us

Working With Network Monitor (Part 5)

TECHGENIX

TechGenix reaches millions of IT Professionals every month, and has set the standard for providing free technical content through its growing family of websites, empowering them with the answers and tools that are needed to set up, configure, maintain and enhance their networks.