[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