Chapter 9: Network Traffic Analysis

		Chapter 9 - Network Traffic Analysis Honeypots for Windows by Roger A. Grimes Apress 2005

Capturing and analyzing network traffic headed to and from your honeypot is an important part of honeypot administration. Most administrators use a network packet protocol analyzer (also called a sniffer) and an IDS to assist in their forensics investigations. Snort is the world’s most popular IDS, and Ethereal is a very popular sniffer. Since both of the tools are open source and free, we will use them as implementation examples.

This chapter will begin with an introduction to sniffers and an IDSs, and their value in a honeypot environment. Next, it covers network protocol basics, to help you understand the capabilities of IDSs and sniffers. The final sections cover Ethereal and Snort in detail.

Why Use a Sniffer and an IDS?

Sniffers are used to capture and reveal all network traffic headed to and from the honeypot. An IDS is used as a secondary sniffer and to alert the administrator when malicious activities are noticed.

Sniffer Benefits

There is a saying in the scientific world that goes something like, “There is no truth but math.” What it means is that the logical application of math will always reveal the truth behind something. It doesn’t lie. It can only reveal. For instance, many of the important scientific discoveries of the last century have been proven in math for decades before they were confirmed by experiments. This includes the speed of light, black holes, and quantum physics. The use of packet capture and analysis follows the same logic. If you want to discover what is happening on a network, or in our case, your honeynet, the only real way is to capture and analyze the traffic.

Outside the realm of honeypot administration, I have used network protocol analysis to solve many stubborn problems—the ones no one else can seem to figure out. While different vendors are pointing fingers at each other over the “unsolvable” problem, I can capture network traffic at its source and reveal the truth. Network administrators with packet-analyzing experience are always good network engineers. They understand how networks really work, beyond the veil of theoretical discussion.

Network protocol analyzers excel at catching all network communication data streams headed to and from the honeypot. Using the captured data, you can completely reconstruct what hackers did to the honeypot, assuming they aren’t encrypting the traffic. Whereas an IDS might alert and capture only the specific packet related to a malicious attempt, a sniffer utility should be catching and storing everything, from beginning to end. Most hackers aren’t lucky enough to be successful in their first attempt. They usually probe the machine first, looking for signs of weaknesses and scoping out potentially vulnerable services.

A network sniffer should be catching everything, but an IDS’s main job is locating malicious activity. An IDS might catch only the actual buffer overflow in action, whereas the protocol analyzer would catch all the hacker’s probes and exploits from the beginning.

A protocol analyzer shows each network packet, in detail. You can study the packets, look at the protocols and port numbers being used, and see the payload data. You’ll be able to see buffer overflow exploits, transmitted files, password attempts, and literally anything else the hacker throws at your honeypot. With some assistance from tools known as packet injectors, you can even replay the packets across the network, exactly duplicating the hackers’ actions and see the results. If you ever plan to prosecute a hacker, you should make sure you capture all traffic headed to and from your honeypot, rotate the logs on a regular basis, and save them to permanent write-once media for evidence.

Note 

Packet injectors are programs that can build custom packet traffic and place it on the network. Injectors are used legitimately to test networks and by malicious hackers for more treacherous purposes.

There are dozens of network protocol analyzers to choose from, including Ethereal, Network General’s Sniffer, NetXray, tcpdump, Novell’s LANalyzer, Microsoft’s Network Monitor, Sun Snoop, and AIX’s IPTrace.

OSI MODELS WITHIN OSI MODELS

I remember my first surprise at seeing UDP traffic resend transmissions when packets were lost or corrupted. Having heard how UDP is stateless and unreliable for so many years, I had no idea how UDP was accomplishing retransmissions on a noisy network line. That’s when I learned that the upper-layer application was verifying data and asking the source to retransmit corrupted data. UDP itself wasn’t doing the error checking and retransmission, but a lot of other layers usually prevent it from being the unreliable protocol that it is made out to be in books. This will explain why none of the UDP applications that you use ever seem to be missing data.

I was similarly surprised when watching network traffic flow off a cable provider’s 10 Mbps Ethernet WAN link. When using a WAN protocol analyzer, I learned that our WAN link provider was using ATM over a SONET backbone to deliver 10 Mbps Ethernet LAN traffic between two of our metropolitan locations.

SONET is a worldwide standard for transmitting high-speed optical data between two points. It uses 810-byte frames. SONET frames will often hold ATM frames, which are smaller 53-byte frames. Once on the LAN, the SONET frames are converted to LAN-based frames and converted into larger Ethernet frames with a maximum transmission unit (MTU) size of 1500 bytes. There are packets encapsulated in other types of packets, each with its own complete OSI layer model.

All the wrapping, splitting, and splicing to deliver data from one computer to another happens in nanoseconds on a typical WAN link. Each OSI layer of network packets existed only to transport the packet across its logical network, where at the endpoint, all the other packets were stripped away, and my network was handed ordinary Ethernet packets.

Getting involved with network protocol analysis revealed to me that there can be multiple OSI models inside other OSI models, when describing how data gets from point A to point B. This is all quite interesting, and similar to the Russian nesting (matryoshka) dolls.

IDS Benefits

Most honeypot administrators run an IDS, like Snort, because it will document and alert them to when specific threats to their honeypot are noted. If the attacker is trying to run a buffer overflow that the IDS recognizes, the IDS can document the attack and its data to a log and send an alert to the administrator.

Since any traffic to a honeypot should be considered malicious by default, the administrator needs to know when any traffic hits it. But, in most instances, a honeypot will not be under constant attack. It’s usually days of waiting for something exciting and out of the norm to happen, followed by a few intense hours. But when an attacker does strike, it’s important that the event and its data be logged and the administrator alerted.

Most IDSs have a flexible alerting feature that lets administrators define how they wish to be notified. Some honeypot administrators wait for console network messages; others prefer SMTP mail messages. The most common alerting mechanism is for the alert to be sent to a cell phone or beeper. Because most cell phones and beepers can be sent messages over the Internet, it is usually trivial to configure the IDS to send a short message when the honeypot is touched.

Most attacks are automated worms and scripts, and they should be recognized as that. To be honest, once you’ve seen the same worm or script a few times, it becomes uninteresting. It’s almost as important for the IDS to tell you when the attack is old and known as it is for you to find out about new attacks (that the IDS doesn’t recognize). Older, recognized attacks can be filtered out, or maybe logged without alerting the administrator. Newer attacks should definitely generate alerts, so the administrator can respond and ensure that the attack is being contained to the honeypot.

How a Sniffer and IDS Complement Each Other

When a known attack is finally launched, the IDS should send an alert. Most sniffers can do the same thing; that is, they can send an alert based on some predefined packet content that they find. But sniffers usually let you define only one (or a few) patterns at a time, and you would need to decode what the signature meant and how to respond. IDSs are built for that kind of work. The trick is to use both tools at the same time and let the strengths of each of them build a more complete picture of the intruder.

When the attack isn’t previously recognized, you can capture it with the sniffer (or IDS), create a new signature, and make the IDS recognize it if it happens again. Second-generation honeypots are also placing IDSs inline, where they can redirect potentially malicious traffic away from production resources and toward the waiting honeypots, or even manipulate outgoing malicious traffic in order to deceive the hacker. This latter technique is just starting to be used and shows great promise for the future.

Whatever your honeypot environment is, make sure it has both a network sniffer and an IDS.

Where to Place the Sniffer and IDS

As covered in Chapter 2, monitoring tools should be placed in such a way as to not alert the hacker.

To review, the best way to keep these monitoring programs hidden is to use a port mirroring switch (see Figures 2-4 and 2-7 in Chapter 2). The honeypot plugs into one of the switch’s normal ports. The monitoring workstation, containing both the sniffer and IDS, is plugged into the management port on the switch receiving the mirrored traffic. Using this configuration makes it considerably more difficult for the intruder to suspect something is up.