[Snort-users] dual interface?

Bennett Todd bet at ...6163...
Fri Oct 25 06:50:07 EDT 2002

2002-10-24-15:13:12 Phillip Tyre:
> [...] Since I was monitoring traffic outside my firewall, inside
> my firewall, and inside each of my DMZs I wanted to be able
> to configure my rules independtly, so I'm running 4 seperate
> instances of snort:
> snort -i eth0 -U -o -d -D -c /etc/snort/snort0.conf
> snort -i eth1 -U -o -d -D -c /etc/snort/snort1.conf
> snort -i eth2 -U -o -d -D -c /etc/snort/snort2.conf
> snort -i eth3 -U -o -d -D -c /etc/snort/snort3.conf

That's often the recommended approach. For many settings, it's easy
to get enough overkill on hardware that performance isn't an issue.

One time you don't want to be forced to take this approach is when
you've got two or more NICs whose traffic you must consolidate,
because e.g. a balanced H-A plant might have assymetric routing,
with replies coming down a different side from queries, and hence
both sides must be reassembled for snort to track tcp session
initiation correctly. That's the circumstance that drove me to
figure out the channel bonding stuff for Linux. The only alternative
here is to use extra external hardware, a hub or a switch, to
aggregate the traffic.

Another case might be when the performance of the box is near the
wall, and there's fairly active traffic on multiple of the
interfaces concurrently, and you don't have at least as many CPUs as
you have active snort instances. I could imagine the context
switching overhead of having multiple concurrent different snorts
might impact performance.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20021025/caf621bc/attachment.sig>

More information about the Snort-users mailing list