[Oisf-users] Listening on multiple interfaces with Suricata

[Pablo]

2010/12/24 Victor Julien <victor at inliniac.net>

> >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 :)
>

Hi Victor,

Great work! This looks interesting for some confgurations. Thinking on
divert sockets (ipfw), maybe it would be useful to do something similar
(collect packets from different diverts), with the advantage that you can
configure filters from ipfw to avoid duplicated traffic on each port.

Also, with the same idea in mind, would it be possible to set filters for
the interfaces to address this? Let's say eth1 has behind net1 (
192.168.0.0/24) and eth2 net2 (192.168.1.0/24), maybe it would be possible
to set up a filter at eth0 to only process packets like [net1 <-> !net2],
and eth2 any net. So in this case the duplicated traffic (net1 <-> net2)
would be processed only by eth2 regardless of the directtion, and it would
not be processed by eth1. Would this idea become possible by setting bpf
filters on each interfaces specified? I guess that the more networks you'd
have, the more complex the filters would become, right, but possible,
thought.

So the fact of duplicated traffic would not become to realize through the
filters.

The idea would be to setup the interfaces configuration at the config file
suricata.yaml, by setting the interfaces to capture traffic from, and
"bpf-filter" for each of them (cause currently we can set only one bpf
filter for a "main" iface). Lot of interfaces would process ony traffic of
the nets behind them, and others would process the common traffic.

Your thoughts?


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!
>

Merry xmas! ;-)


>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>



-- 

Best regards,

--
Pablo Rincón Crespo
Security researcher and developer
Open Information Security Foundation - http://www.openinfosecfoundation.org
Emerging Threats Pro, INC - http://www.emergingthreatspro.com
------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20101225/b0854eae/attachment-0002.html>