Snort mailing list archives

Re: multiple instances, three nics, one box


From: Bennett Todd <bet () rahul net>
Date: Tue, 13 Apr 2004 01:52:30 +0000

2004-04-12T21:31:17 Zondlo, Zack:
Anyone know how to run two separate instances of snort on one box, to
the point where they act as if on different boxes and I can get them to
show as 1a and 1b (for example) on my management box.

Except for the last few words, you're looking for three invocations
of snort, with (perhaps) distinct -c and (surely) distinct -i
options.

Your "management box" is running some management software, and
that's not snort. That's some aftermarket add-on, as it were. The
answer "how to make the differences show up distinctly on your
management box" lies partly if not entirely in the neighborhood of
your management software. I've no clue about the RDBMS backends to
snort, never tried one. If you're syslogging and using a
syslog-based management system, you may be looking for "-I".

I have 3 nics, one outside, one inside, one for management and I'm
looking to use one machine to monitor both sides of the firewall
and want to keep everything separate but not buy a second box.

As a general rule, if you have identical rules, and you want to
purely aggregate the traffic, you can get the best performance with
bonding the NICs together and having snort listen to the aggregated
bond0 interface.

If you have identical rules, but want snort to be able to
distinguish them with -I, then you may want to tell snort to listen
on -i any.

If you have different rules, you need to run separate instances of
snort, this is the most general-purpose config.

The first and third options are generally preferred, and it's nice
to have (a) a separate, unnumbered interface for each place snort
should listen, and (b) at least as many CPUs as you have concurrent
snort instances (plus one if you're doing high volumes, plus 2 if
high volumes plus significant local processing e.g. with an
aggregator or local RDBMs or whatever). If you can't hit these,
performance will be less than optimal.

-Bennett

Attachment: _bin
Description:


Current thread: