<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>