<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>It seems like some alert should be generate for a second SYN on the same 5-tuple, since that is unusual.</div><div><br></div><div>-Ken</div><div><br>On Nov 13, 2014, at 2:17 PM, Duane Howard <<a href="mailto:duane.security@gmail.com">duane.security@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">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'?<div>I've got an empty threshold.config so I'm unsure of anything that might be built in to cause this...</div><div><br></div><div>./d</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 11:10 AM, Victor Julien <span dir="ltr"><<a href="mailto:lists@inliniac.net" target="_blank">lists@inliniac.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/13/2014 07:29 PM, Duane Howard wrote:<br>
> In a test pcap, I have two distinct sessions (neither is closed) that<br>
> look something like:<br>
><br>
> SYN, SYN-ACK, ACK, HTTP-GET<br>
> SYN, SYN-ACK, ACK, HTTP-GET<br>
><br>
> They do both have the same 5-tuple so they'd look like the same session<br>
> if there wasn't a new 3-way handshake. (imo the second three-way<br>
> handshake should kill the first session and start a new one).<br>
<br>
</span>Until the flow engine times out a TCP sesssion, we consider SYN packets<br>
on such sessions erroneous. The time out is controlled by:<br>
<br>
flow-timeouts:<br>
tcp:<br>
new: 60<br>
established: 3600 # <- this<br>
closed: 120<br>
<br>
Only if the TCP state has moved to CLOSED, which is after a<br>
successful/valid FIN handshake or RST, new SYN's are accepted. In this<br>
case we do reuse the flow structure itself, but reset the TCP session.<br>
This will lead to an increment of the tcp.reuse counter in your stats.log.<br>
<span class=""><br>
> Snort will alert twice (once per flow) but Suricata will only alert once<br>
> and the recorded time seems to be the time of the packet at the final<br>
> ACK for the second flow. Where snort's alert times map directly to the<br>
> packet times of the GET request that my rule is looking for.<br>
><br>
> I'm still new to Suricata, is there some flow/sessionization setup<br>
> configuration I'm missing that would cause this behavior? I'm on 2.0.4<br>
> built from source. Also, why would the alert time in the fast.log map to<br>
> a packet *after* the suspect content?<br>
<br>
</span>In IDS mode we inspect the HTTP session based on stream reassembly,<br>
which runs on ACK'd data. So only after the ACK do we inspect most of<br>
the rules.<br>
<br>
There is some separate logic for when the flow ends (times out) w/o that<br>
ACK.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
---------------------------------------------<br>
Victor Julien<br>
<a href="http://www.inliniac.net/" target="_blank">http://www.inliniac.net/</a><br>
PGP: <a href="http://www.inliniac.net/victorjulien.asc" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br>
---------------------------------------------<br>
<br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
Training now available: <a href="http://suricata-ids.org/training/" target="_blank">http://suricata-ids.org/training/</a><br>
</font></span></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a></span><br><span>Site: <a href="http://suricata-ids.org">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/">http://suricata-ids.org/support/</a></span><br><span>List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a></span><br><span>Training now available: <a href="http://suricata-ids.org/training/">http://suricata-ids.org/training/</a></span></div></blockquote></body></html>