Deep packet inspection (DPI) is all about understanding what’s in network traffic – minimally, to be aware of it (an intrusion detection system, or IDS), but, more commonly these days, to do something about it (an intrusion prevention system, or IPS).

Part 1 of our DPI coverage was motivated by a DPI bake-off run by Netronome. The benchmark used was the Snort algorithm. Snort is a free, open-source program for implementing IDS or IPS, and it has been widely used. It consists of the program itself and a body of rules that are being updated regularly. This “crowdsourcing” of rules is one of the things that make Snort appealing. An installation of Snort can be regularly updated with new rules.

Snort can operate in one of three modes. The first two simply display packets: one on screen, the other by logging to files. The third mode is the most powerful one: it can search for content in a packet and then, optionally, do something if the looked-for thing shows up. When used passively alongside the network, Snort acts as an IDS. When placed inline, as a “bump in the wire,” Snort acts as an IPS and can block, pass, create, or modify packets.

The key to Snort is the body of rules, both those that exist and new ones that can be created. Each rule consists of a header and a set of options. The header specifies an action as well as traffic information about the packet to be monitored (source, destination, port, etc.). The options provide alert messages and content to be located, as well as possible limitations on where to look for the content.

Content searching is done largely based on regular expressions. There are more than 4000 rules at present. This creates a major computing burden, since all rules theoretically need to be run against all packets. The fact that the rules are independent suggests that many rules could be run in parallel using independent content inspection engines, each of which would handle separate rules.

The problem is that all these rules require searching the packet, which is stored in memory, and there aren’t that many ports allowing simultaneous access to the packet. Making multiple copies of the packet takes too long, which leaves running the rules in series as the only option.

The way this is handled is that the rules are constructed hierarchically and compiled into a tree so that, as the packet is searched, the tree is traversed, effectively eliminating rules that aren’t being met and allowing for a much smaller subset of rules to be run.

The execution of all these regular expression checks is still significant work, and, in a future article, we’ll look at one option for accelerating that work.

More info on Snort is available here…