[Oisf-users] single flow treated as two?

Duane Howard duane.security at gmail.com
Fri Nov 14 17:21:23 UTC 2014


Nevermind. These a bug in our generator that switched source addresses here
from 172.18.153.6 to 172.26.223.15

./d

On Fri, Nov 14, 2014 at 9:18 AM, Duane Howard <duane.security at gmail.com>
wrote:

> I'm back again. =)
>
> 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:
>
> $ suricata -c configs/suricata.yaml -r test.pcap
> <snip>
> 14/11/2014 -- 17:10:26 - <Notice> - Pcap-file module read 5 packets, 614
> bytes
> 14/11/2014 -- 17:10:26 - <Info> - AutoFP - Total flow handler queues - 6
> 14/11/2014 -- 17:10:26 - <Info> - AutoFP - Queue 0  - pkts: 3
>  flows: 1
> 14/11/2014 -- 17:10:26 - <Info> - AutoFP - Queue 1  - pkts: 2
>  flows: 1
> <snip>
> 14/11/2014 -- 17:10:26 - <Info> - Stream TCP processed 3 TCP packets
> 14/11/2014 -- 17:10:26 - <Info> - Fast log output wrote 0 alerts
> 14/11/2014 -- 17:10:26 - <Info> - (Detect1) Alerts 0
> 14/11/2014 -- 17:10:26 - <Info> - Alert unified2 module wrote 0 alerts
> 14/11/2014 -- 17:10:26 - <Info> - Stream TCP processed 2 TCP packets
> 14/11/2014 -- 17:10:26 - <Info> - Fast log output wrote 0 alerts
> <snip>
>
> $tcpdump -n -r test.pcap
> 01:13:01.020098 IP 172.18.153.6.28865 > 222.173.116.208.80: Flags [S], seq
> 4179007559, win 65535, length 0
> 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
> 01:13:01.020159 IP 172.18.153.6.28865 > 222.173.116.208.80: Flags [.], ack
> 1, win 65535, length 0
> 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
> 01:13:01.020220 IP 222.173.116.208.80 > 172.26.223.15.28865: Flags [P.],
> ack 344, win 65535, length 0
>
> 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?
>
> These are generated pcaps, not from real traffic, but everything *should*
> look like real traffic.
>
> Thoughts?
>
> ./d
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20141114/315891bd/attachment-0002.html>


More information about the Oisf-users mailing list