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

Victor Julien lists at inliniac.net
Thu Nov 13 19:31:33 UTC 2014


On 11/13/2014 08:25 PM, Ken Steele wrote:
> It seems like some alert should be generate for a second SYN on the same
> 5-tuple, since that is unusual.

It should trigger:
alert tcp any any -> any any (msg:"SURICATA STREAM ESTABLISHED SYN
resend with different seq"; stream-event:est_syn_resend_diff_seq;
classtype:protocol-command-decode; sid:2210027; rev:2;)

Cheers,
Victor


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




More information about the Oisf-users mailing list