[Oisf-devel] assymmetric flow, app layer event, ...

[Victor Julien]

On 03/15/2013 06:03 PM, Carl Soeder wrote:
> I’m writing an application layer module that trigger events, and I was
> puzzled why I wasn’t seeing alerts despite running packets through that
> triggered event and loading rules to generate alerts when the events are
> triggered.
> 
> I discovered that SigMatchSignatures is fussy about flow being
> established before signaling a match. This fussiness creates unexpected
> behavior on asymmetric flows: missing alerts and alerts associated with
> the wrong packet.

In TCP stream we have the aync mode, but for other protocols we don't
have something similar. For those the flow engine does consider a flow
established if it has seen traffic from both sides. I guess we could add
a "async" mode here as well.


> Another thing I noticed that surprised me is that events are associated
> with flows but don’t carry information about the packet. Combine this
> with fussiness about flow, and alerts can generated for events that
> refer to the wrong packet. Consider a packet at the start of the flow
> that causes the application layer module to generate an event. Because
> the flow hasn’t been established, an alert won’t be generated for the
> packet. But the event is still pending so an alert may be generated for
> another packet in the flow once flow is established.
> 
>  
> 
> Does Suricata have ambitions to work correctly in the presence of
> asymmetric flows?

As much as possible, ya. The problem is that in some cases it is hard to
do. In normal IDS mode we don't send TCP data to the app layer until it
is ACK'd, so by definition _after_ the packet(s) containing the data
have passed us. Add IP fragmentation and it's even more the case.

As soon as we start looking into reassembled TCP stream, parsed and
normalized app layer traffic, I think the packet context is much less
important. Packets cane come in in any form or shape, but after
reassembly and normalization it's the high level data that matters.

Another case where you may have alerts after you expect them is when
flows time out. At flow timeout we do our final inspection on any
unreassembled TCP segments and app layer state updates what may result
from closing the flow. As this is a timeout condition, and not triggered
by actual traffic, we can't associate it with a real packet. So we
inject a fake pkt into the engine (2 actually, once for each direction).

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