Good morning,
Suricata is getting traffic from our configured SPAN ports on our core switches, but in the FAST log, most of what we see is
“SURICATA STREAM pkt seen on wrong thread”
Is there a setting in Suricata to help it figure this out?
Details? Read on.
We’re running Suricata v6 on Ubuntu 20.04.3 on ESXi 6.7u3
We have a pair of core switches that are set up with SPAN ports configured to send traffic to a specific physical NIC on an ESXi host. These NICs are in a port group with a virtual vmxnet nic attached to the Suricata VM.
All traffic crossing a switch has traffic mirrored out that port and sent to ESXi.
Both switches are trunked together and trunked up to our firewalls and down to the ‘edge’ switches (aka desktop/distribution).
This is working, to a point, Suricata can see traffic crossing internal subnets and to/from the Internets.
SURICATA STREAM pkt seen on wrong thread [] [Classification: (null)] [Priority: 3] {TCP} 10.11.0.8:58545 → 10.200.20.253:444
SURICATA STREAM pkt seen on wrong thread [] [Classification: (null)] [Priority: 3] {TCP} 10.11.0.201:59495 → 142.44.1.88:443
I’m quite certain what is going on is that due to the way the firewalls and switches are uh, Forti-Trunked, packet streams are going from one switch to another, and then Suricata is getting them on different capture threads - and it doesn’t like that.
Thank you in advance for your help.
Relevant (I think) suricata.yaml config sections:
Under common capture config:
af-packet
-interface:ens192
-threads: auto
-cluster-id:99
-cluster-type: cluster_flow
-defrag: yes
-use-mmap: yes
-buffer-size: 65536
-interface: ens224
Advanced tracking section:
Defrag:
-memcap:256mb
-hash-size: 65536
-trackers: 65535
-max-frags 65535
-prealloc: yes
-timeout:60
Flow:
memcap: 256mb
hash-size: 65536
prealloc: 10000
emergency-recovery: 30
vlan: use-for-tracking: true
stream:
memcap: 256mb
checksum-validation: yes
inline: auto
reassembly:
memcap: 256mb
depth: 100mb
toserver-chunk-size: 2560
toclient-chunk-size: 2560
randomize-chunk-size: yes
pfring:
interface: ens192
threads: auto
cluster-id;99
cluster-type: cluster_flow
checksum-checks: auto
Second interface
- interface: ens224
threads: auto
cluster-id: 99
cluster-type: cluster_flow