Dissecting Snort
- Feeding Snort Packets with Libpcap
- Preprocessors
- The Detection Engine
- Output Plugins
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The cliché your grammar school teachers told you, "It's what's on the inside that counts!" still applies in the real world. Snort contains many configurable internal components that can vastly influence false positives and negatives as well as general packet logging performance. Knowledge of Snort's internals is required to make Snort run and monitor for intrusions effectively. Snort is a powerful application, but it takes a little more in-depth research on your part than other, less potent, IDSs. Understanding the function of these internal components will help you customize Snort to your network and help you avoid some of the common Snort pitfalls.
Snort can be divided into five major components that are each critical to intrusion detection. The first is the packet capturing mechanism. Snort relies on an external packet capturing library (libpcap) to sniff packets. After packets have been captured in a raw form, they are passed into the packet decoder. The decoder is the first step into Snort's own architecture. The packet decoder translates specific protocol elements into an internal data structure. After the initial preparatory packet capture and decode is completed, traffic is handled by the preprocessors. Any number of pluggable preprocessors either examine or manipulate packets before handing them to the next component: the detection engine. The detection engine performs simple tests on a single aspect of each packet to detect intrusions. The last component is the output plugins, which generate alerts to present suspicious activity to you. A simplified graphical representation of the dataflow is shown in Figure 3.1.
)
Figure
3.1 Snort component dataflow.
Feeding Snort Packets with Libpcap
To get packets into the preprocessors and then the main detection engine, some prior labor must first occur. Snort has no native packet capture facility yet; it requires an external packet sniffing library: libpcap. Libpcap was chosen for packet capture for its platform independence. It can be run on every popular combination of hardware and OS; there is even a Win32 port—winpcap. Because Snort utilizes the libpcap library to grab packets off the wire, it can leverage lipbcap's platform portability and be installed almost anywhere. Using libpcap makes Snort a truly platform-independent application.
The responsibility for grabbing packets directly from the network interface card belongs to libpcap. It makes the capture facility for raw packets provided by the underlying operating system available to other applications.
A raw packet is a packet that is left in its original, unmodified form as it had traveled across the network from client to server. A raw packet has all its protocol header information left intact and unaltered by the operating system. Network applications typically do not process raw packets; they depend on the OS to read protocol information and properly forward payload data to them. Snort is unusual in this sense in that it requires the opposite: it needs to have the packets in their raw state to function. Snort uses protocol header information that would have been stripped off by the operating system to detect some forms of attacks.
Using libpcap is not the most efficient way to acquire raw packets. It can process only one packet at a time, making it a bottleneck for high-bandwidth (1Gbps) monitoring situations. In the future Snort will likely implement packet capture libraries specific to an OS, or even hardware. There are several methods other than using libpcap for grabbing packets from a network interface card. Berkeley Packet Filter (BPF), Data Link Provider Interface (DLPI), and the SOCK_PACKET mechanism in the Linux kernel are other tools for grabbing raw packets.
Packet Decoder
As soon as packets have been gathered, Snort must decode the specific protocol elements for each packet. The packet decoder is actually a series of decoders that each decode specific protocol elements. It works up the Network stack, starting with lower level Data Link protocols, decoding each protocol as it moves up. A packet follows this data flow as it moves through the packet decoder (see Figure 3.2).
)
Figure
3.2 Decoder data flow.
As packets move through the various protocol decoders, a data structure is filled up with decoded packet data. As soon as packet data is stored in a data structure it is ready to be analyzed by the preprocessors and the detection engine.