[Oisf-users] multiple alerts being logged to unified2

[Peter Manev]

On Mon, Mar 2, 2015 at 2:18 PM, Eric Leblond <eric at regit.org> wrote:
> Hi,
>
> On Mon, 2015-03-02 at 13:53 +0100, Peter Manev wrote:
>> On Wed, Feb 25, 2015 at 3:34 AM, Russell Fulton <r.fulton at auckland.ac.nz> wrote:
>> > Hi
>> >
>> > Is there a way to tell suri to log a single alert per ‘event’.  I am now seeing lots of cases where I get multiple alerts with different packet data for a single detection event.  Most of these are for
>>
>> Is it possible to give an example?
>>
>> > rules where the detection would have occurred on the reassembled stream so I assume that suri just dumps the stream buffer because it does not know which packet the data was in.
>
> There is currently no option to disable this behavior. It has been coded
> as it is because unified2 format does not allow to add values to an
> event.
>
> You should be able to use the event id to match the unified2 objects
> created in link with a Suricata alert.
>
>> >
>> > Many of these are for compressed content so the raw packet data is pretty useless anyway.  Since I am now getting suri to log pcaps and sucking them into moloch (spooling them to /run/shm) If I want to look at the stream I can get it from moloch.  BTW the packet capture spooled to moloch  seems to work well but it is still early days.
>> >
>> > I am using both fast and unified2 outputs.  I will probably soon move to eve and throw the lot in ES.  Will that suffer from the multiple alerts too?  I am guessing not since iirc eve does not log data by default.
>>
>> The number of alerts would be the same in ES.

Sorry  - I need to clarify - i meant number of alerts in fast log =
number of alerts in eve.json
ES will not have the same duplication problem as unified.

>
> Nope, the EVE format will contain one event per alert. All the stream
> data will be put in the "stream" key.
>
> BR,
> --
> Eric Leblond <eric at regit.org>
>



-- 
Regards,
Peter Manev