Managing Security with Snort & IDS Tools

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This book is about building a network-based intrusion detection system (NIDS) based on the open source application called Snort. Snort got a modest start as the open source project of a software engineer names Martin Roesch (who incidentally was the lead engineer in the development of an IDS solution for GTE). Snort is now a high-performance, full-featured solution that provides competition for some very expensive commercial solutions (and surpasses many).

A context for the use of an NIDS solution is established by examining the challenges confronting a network administrator with regards to security. New technologies are making it easier for remote users and partners to access the insides of the network, bypassing perimeter security entirely. A new breed of Internet worm is attacking from a variety of directions—through email, across the network, and even across virtual private network (VPN) connections. Hacker communities are creating tools that make attacking a network much easier. This gives rise to "script kiddies," who download an attack tool and penetrate an organization's network—all without knowing how the tool they are using works or the effect it will have on the target system.

In the old days (two years ago or so), a firewall was most of what an administrator needed to protect a network from attack. It was easy to establish where your network ended and the Internet began. Technological advances and decreasing costs for wide area network technologies have eroded this concept of a perimeter. VPNs have all but replaced conventional dial-up modem pools. Most users have high-speed DSL or Cable Modem service, and the VPN makes the user feel like he's sitting at his desk. Some VPNs use an appliance that sits on the perimeter of the network and has the capability of controlling how the network is used remotely. While this is a boon for telecommuters, it is a real risk for most networks. A virus or worm-infected system on the user's home network suddenly has unfettered access to the inside of your network. That high-speed highway into your network can allow rapid propagation of an aggressive worm.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the old days (two years ago or so), a firewall was most of what an administrator needed to protect a network from attack. It was easy to establish where your network ended and the Internet began. Technological advances and decreasing costs for wide area network technologies have eroded this concept of a perimeter. VPNs have all but replaced conventional dial-up modem pools. Most users have high-speed DSL or Cable Modem service, and the VPN makes the user feel like he's sitting at his desk. Some VPNs use an appliance that sits on the perimeter of the network and has the capability of controlling how the network is used remotely. While this is a boon for telecommuters, it is a real risk for most networks. A virus or worm-infected system on the user's home network suddenly has unfettered access to the inside of your network. That high-speed highway into your network can allow rapid propagation of an aggressive worm.

Connections to business partners used to be an expensive proposition and were only for the most well-to-do organizations. Dedicated T1 links are expensive. With less expensive network options (not to mention network-to-network VPN connections), this cost has decreased significantly. This allows many organizations to connect their network to yours—sometimes directly into the internal network. Without real precautions in place, security problems on the partner networks quickly become security problems on your network—very often undetected until much damage is done. Whether you trust your partner to that extent is another matter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When deploying troops in a theater of war, a general has to consider all the ways an enemy may attack: by land (either at the front line, or a commando raid behind the lines), by sea (surface ships or submarines), or by air (helicopters, fighters, bombers, missiles, or artillery). The general has to deploy defenses against all potential vectors of attack. He doesn't just trust the trenches at the front line for all his security. He will deploy troops to the front line, as well as at high-value assets behind the lines. He will deploy a variety of anti-submarine and anti-surface ship defenses. He will deploy a variety of anti-air assets to protect against the various air threats. This concept of multiple overlapping defensive measures is known as defense-in-depth .

A similar system can be applied to network security. Instead of trusting the eroding value of perimeter defenses (firewalls) for all of our security, we turn to other mechanisms. We configure systems according to industry-accepted best practices (disable unnecessary services, keep software updated, run antivirus software). We establish a system to securely aggregate our system logs in one place (and we monitor those logs for anomalies). We segregate our network to control access to important machines and to "wall-off" partner and remote connections. We utilize strong authentication and authorization practices. And finally, we take steps to detect and prevent intrusions (preferably attempted intrusions) on our network and on our systems. We also try to do this with limited budgets and limited time. In the real world, the general is trying to protect against lost real estate. In the network world, the administrator is protecting against downtime and data loss. I won't beat the analogy to death. The main thing to remember is not to trust a single component of your security framework for all your security. If you are able to, apply security as close to the thing you are trying to secure as possible. These steps will help you stop at least 80% of attacks. Intrusion detection should catch the remaining 20%.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Intrusion detection is simply trying to detect the signs of a network intruder before damage is done, a service denied, or data lost. This can be done through the use of a variety of mechanisms. Properly configured systems generate system logs that keep track of services, users, and data. These logs very often show traces of suspicious (or downright nefarious) activity. The problem is that these logs often have a lot more information in them than a security administrator is interested in. It is important to consider system log review as a basic intrusion detection mechanism, though. Many times the system logs show their value in a forensic analysis after the fact.

The next layer of intrusion detection (and prevention) is automated tools, commonly referred to as host-based intrusion detection (HIDS). HIDS tools include antivirus software, personal firewalls, NIDS installed on the individual hosts, and a new breed of software (intrusion prevention systems) that protects system memory against buffer overflow attacks or enforces security policies. Many products are a hybrid mix of these solutions (a personal firewall/antivirus product, for example).

The final layer of intrusion detection is NIDS.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

On a basic level, network intrusion detection is exactly what it sounds like: the process of determining when unauthorized people are attempting to break into your network. Keeping those attackers out or extracting them from the network once they've gotten in is a different problem. Obviously, keeping intruders out of your network is a meaningless task if you don't know when they're breaking in.

Detecting unauthorized connections is a good start, but it is not the whole story. Network intrusion detection systems like Snort are great at detecting attempts to login to your system, access unprotected network shares, and things like that. But there are other kinds of intrusion that are not as clear-cut as an outsider walking past the receptionist at the front desk and sitting down at a computer. Is a denial of service attack—one that operates by sending a carefully crafted sequence of packets to a network server and ultimately crashing it—an intrusion? No one has literally gained access to your machine's physical resources. However, bandwidth, CPU time, and hard-drive space on your IDS are all consumed by the attack. Denial of service is considered a successful attack because it occupies resources that would have been employed somewhere else. Does someone probing your networks with port scans or pings constitute an intrusion? Perhaps not, but it is a sign that she may soon start doing something more hostile. So we also consider probing an intrusion, and expect our intrusion detection system to warn us whenever things such as these happen.

Generally speaking, an intrusion detection system like Snort scans network traffic looking for suspicious activity based on the signatures of bad packets. You are probably already familiar with tools like tcpdump and ethereal, which display all the traffic flowing on your network within a specific subnet. An intrusion detection system is essentially an automated tcpdump, a packet sniffer that sniffs in the background and does not require you to watch or analyze the traffic yourself. Tools like ethereal work well for debugging; for instance, when you have to look at each packet to figure out what might be wrong. But on any real network, there is just too much traffic to watch for suspicious activity. That is what computers are good for: doing a very boring job repetitively, and alerting you when something interesting comes along.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The benefits of detecting an intrusion as early as possible are undeniable. But it is important to deploy an IDS with realistic expectations. There are some real challenges in installing, maintaining, and interpreting the output from an intrusion detection system.

A potential intrusion detection administrator needs a good knowledge of the environment into which she is introducing NIDS. What is the network layout? This information helps determine the positioning of the sensors and also may help determine which mode of operation should be used. What kinds of systems are in the environment? Windows? Unix? What services are the systems providing? Email? Web services? How is encryption used in the environment?

A good understanding of how systems communicate on the network is very important in interpreting the output of the NIDS sensors. Without knowing the makeup of a TCP packet, an alert specifying a problem within a packet will only cause confusion. If you are not familiar with network sniffing tools like tcpdump and ethereal, spend some time watching the traffic on your network. Review the contents of Chapter 2 to help you interpret the results. Only good can come from this time spent watching and learning how things talk and move around your network. Without this background, the job of determining what is really something to worry about—as well as tuning out unneeded rules and features—is very difficult.

Very often (and especially before tuning), when Snort sends you a warning that something suspicious is happening, there is nothing really serious going on. Any NIDS is going to generate a lot of false positives, warnings that someone or something is launching some form of attack, when in fact nothing is happening. You may be able to minimize false positives, but you cannot entirely eliminate them. Furthermore, the more false positives you receive, the more likely it is that Snort is missing an actual attack or subversive intrusion attempt. It is up to you to figure out an acceptable level of risk. Do you really want to be notified about every port scan? About every unauthorized attempt to mount a Windows share? Even on a home network this can quickly drive most sane administrators crazy.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Snort represents a cost-effective and robust NIDS solution that fits the needs of many organizations. This book should be all you need to get Snort installed, configured, tuned, and alerting accurately in your environment. Snort is covered from initial configuration to ongoing maintenance. Strategies are revealed to make Snort useful for a home office or a large corporation with a dedicated and experienced network security staff. The approach is one of attempting to derive reasonable approaches to the issues at hand. I try hard not to be a zealot.

Snort does not stand by itself as the beginning and end of a security framework for an organization. It is part of an overall defense-in-depth strategy that incorporates security in all aspects of a network. Whether Snort is an important and significant contributor relies on strong planning and an ongoing dedication to the care and feeding of your NIDS.

There are a wide variety of choices in the area of intrusion detection. Digging through the propaganda generated by the various marketing departments is not easy. Even the definition of intrusion detection is murky, often moving from one solution to another. To cut through the noise, consider the following:

Cost: Open source software is hard to beat on price. To be sure, very often such software can be more difficult to operate. Snort is one of the more mature open source packages out there and competes with any commercial product for return on investment. There is the occasional C-level executive that will throw out an open source solution because there is no one to call when it breaks. With mainstream acceptance of open source solutions increasing constantly, this is less often a problem. For those who cling to this thinking, there are several commercial products that use Snort as their core technology. Chief among these is Sourcefire, an organization at the forefront of Snort development and implementation. Sourcefire was started by a fellow named Martin Roesch, now the CTO (does that name sound familiar?).
Stability, speed, and robustness: Since very early on, one of the main goals of Snort's developers was to keep it lightweight, fast, and lean, in order to keep up with ever-increasing network bandwidths. Since it is not a new solution, bugs are virtually nonexistent. A Snort instance crashing is almost unheard of. I personally have a Snort installation that watches sustained 450 Mbps of bandwidth using a cluster of six sensors. The only time Snort is down is during a planned maintenance window to upgrade signatures or move to a new version. This demonstrates not only Snort's stability, but also its ability to be adapted to very demanding environments (see Chapter 13).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Snort's homepage	`http://www.snort.org`
SecurityFocus IDS Page	`http://www.securityfocus.com/ids`
The SANS Institute	`http://www.sans.org`
CERT homepage	`http://www.cert.org`
The NSA Security Guides	`http://www.nsa.gov/snac/index.cfm`
tcpdump homepage	`http://www.tcpdump.org`
ethereal homepage	`http://www.ethereal.com`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A network IDS is really just a network sniffer that compares the contents of packets of information traveling the wire to a catalog of signatures that indicate potential malicious activity. A sniffer is a device (formerly very expensive, special-built systems, but now a simple laptop) with a network card that watches traffic between computers and other network-capable devices. This device can do a number of things with this traffic: record, sort, or analyze it.

Because most network security and intrusion detection is based on identifying and interpreting packet data, it's important to understand how a packet is constructed and how it performs in real-world scenarios. In most cases, you can trust intrusion detection tools such as Snort and their alerts regarding suspicious packets, but there are times when the packet payload must be examined a person rather than a computer program. A careful analysis of a packet is sometimes required to determine if an alert is in fact a real alert or a red herring. Not knowing at least the basics of how computers use the network to communicate makes this task much harder, if not impossible.

This chapter starts with some level-setting discussions about how networks are used by systems to communicate using the TCP/IP suite of protocols. We'll cover the TCP/IP suite in general and concentrate on TCP in particular. While looking at TCP, we will break down the structure of an individual TCP packet, looking at the different options available. We will then examine the very important concept of the three-way handshake. This will be a quick survey of TCP/IP networking and is not meant to be a comprehensive education. The goal is to give you the tools you need to interpret what your IDS sensors are telling you.

One of the main tools used to capture and analyze network traffic is an open source tool called tcpdump . tcpdump is one of the most common tools for learning the basics of interpreting packets. It's easy to install on a number of platforms, freely available, runs on both Unix-based and Windows systems, and it's very flexible. I explain how to install and properly configure tcpdump and examine the basic usage of tcpdump as a teaching tool and a security application. I then look at

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

TCP/IP (Transmission Control Protocol/Internet Protocol) is a suite of network protocols. TCP and IP are only two of the protocols within the suite but arguably the most important. The TCP/IP protocols were designed to allow different applications on dissimilar operating systems to communicate across a network. I'll talk about some (certainly not all) of the TCP/IP protocols in the context of intrusion detection.

TCP (Transmission Control Protocol) is a connection-oriented transport layer protocol designed to provide a reliable connection for data exchange between two systems. TCP ensures that all packets are properly sequenced and acknowledged, and that a conversation is established before data is sent. This ensures that both machines are ready to have a conversation and that the information moving from one system to another makes it without anything being lost. Services using TCP as their communication mechanism listen on specific port numbers for clients to make requests. Some applications that make use of TCP as their method of communication are:

Virtual Terminal Protocol (Telnet port 23)
File Transfer Protocol (FTP ports 20 and 21)
Simple Mail Transfer Protocol (SMTP port 25)
Secure Shell (SSH port 23)

TCP provides its reliability through the use of an acknowledgment (network geeks call this an ACK). An ACK is returned by a receiving machine to a sending machine to tell the sender that the message that was sent was received without error. If the sender does not receive an ACK, it resends the message.

If a receiving machine needed to send an ACK for every packet, it would result in incredible overhead for the system and the network. To reduce the overhead, a mechanism called windowing is used. The receiving system advertises a certain number of packets it can receive at a time (essentially an input buffer size). The sending system watches for an ACK after the designated number of packets is sent. If an ACK is not received, data will be retransmitted from the point of the last ACK. If the receiving machine has trouble keeping up with the inflow of packets, it reduces the window size. If the machine is really getting hammered, it advertises a window size of zero and the sender stops transmission until an ACK with a nonzero window value is received.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A network packet is nothing more than a chunk of data that an application wants to deliver to another system on the network. This chunk of data has information added to the front and back that contains instructions for where the data needs to go and what the destination system should do with it once it arrives. The addition of this routing and usage information is called encapsulation .

The TCP/IP model uses four layers of encapsulation, also referred to as a stack or an IP stack . A packet is something like Russian Matroishka or "nesting" dolls: painted wooden figurines that hold smaller versions of themselves. Each doll is slightly smaller than the parent into which it is placed. The smallest doll, which cannot be opened, is the actual application data. Each larger, enclosing doll represents the header data affixed to the original content. The insertion and removal of each layer of a Matroishka doll is equal to a network-level header being added or removed from a packet.

Figure 2-2 illustrates the process. We start with a chunk of application data, to which we add a header. We take that data (application data plus application header) and package it up as a series of TCP segments by adding TCP headers. We then add an IP header to each TCP segment, making IP datagrams. Finally, we add Ethernet headers and trailers to the IP datagrams, making an Ethernet frame that we can send over the wire. Each layer has its own function: TCP (the transport layer) makes sure data gets from point A to point B reliably and in order; IP (the network layer) handles routing, based on IP addresses and should be familiar to you; and Ethernet (the link layer) adds low-level MAC (media access control) addresses that specify actual physical devices. It's also important to note that there are several choices at each layer of the model: at the transport layer, you can see either TCP, UDP, or ICMP. Each layer of the network stack is unaware of the layers above and below. The information coming from the layers above are simply treated as data to be encapsulated. Many application protocols can be packed into TCP. When the packet is received at its final destination, the same process is repeated in reverse. The packet is de-encapsulated and the headers stripped off when it is received by the intended target.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of the most important techniques covered in this book is how to sniff or capture network packets for closer analysis. tcpdump extracts packets traversing the network and either displays them in real-time—a term open to interpretation and highly dependent on network bandwidth speed—or else tcpdump logs the packets to the system for later analysis. This process is called packet sniffing . Understanding a packet's basic composition can give a preliminary indication of whether a packet is good or bad—whether it is benign and should be logged or simply ignored, or flagged and the administrator alerted.

In normal network operations, a Network Interface Card (NIC) receives only traffic addressed to it. The card sees all the traffic on the wire; it just passes traffic destined for itself on to the operating system. In order to sniff packets on the network, the network device must first be able to see all packets passing through. To support packet analysis, most network interfaces provide a promiscuous mode . Promiscuous mode "tells" the NIC to pass all the packets it sees on the wire to the network driver, even if they are not directed to the local system. However, before you can start looking at the packets rushing by your NIC, you must think a bit about your network. If your network uses switches (or even dual-speed hubs), you still won't see all the traffic. A switch sends each node only the packets that are addressed to it. Promiscuous mode doesn't help, because your NIC never gets to see the packets. The solution is to enable port monitoring (called a SPAN port in the Cisco world) on the switch, or (as a temporary measure), replace the switch with a hub.

Promiscuous mode on a network interface card is not a bad thing unless it is enabled on a machine that is normally not permitted to sniff packets. Be wary of any machine that has promiscuous mode drivers enabled and is actively checking network packets. A tool such as SniffDet is useful for tracking down machines that are running in promiscuous mode or capturing and logging packets. Promiscuous machines may indicate that a cracker is already inside your network and looking for sensitive data or passwords within those packets. If you closely manage network security, no one should be sniffing packets without your approval.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The tcpdump application may already be installed on your Linux distribution. tcpdump requires the libpcap library, which in all likelihood is also already installed as an RPM package. libpcap is the basis of all packet-sniffing applications. This library provides a portable framework for low-level network monitoring. Besides packet sniffing, it is used for network statistics collection, security monitoring, and network debugging. Most hardcore security administrators prefer downloading the latest source, verifying the PGP signature, and compiling and installing them manually. If tcpdump and libpcap are not already installed, compile both programs from source. Even if you already have the RPM version, consider installing the latest version using the source code. The latest versions very often have much better performance and stability than the pre-installed binaries. Simply uninstall the preinstalled versions of libpcap and tcpdump and proceed. As an example, if your distribution uses RPM packages, you can remove tcpdump by using the following command line:

# rpm -e tcpdump

After copying the compressed files to a standard location, such as /usr/local/src/, uncompress the code. Here is an example install:

# cp tcpdump-3.8.1.tar.gz /usr/local/src/
# cp libpcap-0.8.1.tar.gz /usr/local/src/
# cd /usr/local/src
# tar -zxvf tcpdump-3.8.1.tar.gz
# tar -zxvf libpcap-0.8.1.tar.gz

Replace the version number (as shown above) with the latest release number. The commands for installing both applications are covered in the INSTALL files included with each application's source code. These are fairly standard and do not require much modification. You may add other configuration options to the install process. To view these options, use the --help flag following the configure command. In most cases, though, you won't need any options. Here's how to install libpcap and tcpdump from source:

# cd libpcap-0.8.1
# ./configure ; make ; make install
# cd ../tcpdump-3.8.1
# ./configure ; make ; make install

Rather than use a semicolon to separate multiple commands on the same line, some developers recommend &&. With &&, a command is executed only if prior commands succeed. If something fails during the configuration or

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The most effective way to start learning about network packet formation is to study some examples. tcpdump operates by capturing packets from a network connection. The output is displayed in a standard format understandable by other network sniffing applications. Here's some captured data, as seen by tcpdump:

07:00:48.036746 ping.net > myhost.com: icmp echo request (DF)
07:00:48.036776 myhost.com > ping.net: icmp: echo reply (DF)
07:02:12.622460 log.net.3155 > syslog.com.514: udp 101
07:03:01.132414 send.net.32938 > mail.com.25 S 248631:248631(0) win 8760

tcpdump prints more (verbose) information about the sniffed traffic with the -v option, and prints its output in hexadecimal with -x. It can also write the "raw packets" to a file using -w rather than sending them to standard output or to the console. Writing the contents to a file is extremely useful when you only have command-line access to a sniffer but want to dump the capture to a file for later analysis (or analysis by another tool). tcpdump filters assist in specifying data-only traffic on a particular port, such as port 22, or by using a specific protocol such as UDP, instead of collecting all data and filling up the logs. These filters are applied directly within the kernel, so no circular copying to the user space is needed.

In some cases, tcpdump resolves the port number to a particular service. For example, port 21, in some instances, is resolved to "ftp". Check the /etc/services file for more information regarding the port number and the actual service.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The more data collected by tcpdump, the clearer the content of the network traffic stream becomes. Here is another example of a tcpdump capture:

14:02:09.181190 specto.ksl.com.33248 > quasi.ksl.com.ftp: S 1191864640:1191864640(0) 
win 5840 <mss 1460,sackOK,timestamp 238617 0,nop,wscale 0> (DF)

Here's what each field in this output means:

14:02:09.181190: Timestamp
specto.ksl.com.33248: Hostname and source port
quasi.ksl.com.ftp: Hostname and destination port (translated to FTP)
S: First character of the TCP flag: PSH, RST, SYN, FIN (the ACK flag is shown somewhere else)
1191864640: Initial sequence number from source
1191864640: Ending sequence number, which is the initial sequence number plus the size of the packet in data bytes
(0): Data bytes or payload size of this TCP packet
win 5840: Size of the receiving data window

The data within the < and > characters are the TCP options; they ensure safe and effective delivery of the packet. While there are some techniques where an attacker can gather information about a host based upon how they respond to strange settings in these options, their real importance is most often secondary to what is contained in the main header and data payload of the packet. Here are the options for the packet we're examining:

mss 1460: Max-segment-size or mss option (TCP option)
sackOK: Selective acknowledgement permitted (TCP option)
timestamp 238617: Round-trip delivery time used for tracking changes in latency that may require acknowledgment timer adjustments (TCP option)
nop: No operation provides padding around other options; useful for acknowledging receipt of packets without forcing resends (TCP option)
wscale 0: Window scale (not to be confused with the standard TCP header field of window size) used for recording the bytes of buffer space the host has for receiving data (TCP option)
(DF): The "don't fragment" bit is set

The tcpdump output shows this packet to be a connection request from specto.ksl.com to establish an FTP connection to quasi.ksl.com. While older versions of tcpdump might display only the port number, port 21 resolves here to the FTP service. This is resolved using the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Knowing the basics behind the captured tcpdump data, we can start looking at how to use tcpdump within the network. tcpdump can be used to test lines and network connections or sniff packets. There may be instances when problems arise within the network and you cannot physically lay hands on any machines for testing. It is times such as these that tcpdump comes in handy. If you can secure shell or SSH into a machine on the network and configure your network card to run in promiscuous mode, you can sniff the packets flowing by and later analyze them for issues.

It's interesting to note that tcpdump captures packets before the kernel receives them and after they leave it. Even more importantly, the packets are captured before they are processed by Netfilter. tcpdump allows you to see if the packets are arriving; it can also check the local machine for faulty configurations in the event of network problems.

If you are not sniffing from a remote host through an SSH session, instead of the client itself, be careful! You can end up sniffing your own terminal session traffic. tcpdump generates line after line of output that gets sent to your client through the terminal session, which generates more traffic, which gets sniffed, which... well, you get the idea. You can exclude the traffic generated by your terminal session with careful filtering (discussed later in the chapter).

Because tcpdump is command-line based, it is easy to run on any machine. You need not worry about a GUI interface as you would with ethereal. Rather than viewing the packets in real-time via the console, it is often more useful to capture them to a logfile and then use secure FTP (SFTP) or Secure Copy (SCP) to transfer the logs to another location. Use ethereal to better analyze the content.

There are a few ways to run tcpdump from the command line. Rather than viewing every packet as it scrolls across the screen, write the data to a temporary file. If your network is as busy as mine, it will be impossible to view everything. Even if you could, you may drop packets, since a standard display cannot keep up with normal network speed. The console uses a serial terminal connection emulation, which has a speed far less then 100 MBit/s.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As I mentioned early in this chapter, there are alternatives to tcpdump that provide GUI interfaces. However, it is important that you familiarize yourself first with the structure of packets as they are captured and then with command-line interface tools before making the leap to a GUI application that may overwhelm you with too much information. Starting off with something such as ethereal before learning the basics is like purchasing a top-end calculator with all the whistles and bells without knowing how to do simple addition, subtraction, and multiplication commands. You can still perform basic calculations, but you'll end up using only a small fraction of the calculator's total power or resources.

The ethereal network analyzer is a standard feature of most Linux distributions, including Red Hat Linux. Just like tcpdump, ethereal captures its data in libpcap format. It can also read captured data from a variety of other network sniffing appliances that may use different logging formats. Check the ethereal manpage for a complete listing of the applications with which it is compatible. Chances are if your application of tool is not listed, the ethereal developers can easily create a port of it or you may just find ethereal to be all that you need.

For those who prefer compiling the latest ethereal from source rather than simply installing the RPMs, the main ethereal page provides links and ports to nearly every available operating system and flavor of Unix on the market, including a Windows version. Most RPMs for ethereal are a couple versions behind the latest source release. Staying ahead of the game and up-to-date on the most current version is incentive enough for anyone to use the source rather than the binary.

Although there are several different options available for customizing ethereal, the standard commands apply. Use the following commands to build and install a default version of the application on your system after uncompressing the source code in a standard location:

# ./configure && make && make install

ethereal is a fairly beefy application, weighing in at over three and a half megabytes. It can take some time to compile on older systems. It is worth the wait.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The following lists the URL of each pertinent item mentioned in this chapter. Each site also has links to additional informative sites. I highly recommend browsing some of the locations for further tutorials, related applications, or noteworthy information.

ethereal	`http://www.ethereal.com`
libpcap	`http://www.tcpdump.org`
libpcap tutorial	`http://www.cet.nau.edu/~mc8/Socket/Tutorials/section1.html`
Packetyzer	`http://www.networkchemistry.com/products/packetyzer/`
Pcap tutorial	`http://www.tcpdump.org/pcap.htm`
Sans TCP/IP Guide	`http://www.sans.org/resources/tcpip.pdf`
tcpdump	`http://www.tcpdump.org`
Tethereal	`http://www.ethereal.com`
WinDump	`http://windump.polito.it`
WinPcap	`http://winpcap.polito.it`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter examines common techniques for capturing packets and analyzing their contents. In this chapter, we will get Snort installed and start experimenting with some of the ways to use it. We start with using Snort as a sniffer, a packet logger, and finally start using it as an actual NIDS.

Snort is perhaps the best known open source intrusion detection system available. Snort is designed primarily to operate from the command line, and it has been integrated into several other applications and ported to various platforms. Many third-party applications have been engineered around its use. Snort is actively maintained, and it is possibly the best open source IDS available for download.

Snort was first developed in November 1998. It was originally intended to function as a packet sniffer. Since then it has grown to become much more. Each week Snort is downloaded by thousands of users and developers. It is currently used in most IDS situations, from small office and home networks to corporate and IT offices worldwide. It has been ported to a variety of platforms, so finding a release for your particular operating system should be no problem. I currently run Snort on Windows, FreeBSD, Linux, and Solaris.

No discussion of Snort would be complete without mentioning its commercial counterpart. The Snort developers created their own company, Sourcefire , which supplies an intrusion detection appliance for enterprise-level networks. The Sourcefire appliance combines an enhanced version of Snort with other proprietary technologies to create what they call an Intrusion Management System (IMS). The capabilities of Snort and other applications are combined into a seamless whole that offers state-of-the-art monitoring, perimeter defense, system management, and real-time awareness. For the cost, Sourcefire offers perhaps the most up-to-date and reliable IDS devices for those interested in investing in a commercial variant. By any measure, it competes strongly with solutions from the big players—Cisco, ISS, NFR, and Top Layer, to name a few.

Not much needs to be said about installing Snort. It downloads and installs on nearly all platforms. The commands for configuring Snort are much the same as for other source code or RPM builds. The source is freely available for download in the event users wish to stay current with the latest releases. I strongly recommend downloading and compiling the Snort source code rather than installing a binary release; you are assured pristine code that has not been modified by any third party. You may also configure Snort with additional options, such as MySQL support. The most recent Snort release appears as source code before it comes out in RPM format. For the most up-to-date code, use the source.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Snort is perhaps the best known open source intrusion detection system available. Snort is designed primarily to operate from the command line, and it has been integrated into several other applications and ported to various platforms. Many third-party applications have been engineered around its use. Snort is actively maintained, and it is possibly the best open source IDS available for download.

Snort was first developed in November 1998. It was originally intended to function as a packet sniffer. Since then it has grown to become much more. Each week Snort is downloaded by thousands of users and developers. It is currently used in most IDS situations, from small office and home networks to corporate and IT offices worldwide. It has been ported to a variety of platforms, so finding a release for your particular operating system should be no problem. I currently run Snort on Windows, FreeBSD, Linux, and Solaris.

No discussion of Snort would be complete without mentioning its commercial counterpart. The Snort developers created their own company, Sourcefire , which supplies an intrusion detection appliance for enterprise-level networks. The Sourcefire appliance combines an enhanced version of Snort with other proprietary technologies to create what they call an Intrusion Management System (IMS). The capabilities of Snort and other applications are combined into a seamless whole that offers state-of-the-art monitoring, perimeter defense, system management, and real-time awareness. For the cost, Sourcefire offers perhaps the most up-to-date and reliable IDS devices for those interested in investing in a commercial variant. By any measure, it competes strongly with solutions from the big players—Cisco, ISS, NFR, and Top Layer, to name a few.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Not much needs to be said about installing Snort. It downloads and installs on nearly all platforms. The commands for configuring Snort are much the same as for other source code or RPM builds. The source is freely available for download in the event users wish to stay current with the latest releases. I strongly recommend downloading and compiling the Snort source code rather than installing a binary release; you are assured pristine code that has not been modified by any third party. You may also configure Snort with additional options, such as MySQL support. The most recent Snort release appears as source code before it comes out in RPM format. For the most up-to-date code, use the source.

The latest version of Snort as of this writing is snort-2.1.x. The developers attempt to keep abreast of the latest developments, patch submissions, and vulnerabilities, while also incorporating new features into their releases. Unlike the Linux kernel numbering scheme, the Snort minor number is not indicative of a stable or developmental release. Stables releases use odd as well as even release numbers.

Building Snort is fairly easy. There are a lot of options that you can request; the most important configure Snort to use various databases for storage. However, at this point, I'll show you how to do a quick and dirty build for some simple experimentation. In Chapter 6, when I talk about deploying a full-blown network IDS, I'll get into issues like database support.

Once you've downloaded and uncompressed the source distribution from http://www.snort.org, building it is easy. I create a directory in /usr/local/src called snort. I move the downloaded gzipped tarball to that directory and perform the following commands:

               $ tar xvft snort-2.1.x.tar.gz
               $ cd snort-2.1.x
               $ ./configure
               $ make
               # make install

The last command must be run as root. It installs the Snort binary in /usr/local/bin. Any user can run it, although you need to be root to place network interfaces in promiscuous mode.

If that works, fine. If it doesn't work, the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before we go into Snort's basic operational modes, let's first look at a breakdown of the command-line options. This chapter covers each item listed here, but some are not frequently used or may only be used in conjunction with other variables. Some of the options can be specified in the config file instead of at the command line. If you are just trying something out, specify the setting at the command line. If you are planning on keeping the setting for a while, set it in the config file.

-A alert-mode: Generates an alert using one of the specified alert-modes: fast, full, none, and unsock. Rather than specifying the alert mode within a configuration file, you can include it here at the command line.
-b: Logs packets in tcpdump format (i.e., libpcap). Files in tcpdump format are smaller, so this is the best method of recording large amounts of logged data and packets. It is very fast and may be a good option on high-traffic networks.
-B address-conversion-mask: Scrambles the networks specified in the -h (or HOME_NET) setting. This helps hide the real internal network addresses inside binary logs.
-c config-file: Allows you to specify which configuration file you want to use. If you have different configurations with various rules enabled, you can specify which configuration to use at the command line. This option is required when Snort is run in NIDS mode.
-C: Prints the character data found in the packet payload, rather than displaying it in hexadecimal format. Reading this information is easier than wrestling with Hex output.
-d: Displays the application layer data when in verbose or packet logging mode.
-D: Runs Snort in daemon mode. Alerts are dumped to the alert file in the logging directory (/var/log/snort by default). Daemon mode is useful if you wish to automate the startup of Snort in the event of a reboot. Passing this option to Snort in a command script starts Snort in the background. No error messages are printed to the console in this mode. Do not use this mode unless you are already familiar with Snort and have a working, viable configuration. (Use the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At this point, you may be asking yourself, Why do I need to know Snort? It sounds much like tcpdump, in that it sniffs packets and can read and write into the same libpcap format. Here are just a few of the reasons Snort is a versatile solution for both packet sniffing and intrusion detection. Snort:

Is descriptive and verbose.
Is more versatile than tcpdump in output and readability.
Determines each entry's value.
Identifies individual fields and computes corresponding fields.
Can be customized to print out all varying fields in the headers.
Has rules that are relatively easy to configure and understand.
Can report on separate wireless networks using specialized patches.
Generates alerts (it's a network intrusion detection system).

As you begin to use Snort, you will notice the many advantages it offers over tcpdump for raw data interpretation.

Next, we'll cover how to run Snort in its three basic operational modes.

Sniffer (snort -v)
Packet logger (snort -l)
Network Intrusion Detection System (snort -A or snort -c <path_to_conf_file>)

While the previously discussed network sniffer tools (tcpdump, ethereal, and Tethereal) are more full-featured and provide excellent packet analysis, there may come a time when you quickly look at the network traffic on a Snort sensor. In this case, using Snort as a sniffer might be valuable. The Snort sniffer-mode output is slightly different than the other command-line sniffers. It is actually very easy to read and you may find you prefer it for quick captures. One very nice feature of sniffer-mode Snort is the network traffic summary at the end of the capture. Sometimes this can be a very useful troubleshooting tool for network administrators.

Enable sniffer mode for Snort using the -v flag:

               # snort -v
Running in packet dump mode
Log directory = /var/log/snort

Initializing Network Interface eth0

        --== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface eth0

        --== Initialization Complete ==--

-*> Snort! <*-
Version 2.1.x (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
06/24-11:19:32.257859 64.147.136.193:3131 -> 192.168.0.15:9100
TCP TTL:128 TOS:0x0 ID:21742 IpLen:20 DgmLen:48 DF
******S* Seq: 0x5DB36D37  Ack: 0x0  Win: 0xFAF0  TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:19:32.261606 64.147.136.5 -> 224.0.0.10
EIGRP TTL:2 TOS:0x0 ID:0 IpLen:20 DgmLen:60
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:19:34.470931 64.147.136.1 -> 224.0.0.10
EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20 DgmLen:60
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:19:34.482799 64.147.136.1 -> 224.0.0.10
EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20 DgmLen:60
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

===========================================================================
Snort analyzed 38 out of 38 packets, dropping 0(0.000%) packets

Breakdown by protocol:                Action Stats:
    TCP: 1          (2.632%)          ALERTS: 0
    UDP: 0          (0.000%)          LOGGED: 0
   ICMP: 0          (0.000%)          PASSED: 0
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 37         (97.368%)
DISCARD: 0          (0.000%)
===========================================================================
Wireless Stats:
Breakdown by type:
    Management Packets: 0          (0.000%)
    Control Packets:    0          (0.000%)
    Data Packets:       0          (0.000%)
===========================================================================
Fragmentation Stats:
Fragmented IP Packets: 0          (0.000%)
    Fragment Trackers: 0
   Rebuilt IP Packets: 0
   Frag elements used: 0
Discarded(incomplete): 0
   Discarded(timeout): 0
  Frag2 memory faults: 0
===========================================================================
TCP Stream Reassembly Stats:
        TCP Packets Used: 0          (0.000%)
         Stream Trackers: 0
          Stream flushes: 0
           Segments used: 0
   Stream4 Memory Faults: 0
===========================================================================
Snort exiting

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Any security-related project starts with an inventory. You need to know what systems are in your environment and what software they are running. You also need to know what business processes exist in your organization so you can tailor your information technology decisions to support these processes.

When starting an IDS project, it's important to know not just what you're protecting, but also what the threats to your environment are. If you don't understand the nature and methods of your enemy, building defenses to protect against their attack is nearly impossible. While you might stumble onto something by accident, a targeted approach to an IDS deployment yields better returns on your time (and budget).

It's unlikely that a maniacal billionaire is hiring some elite hacker to break into your network or that a group of former Spetnatz commandos are trying to steal the secret to how your widgets are manufactured. The threat often comes from people who aren't targeting you specifically; they are simply scanning huge ranges of Internet-connected systems looking for vulnerable systems that they can use for whatever purpose. No matter the identity of these individuals, they can be the cause of your two real enemies: downtime and data loss.

Most often these attackers are not targeting your environment specifically. They scan and probe wide ranges of addresses looking for systems that are vulnerable to the exploits they are familiar with. They range from the classic 15-year-old boy trying to gain notoriety with his peers to a SPAM sender looking for an open mail server to act as a relay for his unsolicited emails. While this group of people represents mainly an annoyance, it is folly to ignore the threat.

Simply connecting your network to the Internet exposes you to this kind of attacker. It's not a matter of if but when someone will probe and attempt to penetrate your network.

Opportunists: These individuals are trying to break into systems just for the challenge. They might just look around after getting in, or may become vandals. While not (at least initially) malicious, they can inadvertently do damage or cause service interruptions in the course of their activity.

Addit

Table of Contents