[Oisf-users] EXTERNAL: Re: Making Suricata Alert Per Matching Packet

Fri May 6 06:58:42 UTC 2016

On 25-04-16 09:51, Darren S. wrote:
> In situations where multiple different rules might match a single
> packet or stream or transaction, does Suricata allow each possible
> rule to be matched to the target and an alert to be generated for each
> matching rule? Or is this short-circuited based on the logic you
> describe?
> 
> For example:
> 
> Payload contains string "abc".
> 
> Rule 1: content:"a";
> 
> Rule 2: content:"b";
> 
> Rule 3: content:"c";
> 
> When that payload is encountered by the engine, are 3 individual
> alerts generated or only one for the first matching rule?

All three rules will generate an alert.

Exception is that when one of the rules is a 'pass' rule, it's evaluated
first and bypasses the rest.

Cheers,
Victor

> 
> - Darren
> 
> On Tue, Apr 12, 2016 at 10:39 AM, Victor Julien <lists at inliniac.net> wrote:
>> Hi all,
>>
>> On 12-04-16 18:27, Cooper F. Nelson wrote:
>>> I suspect it's just that the stream tracker is designed to only generate
>>> one alert per flow.  I would even say this is expected behavior.
>>
>> As this is a common source of confusion, here's a little overview. TL;DR
>> it's complicated.
>>
>>
>> Suricata has different classes of rules
>>
>> 1. ip-only rules. Rules that only inspect header properties that stay
>> static over the lifetime of a (bidirectional) flow are inspected in a
>> separate inspection engine. This will only inspect the first packet in
>> each flow direction.
>>
>> Rule keywords like ttl will exclude a rule from the ip-only engine, as
>> this is a per packet property. Also if the if the flow engine runs out
>> of memory, we fall back to per packet inspection.
>>
>>
>> 2. stateful rules
>>
>> a. tx aware
>>
>> Transaction based protocols (e.g. HTTP/1.1) will inspect protocol aware
>> rules once per transaction. In the HTTP example a http_uri rule will be
>> inspected again each TX, so against each URI. If a rule has a URI match
>> and a BODY match, the state of this matching process is stored in the
>> flow structure so that the URI can match when we see packet X and the
>> BODY when we see packet X+1000.
>>
>> b. other
>>
>> A couple of protocol implementations are not tx-aware (e.g. ssh). These
>> will match max once per flow.
>>
>>
>> 3. raw content inspection
>>
>> Raw content inspection means the pattern matching and other content
>> inspection keywords (e.g. content, isdataat, pcre) that are not used to
>> look at a HTTP buffer or similar, but simply at packet and reassembled
>> stream payloads.
>>
>> A simple rule like 'alert tcp any any -> any any (content:"abc";) will
>> by default be inspected against the reassembled stream only. However,
>> one exception is that when the stream engine wasn't able to add a packet
>> to it's state, the packet payload is inspected.
>>
>> Some rule keywords will force the inspection against packets. For
>> example 'dsize' is only valid for packets, so if this appears in a rule
>> the rule will only be evaluated against the packet payload. Another is
>> 'alert tcp-pkt ... '. The opposite is also possible, 'alert tcp-stream
>> ...' will force only stream inspection.
>>
>> The stream inspection happens in chunks that are larger than a single
>> packet generally. This is controlled by toserver-chunk-size and it's
>> toclient opposite in the stream config section.
>>
>> For per packet payload inspection, those rules are inspected per packet
>> that has a payload.
>>
>>
>> To further complicate matters there is the mpm stage. The multi pattern
>> matching stage (some refer to it as fast_pattern) makes sure that only
>> those rules that have a remote chance of matching are evaluated
>> individually. So a rule may not appear to be inspected at all, but this
>> is because the fast pattern of the rule didn't appear in the payload.
>>
>> To even further complicate things, Suricata does more 'prefilter' things
>> to avoid having to look at rules individually.
>>
>>
>> 4. the rest
>>
>> The rest should be rules that for example look at the ttl field. Those
>> should be inspected against all packet that have a remote chance of
>> matching. So a tcp specific keyword (flags) will not be inspected
>> against UDP packets.
>>
>>
>>
>> Some helpful tools:
>>
>> Runtime option --list-keywords=all will give you list including which
>> keywords are 'ip-only compatible'.
>>
>> Runtime option --engine-analysis will dump some info about the loaded
>> rules into your log directory
>>
>> Compile time option --enable-profiling will give you a lot more info
>> about how often rules are inspected. There are per rule, per rule
>> keyword and packet profiling outputs.
>>
>>
>> I'm open to ideas how we can make this easier to grasp (other than
>> documentation). I'd be happy to create some new analysis output to give
>> more insights into how Suri sees a rule.
>>
>> Cheers,
>> Victor
>>
>>
>> --
>> ---------------------------------------------
>> Victor Julien
>> http://www.inliniac.net/
>> PGP: http://www.inliniac.net/victorjulien.asc
>> ---------------------------------------------
>>
>> _______________________________________________
>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> Suricata User Conference November 9-11 in Washington, DC: http://oisfevents.net
> 
> 
> 

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