[Oisf-users] Suricata treating two flows as one?

[Duane Howard]

This makes, sense, but if the content I'm looking for occurs twice in that
'session' should I not get a second alert? Is there something that says
'only alert once every so often'?
I've got an empty threshold.config so I'm unsure of anything that might be
built in to cause this...

./d

On Thu, Nov 13, 2014 at 11:10 AM, Victor Julien <lists at inliniac.net> wrote:

> On 11/13/2014 07:29 PM, Duane Howard wrote:
> > In a test pcap, I have two distinct sessions (neither is closed) that
> > look something like:
> >
> > SYN, SYN-ACK, ACK, HTTP-GET
> > SYN, SYN-ACK, ACK, HTTP-GET
> >
> > They do both have the same 5-tuple so they'd look like the same session
> > if there wasn't a new 3-way handshake. (imo the second three-way
> > handshake should kill the first session and start a new one).
>
> Until the flow engine times out a TCP sesssion, we consider SYN packets
> on such sessions erroneous. The time out is controlled by:
>
> flow-timeouts:
>   tcp:
>     new: 60
>     established: 3600 # <- this
>     closed: 120
>
> Only if the TCP state has moved to CLOSED, which is after a
> successful/valid FIN handshake or RST, new SYN's are accepted. In this
> case we do reuse the flow structure itself, but reset the TCP session.
> This will lead to an increment of the tcp.reuse counter in your stats.log.
>
> > Snort will alert twice (once per flow) but Suricata will only alert once
> > and the recorded time seems to be the time of the packet at the final
> > ACK for the second flow. Where snort's alert times map directly to the
> > packet times of the GET request that my rule is looking for.
> >
> > I'm still new to Suricata, is there some flow/sessionization setup
> > configuration I'm missing that would cause this behavior? I'm on 2.0.4
> > built from source. Also, why would the alert time in the fast.log map to
> > a packet *after* the suspect content?
>
> In IDS mode we inspect the HTTP session based on stream reassembly,
> which runs on ACK'd data. So only after the ACK do we inspect most of
> the rules.
>
> There is some separate logic for when the flow ends (times out) w/o that
> ACK.
>
> --
> ---------------------------------------------
> 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
> Training now available: http://suricata-ids.org/training/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20141113/9a6681a5/attachment-0002.html>