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

[Ken Steele]

It seems like some alert should be generate for a second SYN on the same 5-tuple, since that is unusual.

-Ken

> On Nov 13, 2014, at 2:17 PM, Duane Howard <duane.security at gmail.com> 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...
> 
> ./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/
> 
> _______________________________________________
> 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/f6ed6521/attachment-0002.html>