<div dir="ltr">Nevermind. These a bug in our generator that switched source addresses here from <span style="font-family:arial,sans-serif;font-size:13px">172.18.153.6</span><span style="font-family:arial,sans-serif;font-size:13px"> to </span><span style="font-family:arial,sans-serif;font-size:13px">172.26.223.15</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">./d</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 9:18 AM, Duane Howard <span dir="ltr"><<a href="mailto:duane.security@gmail.com" target="_blank">duane.security@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm back again. =)<div><br></div><div>While processing a pcap that has 1 session, 5 packets Suricata seems to be treating this flow as two unique flows and assigning to two different flow handler queues:</div><div><br></div><div>$ suricata -c configs/suricata.yaml -r test.pcap</div><div><snip></div><div><div>14/11/2014 -- 17:10:26 - <Notice> - Pcap-file module read 5 packets, 614 bytes</div><div>14/11/2014 -- 17:10:26 - <Info> - AutoFP - Total flow handler queues - 6</div><div>14/11/2014 -- 17:10:26 - <Info> - AutoFP - Queue 0  - pkts: 3            flows: 1           </div><div>14/11/2014 -- 17:10:26 - <Info> - AutoFP - Queue 1  - pkts: 2            flows: 1           </div><div><snip></div><div>14/11/2014 -- 17:10:26 - <Info> - Stream TCP processed 3 TCP packets</div><div>14/11/2014 -- 17:10:26 - <Info> - Fast log output wrote 0 alerts</div><div>14/11/2014 -- 17:10:26 - <Info> - (Detect1) Alerts 0</div><div>14/11/2014 -- 17:10:26 - <Info> - Alert unified2 module wrote 0 alerts</div><div>14/11/2014 -- 17:10:26 - <Info> - Stream TCP processed 2 TCP packets</div><div>14/11/2014 -- 17:10:26 - <Info> - Fast log output wrote 0 alerts</div></div><div><snip></div><div><br></div><div>$tcpdump -n -r test.pcap</div><div><div>01:13:01.020098 IP 172.18.153.6.28865 > 222.173.116.208.80: Flags [S], seq 4179007559, win 65535, length 0</div><div>01:13:01.020128 IP 222.173.116.208.80 > 172.18.153.6.28865: Flags [S.], seq 2638191351, ack 4179007560, win 65535, length 0</div><div>01:13:01.020159 IP 172.18.153.6.28865 > 222.173.116.208.80: Flags [.], ack 1, win 65535, length 0</div><div>01:13:01.020188 IP 172.26.223.15.28865 > 222.173.116.208.80: Flags [P.], seq 4179007560:4179007904, ack 2638191352, win 65535, length 344</div><div>01:13:01.020220 IP 222.173.116.208.80 > 172.26.223.15.28865: Flags [P.], ack 344, win 65535, length 0</div></div><div><br></div><div>The content of that 4th packet should generate an alert (and does in Snort), I'm thinking because I check for 'flow:established,to_server' this is failing because the 5 packets (1 session) are assigned to two different Detect threads? Since one detect thread would see the three-way handshake and the other sees the HTTP content I'm looking for?</div><div><br></div><div>These are generated pcaps, not from real traffic, but everything *should* look like real traffic.</div><div><br></div><div>Thoughts?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>./d</div></font></span></div>
</blockquote></div><br></div>