Feature Highlight: Snort Rule Editor

Recently, the Snort Rule Editor as a part of the Rules Management Interface has been updated. This redesign allows for increased flexibility and provides the user with more of a handle on the IPS rules settings.

How It Works

Entering the Rules Management Interface is easy and can be accessed from two possible locations. From the View Sensors page, the user can select the Edit Rules link to enter the Rules Management Interface. The user can also navigate to the Rules Management Interface from the Main Menu link.

Upon selecting the Rules Management Interface, the user will be prompted to select a sensor from the dropdown and then choosing the Load Rules button. From there, the user will be able to manage the rule sets on a sensor-by-sensor basis.

Selection_003

After selecting a sensor, the user will have the option to modify properties of the rule sets, and issue commands to the sensors with the tools on the Menu Bar. In order for the changes made in the rules interface to take effect, commit the changes using the Save button. (Please note that the Save/Cancel options only appear if the rules have been modified.) After selecting the Save option, a window will appear indicating that the changes are being verified. This process ensures that there are no issues with any changes that were made to the rule sets and that the sensor will correctly load the rules. Once the Save process is finished, the user will be prompted to reload the sensor.

To update the rule files, select the Get Updates button on the Snort Rules Controls. Most of the sensor controls buttons will be disabled/greyed out, and the Get Updates button will have a spinner icon until the update process finishes. Next, the page will refresh to indicate if the updates were applied successfully. After the Get Updates process completes, select to Save the changes and Reload the sensor configuration for the changes to take effect.

Get_updates_1Get_updates_2

The Rule File List portion of the interface displays a complete listing of all the rule sets in the sensor configuration. The local.rules file contains the pass rules (if any) that have been generated using the Tune IDS feature and any rules that were uploaded by the user.

Rules_listings_per_file

In the Rule List, each rule can be enabled or disabled by selecting the checkbox under the Active column next to each rule. If the checkbox under the Drop column next to a rule is checked, the sensor will drop flows that trigger the rule. Although we only recommend it for advanced users, each specific rule can also be edited by clicking on the rule itself. This will open the Rule Editor window, displaying the original rule, the editor, and some statistics that have been collected for that rule. Advanced Snort users can use the Rule Editor to make changes to the content of individual rules. When modifications are made, the Diff section will show changes to a rule since the most recent Save of the rule sets.

Manual_rule_editor

Pass Rules inform the IDS system that packet matching these rules should not generate alerts. These are helpful for eliminating false positives without having to disable the offending rule altogether. The Pass Rules have system-generated SIDs so that they do not conflict with the original rules that to which they refer. The user can utilize the tuning interface to add pass rules to the local.rules file. Please remember to Save any changes to the rule sets through the Rules Management Interface.

Selection_004

For users that want to run a reduced rule set for performance reasons, there is an Automatic Tuning option under the Bulk Edit menu. This option will disable rules that are unlikely to trigger based on our observations across all customer networks. After clicking on the Automatic Tuning option, the changes will be merged with any prior changes that have made, meaning that rules that have specifically enabled will stay enabled. If the user wants to revert to a default minimal set, they should consider first using the Rules Defaults option. Once the Automatic Tuning has processed the rules, it will then automatically fetch the latest updates and disable all of the appropriate rules. To complete this process, the user will need to select Save so that the changes are committed.

Full color images and even more detailed instructions regarding The Rules Management Interface can found in the MetaFlows Wiki.

And Now For Something Completely Technical: PF Ring 10 Gbps Snort IDS

You can always visit the MetaFlows Website for more information.

PF_RING based 10 Gbps Snort multiprocessing

Tested on CentOS 6 64bit using our custom PF_RING source

PF_RING load balances network traffic originating from an Ethernet interface by hashing the IP headers into N buckets. This allows it to spawn N instances of Snort, each processing a single bucket and achieve higher throughput through multiprocessing. In order to take full advantage of this, you need a multicore processor (like an I7 with 8 processing threads) or a dual or quad processor board that increases parallelism even further across multiple chips.

In a related article we measured the performance of PF_RING with Snort inline at 1 Gbps on an I7 950. The results were impressive.

The big deal is that now you can build low-cost IDPS systems using standard off-the-shelf hardware.

You can purchase our purpose-built Hardware with MetaFlows PF_RING pre-installed, giving you a low cost high performance platform to run your custom PF_RING applications on. If you are interested in learning more, please contact us.

In this article we report on our experiment running Snort on a dual processor board with a total of 24 hyperthreads (using the Intel X5670). Besides measuring Snort processing throughput varying the number of rules, we also (1) changed the compiler used to compile Snort (GCC vs. ICC) and (2) compared PF_RING in NAPI mode (running 24 Snort processes in parallel) and PF_RING Direct NIC Access technology (DNA) (running 16 Snort processes in parallel).

PF_RING NAPI performs the hashing of the packets in software and has a traditional architecture where the packets are copied to user space by the driver. Snort is parallelized using 24 processes that are allowed to float on the 24 hardware threads while the interrupts are parallelized on 16 of the 24 hardware threads.

PF_RING DNA performs the hashing of the packets in hardware (using the Intel 52599 RSS functionality) and relies on 16 hardware queues. The DNA driver allows 16 instances of Snort to read packets directly from the hardware queues therefore virtually eliminating system-level processing overhead. The limitation of DNA is that (1) supports a maximum of 16x parallelism per 10G interface, (2) it only allows 1 process to attach to each hardware queue and (3) it costs a bit of money or requires Silicom cards(well worth it). (2) is significant because it does not allow multiple processes to receive the same data. So, for example if you run “tcpdump -i dna0″, you could not also run “snort -i dna0 -c config.snort -A console” at the same time. The second invocation would return an error.

GCC is the standard open source compiler that comes with CentOS 6 and virtually all other Unix systems. It is the foundation of open source and without it we would still be in the stone age (computationally).

ICC is an Intel proprietary compiler that goes much further in extracting instruction- and data-level parallelism of modern multicore processors such as the i7 and Xeons.

All results are excellent and show that you can build a 5-7 Gbps IDS using standard off-the-shelf machines and PF_RING. The system we used to perform these experiments is below:

The graph above shows the sustained Snort performance of 4 different configurations using a varying number of Emerging Threats Pro rules. As expected, the number of rules has a dramatic effect on performance for all configurations (the more rules, the lower the performance). In all cases, memory access contention is likely to be the main limiting factor.

Given our experience, we think that our setup is fairly representative of an academic institution we have to admit that measuring Snort performance in the absolute is hard. No two networks are the same and rule configurations vary even more widely, nevertheless, the relative performance variations are important and of general interest. You can draw your own conclusions from the above graph; however here are some interesting observations:

  • At the high end (6900 rules) ICC makes a big difference by increasing the throughput by ~1 Gbps (25%)
  • GCC is just as good at maintaining throughput around 5 Gbps
  • PF_RING DNA is always better than PF_RING NAPI.

We describe below how to reproduce these numbers on Linux CentOS 6. If you do not want to go through these steps, we also provide this functionality through our security system (MSS) pre-packaged and ready to go. It would help us if you tried it and let us know what you think.