[Oisf-users] Listening on multiple interfaces with Suricata

[ph1g]

ftr, this beats the pants off of creating a bonded interface - which is the
only way I have been able to accomplish this in the past and I've only
accomplished this on *nix systems.

Sometime last year I filed an issue with the snort team on duplicate packets
causing false negatives with stream reassembly. My terror subsided as it was
quickly addressed. Unfortunately I've worked with tens of critical IDS
devices that are monitoring SPAN sessions that can't be configured in away
to only provide one instance of a given packet. This increases load all the
way from the sending interface to stream reassembly in the IDS. Duplicate,
triplicate, and even quintiplicate packet instances should be handled even
when listening on one interface (please, please, please).

-Ben

On Sat, Dec 25, 2010 at 12:27 PM, Pablo <pablo.rincon.crespo at gmail.com>wrote:

> 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
> ------------------------------------
>
>
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110102/bafead8e/attachment-0002.html>