[Snort-devel] Snort 2.0 high CPU load and bad alert rate with higher traffic lo ads?

Obermayr Thomas Thomas.Obermayr at ...2012...
Wed Jun 4 06:27:23 EDT 2003


Hiya!


As part of our studies of different free and commercial IDSs we've had
students perform high speed tests with Snort 1.9.1 and Snort 2.0. The papers
published before the release of Snort 2.0 lead us to believe that Snort 2.0
would actually perform better in a higher load scenario. 

However we've found the opposite to be true.

Test Scenario:
--------------

Snort machine:
    Intel P4 2.4 GHz
    256 MB RAM
    Dual GBit Ethernet
    RedHat 7.3
    Snort 1.9/Snort 2.0

Switch:
    HP ProCurve 8000M
    8x  100 MBit Ports
    4x 1000 MBit Ports
    Snort attached to port configured as monitoring port

8x Traffic generating and receiving machines

1x Nessus scan machine
1x Nessus scan target machine

A pre-defined Nessus Scan was run in all cases and resulted in 38 alerts
with Snort 1.9 and 42 alerts with Snort 2.0.

Certain rules within Snort 1.9 and 2.0 had to be disabled as to not cause
alerts. With the default config otherwise unaltered both versions of Snort
found no alerts with the background traffic alone.

Background traffic: Traffic Generator TCP to port 11111, reply either ACK
only or echo for 750 MBit.

BG    : Background Traffic in MBit/s
CPU   : CPU load in percent
Alerts: Number of alerts reported by Snort

All tests were repeated 5 times with the number of alerts being the average
over all five tests.


Results for 80k TCP packets background traffic:


Snort 1.9:

 BG     CPU     Alerts
-----------------------
  0      5%       38
100     35%       36
380     95%       30
750     99%       25


Snort 2.0:

 BG     CPU     Alerts
-----------------------
  0      5%       42
100     90%       20
380     99%       15
750     99%       12


The test was repeated with 1024 byte TCP packets to make sure TCP stream
reassembly was not causing the high CPU loads. This test lead to the same
results as stated above.

There were several more tests performed with different background traffic
(UDP, mixed TCP/UDP, HTTP requests), with all showing the same picture
within a small margin of error.

This very much looks to us like something within the Snort 2.0 engine is
using a lot more CPU time than 1.9 and therefore causes 2.0 to "see" only
half of the attacks with a traffic load of 100 MBit/s whereas Snort 1.9
utilizes a third of the CPU and performs almost as well as with zero
traffic.

I didn't, of course, expect Snort to work great with 750 Mbit/s traffic
load, however the results with Snort 2.0 for 100 Mbit are a bit
disappointing.

There will probably be a detailed paper of all the tests, results,
configuration etc. at a later time, but this is a pretty good summary of the
results.

If any of the developers (or anyone else) can shed some light on why Snort
2.0 is performing "so badly" with higher traffic loads (and misses 50% of
attacks at only 100MBit/s already) it would be greatly appreciated.

Also any hints or tops on how to make Snort 2.0 perform better in the 100
MBit/s traffic range would be great. Or maybe we just have to wait for 2.0
to be further optimized? And finally, of course, let me congratulate all the
dedicated developers for such a great product!

Regards,
         Tom Obermayr




More information about the Snort-devel mailing list