editor's blog
Subscribe Now

Open-Source DPI

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

Leave a Reply

featured blogs
Apr 7, 2020
Have you seen the video that describes how the coronavirus has hit hardest where 5G was first deployed?...
Apr 7, 2020
In March 2020, the web team focused heavily on some larger features that we are working on for release in the spring. You’ll be reading about these in a few upcoming posts. Here are a few smaller updates we were able to roll out in March 2020. New Online Features for Ma...
Apr 6, 2020
My latest video blog is now available. This time I am looking at the use of dynamic memory in real-time embedded applications. You can see the video here or here: Future video blogs will continue to look at topics of interest to embedded software developers. Suggestions for t...
Apr 3, 2020
[From the last episode: We saw some of the mistakes that can cause programs to fail and to breach security and/or privacy.] We'€™ve seen how having more than one program or user resident as a '€œtenant'€ in a server in the cloud can create some challenges '€“ at leas...

Featured Video

Industry’s First USB 3.2 Gen 2x2 Interoperability Demo -- Synopsys & ASMedia

Sponsored by Synopsys

Blazingly fast USB 3.2 Gen 2x2 are ready for your SoC. In this video, you’ll see Synopsys and ASMedia demonstrate the throughput available with Synopsys DesignWare USB 3.2 IP.

Learn more about Synopsys USB 3.2