erek at ...577...
Sun Jun 9 13:20:02 EDT 2002
On Sun, 9 Jun 2002, James Ashton wrote:
> I am building a new, faster box to run on this network. I am basicaly
> learning with this one. I had hopoed that the 266 would cover a network that
> doesnt see much traffic, like this one. I have also cut a few rules out of
> some of the rules files. maybe 4 or 5 total. nothing that makes a noticable
> differance. Just top get rid of alerts I was not worried about that
> cluttered up the database.
> My original question stands though. Why do the -A fast -b flags actualy slow
> snort down. When run with those flags this box goes from reading one out of
> every 8 packets to reading one out of every 15 or so.
> Again, snort is stared by the command: snort -c /etc/snort/snort.conf -i
> eth0 -D
There are a _lot_ of factors that can make a difference with the speed
as to which snort can log. Lets take a look at your config.
> var HOME_NET [A.B.C.D/24]
> var EXTERNAL_NET any
Works fine, but some internal things will show up as false postives if you do
that. Perhaps consider setting EXTERNAL_NET to !$HOME_NET.
> var SMTP $HOME_NET
> var HTTP_SERVERS $HOME_NET
> var SQL_SERVERS $HOME_NET
> var DNS_SERVERS [a.b.c.d, e.f.g.h]
> preprocessor frag2: timeout 15
> preprocessor stream4: detect_scan, timeout 15, memcap 17572864
> preprocessor stream4_reassemble both, ports [21, 23, 25, 53, 80, 143, 110, 111,
OK, lotsa stuff going on inside of stream4. Reassembling of both client and
source is CPU intensive.
> preprocessor http_decode: 80 2301 -unicode -cginull
> preprocessor portscan: $HOME_NET 5 5 portscan.log
> preprocessor portscan-ignorehosts: $DNS_SERVERS
> output database: log, mysql, user=snort password=snort dbname=snort2
OK, logging to a MySQL DB on the same box. Here's a significant bottlneck.
Your sensor is losing CPU to the DB, and is having to wait on actions
(inserts) to complete before it can write the next packet from snort. That
adds up to a backlog. You might want to consider using barnyard.
> #include classification.config
Errr... Most rules use this, might want to consider adding it back.
> include bad-traffic.rules
> include exploit.rules
> include finger.rules
> include ftp.rules
> include telnet.rules
> include dos.rules
> include tftp.rules
> include web-cgi.rules
> include web-iis.rules
> include web-misc.rules
> include web-attacks.rules
> include misc.rules
> include attack-responses.rules
> include backdoor.rules
Now that's with no flags. When you add flags, you override/add-onto whatever
configs are in snort.conf.... So when you add -b for binary logging, you are
logging to a DB on the local system _and_ to the pcap binary file. When you
add -A (full|fast) you are _again_ increasing I/O usage--Now snort has to log
to a DB, log to bianary files, and then log the decoded packet (full|fast)
info into /var/log/snort/alert.
Consider the box you are using for this. Does it have a very strong I/O
subsystem? SCSI2 or better? One disk? Multi Disks? How many I/O boards to
share bandwith? You may also want to check out your ethernet card. Many
times I've seen performance changes just by trying a different ether card.
Anyways, hope that helps!
More information about the Snort-users