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

[Victor Julien]

On 11/13/2014 08:17 PM, Duane Howard wrote:
> 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...

Depends on the rule, but a typical HTTP sig wouldn't fire twice as we're
not tracking the 2nd session. We're not tracking it because the TCP
engine rejects the packets for the reasons below.

Cheers,
Victor

> ./d
> 
> On Thu, Nov 13, 2014 at 11:10 AM, Victor Julien <lists at inliniac.net
> <mailto: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
>     <mailto: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/
> 
> 


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