Dive into Network Monitor

Network Monitor is a component of the Windows Server OSs and Microsoft Systems Management Server (SMS) that lets you monitor network traffic as it crosses the wire. By using Network Monitor, you can monitor network traffic in real time or capture and store packets for later analysis. You can use the information that Network Monitor captures to troubleshoot problems on LANs, WANs, and virtually any device that uses TCP/IP to communicate. Network Monitor has three primary uses:

Installing Network Monitor
To use Network Monitor, you must have a NIC that supports promiscuous mode installed in the server that's running SMS or Network Monitor. (Most NICs support promiscuous mode.) Network Monitor isn't installed by default unless you explicitly selected it when you installed Windows Server 2003 or Windows 2000 Server. To install the version of Network Monitor that's included in Windows 2003 or Win2K Server, perform these steps:

Starting Network Monitor
After you've installed Network Monitor, you're ready to start the utility. Click Start, Programs, Administrative Tools, Network Monitor. (Alternatively, you can run Network Monitor from the command line or use a batch file to automate packet captures.) You'll see the initial Network Monitor screen. To start capturing packets, click the Capture button. After Network Monitor starts capturing packets, the Network Monitor window will look similar to the window in Figure 1. As you can see, Network Monitor's main window consists of four panes that display different types of information.

Network utilization bar graphs. The first pane (pane 1, red frame) contains a bar graph that displays traffic statistics on your server. The first bar—% Network Utilization—is the most important one. If your server is on a shared segment with other computers and your network utilization exceeds roughly 35 percent, the server could have a serious network bottleneck. Ethernet uses the Carrier Sensing Multiple Access with Collision (CSMA/CD) protocol, which detects collisions. On a nonswitched Ethernet network, network utilization above 35 percent generates numerous collisions, which dramatically decrease throughput. If you're experiencing high network utilization, consider installing an Ethernet switch to increase throughput.

If your server is connected to a dedicated switch port, network utilization can go much higher without producing network delays. However, if your network utilization averages above 80 percent, consider installing a NIC with dual ports or upgrading the backbone to Gigabit Ethernet or 10 Gigabit Ethernet. If you have many broadcasts or multicasts, or both, per second (i.e., more than 50), you could have a beaconing NIC or just many computers that issue broadcasts. It's a good idea to gather network traffic statistics before you have a problem, so that you have a baseline by which to compare your current network traffic with historical network traffic patterns.

Network connections. The second pane (pane 2, blue frame) displays a list of devices with which the server is communicating. The names in the Network Address 1 column are either the names of Network Monitor­supported NICs that are in use on your network or unsupported NICs' Media Access Control (MAC) addresses. (To display a list of NICs on your network, select Options, Show Vendor Names.) The 1->2 column displays the number of packets sent to the device in Network Address 2, and the 1

Network statistics. The third pane (pane 3, green frame) displays statistics about the current network packet trap. If you plan to capture packets for longer than 1 minute, you might have to increase the capture-buffer size, otherwise you'll start to lose packets in the capture buffer. The default capture-buffer size is only 1MB, which can fill up almost instantly on a busy network. When the buffer is full, the oldest packets are discarded and replaced with new packets. To modify the buffer size, select Capture, Buffer Settings and change the buffer-size setting. Don't set a buffer size that's greater than the amount of available physical memory, or you might drop frames because of page-file swapping.

Detailed network packet information. The fourth pane (pane 4, yellow frame) displays detailed information about the number and type of frames sent to or received from each device. If an unusually large number of bytes are sent to or received from a particular device, the device might be faulty or simply transferring a large amount of data across the network.

You can set a capture filter by selecting Capture, Filter, then setting parameters for the capture filter. A filter lets you trap packets according to specific protocols, network addresses, or text-pattern matches. It also reduces the size of the capture buffer, which can be helpful on busy networks. If you're new to Network Monitor, I suggest that you don't use the capture filter until you're very familiar with the type of traffic on your network. It's easy to accidentally filter out the exact data you're looking for by setting a capture filter that's too restrictive. If you want to filter out traffic, I suggest using the display filter (which I explain a bit later) after you've completed your network capture to hide any unwanted packets.

Displaying Captured Packets
After you've captured the amount of data that you want, click the stop and view icon (circled in red in Figure 2) to stop and view the packet capture. Figure 2 shows the results of a packet capture. The capture summary displays several columns, which Table 1 defines.

Double-clicking a frame lets you view detailed information for that specific packet, as Figure 3, shows. The top pane displays a summary of captured packets. The middle pane displays detailed information about the packet that's highlighted in the top pane. The bottom pane displays the raw packet information in hexadecimal format. When you click the detailed information in the middle pane, the bottom pane highlights where the information is coming from in the packet. In the middle pane, you can click any plus (+) sign to display additional detail. The middle pane consists of the following information:

Setting Display Filters
After you capture packets, you can use Network Monitor's display filter to display only packets that meet certain criteria. To set a filter, select Display, Filter and enter any necessary conditions. You can filter by address, protocol, or protocol property. For example, to set a filter that displays only undocumented header packets for HTTP packets, follow these steps:

TCP/IP Session Basics
The "lite" version of Network Monitor captures broadcast packets and network traffic that's sent to or received from the server on which Network Monitor is installed. If you've ever examined your firewall log, you'll see that Network Monitor captures similar information but in much greater detail. A Network Monitor packet capture can be a little intimidating the first time you inspect one. (The first time I reviewed a packet capture, my initial thought was, "What the heck am I looking at?") To ease the shock of interpreting a packet capture, it's helpful to know what to look for and what you're looking at. But before we learn how to read a packet capture, a basic understanding of a TCP/IP session is in order. At a very basic level, a TCP/IP session includes the following components:

Reading Packet Captures
As you know, network traffic is broken up into packets before it's sent across the network. Most packets on your network are typically TCP; however, you can also have other types of packets, such as DNS, ICMP, NetBIOS over TCPIP (NBT), and UDP. Each packet contains a TCP flag in the packet's header section as well as other flags, which are listed below in the order in which they appear in the header.

Flags to watch. Most networks should have traffic that consists mostly of ACK and PSH packets. Unless the server is constantly establishing new sessions, you should see relatively few SYN packets. Servers that experience a large number of SYN packets could be under some type of DoS attack (aka a SYN flood). The number of FIN packets should be roughly equal to the number of SYN packets. You should see few RST packets. A high number of RST packets is a possible symptom of an intermittent network connection, beaconing NIC, high network traffic, faulty network switch or hub, or another type of hardware failure.

Port numbers. As you know, most TCP/IP packets identify a source and a destination port. When you read the packet information, make a note of the source and destination ports on the server. You should also become familiar with well-known ports and the ports that Windows uses. If you notice an unfamiliar port in a capture, it could be a symptom of hacking activity. Table 2 lists some commonly used ports.

After you run a packet capture, you can use the display filter to filter the packet capture for a specific protocol. For example, if you're troubleshooting an HTTP connection problem, use Network Monitor to capture the network packets, then set a filter only on HTTP packets (port 80) to troubleshoot specific HTTP communication problems.

Retransmissions. You can use Network Monitor to troubleshoot connectivity problems. Look for reset, or retransmission, packets (i.e., packets that contain the R flag in the packet header) that have increasing timeout lengths, with static sequence numbers in multiple packets. Retransmissions occur when a transmission between two computers is interrupted for any reason—for example, because of failed hardware or WAN delays. When a retransmission occurs, the timeout value is doubled until the retransmission is attempted 5 times (the default value). Figure 4 shows a capture that occurred when a network cable on the client was disconnected during an FTP file transfer. Frame numbers 834­992 (left column in the top pane) have the same sequence value in each packet, which indicates a connectivity problem. Frames 1172­1385 also share the same sequence number. With normal FTP traffic, the sequence number in each packet should increase, not stay the same. Notice that it took a total of 10 packets to abort the FTP transmission—5 retransmission attempts on the FTP transfer itself, and 5 retransmission attempts to close the connection. Look at the timestamp of 77.012668 in frame 834. The time difference between packet 834 and 845 (77.668893 - 77.012668) is 0.656225. The time difference between packets 845 and 868 is 1.312449, which is twice as long as 0.656225. For each successive packet, the time values double until the maximum retry value (in this case, 5) is reached.

On a slow WAN link or other line with a large variance in connection speed, you might have to increase the maximum retry number. To change this value, on the server running Network Monitor, navigate to the registry subkey HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters and add the DWORD entry TcpMaxDataRetransmissions. Set the value to decimal and change the value to a number larger than 5.

A packet trace can tell you the "best" value for your environment. For example, if you're experiencing a timeout problem caused by multiple retransmissions, increase TcpMaxDataRetransmissions to a fairly high value (e.g., 20) and see how many connections can recover from retransmission packets. If you notice that most FTP sessions can recover within, say, 8 packet retransmissions, you can set TcpMaxDataRetransmissions on your server to 9. This value lets the server time out if the WAN is down but attempt a reconnection with the client if the connection is still alive.

The timeout value for any session is initially set to 3 seconds, then is adjusted based on the connection speed. Our sample connection was on a LAN, so the first connection retry time was relatively short—0.65 seconds. On a slow WAN link, increasing the maximum retransmissions can cause the server to take a long time before it times out. For a slow WAN connection that starts with an initial retry value of 5 seconds, how long would it take for a connection to time out, assuming that the maximum-retransmissions value was 6? The answer is 315 seconds (5 + 10 + 20 + 40 + 80 + 160), or more than 5 minutes.

Using Network Monitor to Head Off an AUTH Attack
One practical use for Network Monitor is to obtain detailed information about the packets traveling to and from your server when you suspect the server is under attack. For example, you might be familiar with the type of attack by which a spammer bombards an Exchange server with SMTP AUTH commands until the spammer successfully logs on to the server. By default, Microsoft Exchange Server 2003 and Microsoft Exchange 2000 Server let a mail server relay messages if the sender can authenticate with a valid username and password. A spammer obtains a valid user ID and password by performing a brute-force attack against your mail server or launching some type of attack against your network. You can turn on Exchange's Diagnostics Logging and set the maximum value for MSExchangeTransport Categories, which will show you the user ID that was used to authenticate to the server. However, the Microsoft Management Console (MMC) Event Viewer snap-in doesn't usually display the spammer's IP address. You can obtain the address by performing a packet trap, as follows:

Find the username. In case you're wondering, the next command string in the TCP data field should have the username and password that was used to authenticate to the server. However, these values are Base64 encoded, so you'll need to use a Base64 coder/decoder to decode them. Many Base64 coders/decoders are available on the Web—such as the one at http://www.dillfrog.com/tools/base-64_encode. (For practice, try using the Dillfrog decoder to decode the user ID c3BhbW1lcg

and the password cmVsYXk= . The decoded answers appear at the end of the article.) Of course, as I mentioned earlier, you can also increase the level of diagnostic logging on the Exchange server to view the user ID that was used to authenticate to your server.

Armed for Network Troubleshooting
Network Monitor is a handy network troubleshooting tool, but it requires some training and skill to obtain the greatest benefit. Become familiar with Network Monitor and the traffic on your network before you have an emergency, so that you can establish some network baselines and not have to fight a learning curve under stressful conditions. Network Monitor and other third-party network sniffers require expertise to quickly find and resolve problems. Get up to speed now to make the most of Network Monitor's capabilities.

Answers to decoding examples:
c3BhbW1lcg spammer
cmVsYXk= relay