The Best Damn Firewall Book Period

Exploring Snort's Features

Snort has several features that make it very powerful: packet sniffing, packet logging, and intrusion detection. Before getting into Snort's features, you should understand Snort's architecture. Snort has several important components, most of which are enabled through the use of plug-ins to customize your Snort implementation. These components include preprocessors, alert plug-ins (which enable Snort to manipulate a packet to make the contents more manageable by the detection engine), and the alert system, which can send its output to different destinations.

Snort consists of four basic components:

• The sniffer

• The preprocessor

• The detection engine

• The output

In its most basic form, Snort is a packet sniffer. However, it is designed to take packets and process them through the preprocessor, and then check those packets against a series of rules (through the detection engine). Figure 29.1 offers a high-level view of the Snort architecture. In its simplest form, Snort's architecture can be likened to a mechanical coin sorter:

Figure 29.1: Snort Architecture

1. It collects all the coins (packets from the network backbone).

2. The coins are sent through a chute to determine if they are coins, and how they should roll (the preprocessor performs this function on the IDS).

3. Next, the coins are sorted according to the coin type. This is for storage of quarters, nickels, dimes, and pennies (the detection engine performs this function on the IDS).

4. Finally, it is the administrator's task to decide what to do with the coins—usually you'll roll them and store them (logging and database storage).

The preprocessor, the detection engine, and the alert components of Snort are all plug-ins. Plug-ins are programs that are written to conform to Snort's plug-in API. These programs used to be part of the core Snort code, but were separated out to make modifications to the core source code easier and more reliable.

Packet Sniffer

A packet sniffer is a device (either hardware or software) used to tap into networks. It works in a similar fashion to a telephone wiretap, but it is used for data networks instead of voice networks. A network sniffer allows an application or a hardware device to eavesdrop on data network traffic. In the case of the Internet, this usually consists of IP traffic, but it can be other traffic such as IPX and AppleTalk network protocols.

Because IP traffic consists of many different types of network traffic, including TCP, UDP, ICMP, routing protocols and IPSec, many sniffers analyze the various network protocols to interpret the packets into something human-readable.

Packet sniffers have various uses:

• Network analysis and troubleshooting

• Performance analysis and benchmarking

• Eavesdropping for clear-text passwords and other interesting tidbits of data

Encrypting your network traffic can prevent people from being able to sniff your packets into something readable. Like any network tool, packet sniffers can be used for good and evil.

As Marty Roesch said, he named the application because it does more than sniffing—it snorts. The sniffer needs to be set up to obtain as many packets as possible. As a sniffer, Snort can save the packets to be processed and viewed later as a packet logger. Figure 29.2 illustrates Snort's packet sniffing ability.

Figure 29.2: Snort's Packet Sniffing Functionality

Preprocessor

At this point, our coin sorter has obtained all the coins it can (packets from the network), and is ready to send the packets through the chute. Before rolling the coins (the detection engine), the coin sorter needs to determine if they are coins.

This is done through the preprocessor. The preprocessor takes the raw packets and checks them against certain plug-ins (like an RPC plug-in and a port scanner plug-in). These plug-ins check for a certain type of behavior from the packet. Once the packet is determined to have a particular type of behavior, it is then sent to the detection engine. From Figure 29.3, you can see how the preprocessor uses its plug-ins to check a packet.

Figure 29.3: Snort's Preprocessor

This is such a great feature for an IDS because other plug-ins can be enabled and disabled as they are needed at the preprocessor level. For example, if you are not interested in the RPC traffic coming into your network, you can disable this plug-in and use the others.

Detection Engine

The detection engine is the meat of the IDS in Snort. The detection engine takes the data that comes from the preprocessor and its plug-ins, and that data is checked through a set of rules. If the rules match the data in the packet, then they are sent to the alert processor.

Earlier in this chapter, we described Snort as a signature-based IDS. The signature-based IDS function is accomplished by using various rule sets. The rule sets are grouped by category (Trojan horses, buffer overflows, access to various applications), and are updated regularly.

The rules themselves consist of two parts:

• The rule header The rule header is basically the action to take (log or alert), type of network packet (TCP, UDP, ICMP, and so forth), source and destination IP addresses, and ports.

• The rule option The option is the content in the packet that should make the packet match the rule.

The detection engine and its rules are the largest portion (and steepest learning curve) to learn and understand with Snort. Snort employs a specific syntax with its rules. Rule syntax can involve the type of protocol, the content, the length, the header, and other various elements, including garbage characters for defining buffer overflow rules.

Once you learn how to write Snort rules, you can fine tune and customize Snort's IDS functionality. You can define rules that are particular to your environment and customize however you want.

The detection engine is the part of the coin sorter that actually rolls the coins based on the type. The most common American coins are the quarter, dime, nickel, and penny. However, you might get a coin that doesn't match, like the Kennedy half-dollar, and discard it. This is illustrated in Figure 29.4.

Figure 29.4: ort's Detection Engine

Alerting/Logging Component

After the Snort data goes through the detection engine, it must be output somewhere. If the data matches a rule in the detection engine, then an alert is triggered. Alerts can be sent to a log file, through a network connection, through UNIX sockets or Windows pop-up (Server Message Block [SMB]), or SNMP traps. The alerts can also be stored in an SQL database such as MySQL and Postgres.

Additionally, there are all sorts of other tools you can use with Snort, including various plug-ins for Perl, PHP, and Web servers to display the logs through a Web interface. Logs are stored in either text files (by default in /var/log/snort) or in a database such as MySQL and Postgres.

Like the detection engine and the preprocessor, the alert component uses plug-ins to send the alerts to databases and through networking protocols such as SNMP traps and WinPopup messages. See Figure 29.5 for an illustration of how this works.

Figure 29.5: Snort's Alerting Component

Additionally, with syslog tools such as Swatch, Snort alert messages can be sent via e-mail to notify a system administrator in real time so no one has to monitor the Snort output all day and night. Table 29.1 lists a few examples of various useful third-party programs and tools.