[Oisf-users] Listening on multiple interfaces with Suricata

[Victor Julien]

>From my blog:
http://www.inliniac.net/blog/2010/12/24/listening-on-multiple-interfaces-with-suricata.html

A question I see quite often is, can I listen on multiple interfaces
with a single Suricata instance? Until now the answer always was “no”.
I’d suggest trying the “any”-pseudo interface (suricata -i any), with an
bpf to limit the traffic or using multiple instances of Suricata. That
last suggestion was especially painful, as one of the goals of Suricata
is to allow a single process to process all packets using all available
resources.

Last week I found some time to look at how hard adding support for
acquiring packets from multiple interfaces would be. Turned out, not so
hard! Due to Suricata’s highly modular threading design, it was actually
quite easy. I decided to keep it simple, so if you want to add multiple
interfaces to listen on, just add each separately on the command line,
like so: suricata -i eth0 -i eth1 -i ppp0. This will create a so called
“receive thread” for each of those interfaces.

I’ve added no internal limits, so in theory it should possible to add
dozens. I just tested with 2 though, so be careful. Normally the thread
name in logs and “top” for the pcap receive thread is “ReceivePcap”.
This is still true if a single interface is passed to Suricata. In case
more are passed to Suricata, thread names change to “RecvPcap-<int>”,
e.g. RecvPcap-eth0 and RecvPcap-eth1. Untested, but it should work fine
to monitor multiple interfaces from different types. Suricata sets the
data link type in the interface-specific receive thread.

If you’re interested in trying out this new feature, there are a few
limitations to consider. First, no Windows support yet. I hope this can
be addressed later. Second, the case where two or more interfaces
(partly) see the same traffic is untested. The problem here is that
we’ll see identical packets going into the engine. This may (or may not,
like I said, it’s untested) screw up the defrag, stream engines. Might
cause duplicate alerts, etc. Addressing this is something that would
probably require keeping a hash of packets so we can detect duplicates.
This is probably quite computationally intensive, so it may not be worth
it. I’m very much open to other solutions. Patches are even more welcome :)

So, for now use it only if interfaces see completely separate traffic.
Unless you’re interested to see what happens if you ignore my warnings,
in that case I’d like to know! The code is available right now in our
current git master, and will be part of 1.1beta2.

Merry xmas everyone!

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------