Yesterday I pushed a patch that changes the default runmode from “auto” to “autofp”. The autofp name stands for “auto flow pinning” and it automatically makes sure all packets belonging to a flow are processed by the same stream, detection and output thread. Until now, the assignment was done with a simple hash calculation. The problem with that is that it doesn’t take into account how busy a thread may be.
OISF’s Anoop Saldanha recently wrote a new load balancer, called “active-packets”, which is now the default. Before assigning a new flow to a thread, it checks how busy it is. This leads to a much more fair distribution of flows and packets.
AutoFP - Total flow handler queues - 6
AutoFP - Queue 0 - pkts: 82879145 flows: 30589
AutoFP - Queue 1 - pkts: 36997716 flows: 4042
AutoFP - Queue 2 - pkts: 22168624 flows: 356
AutoFP - Queue 3 - pkts: 36886948 flows: 40
AutoFP - Queue 4 - pkts: 22135664 flows: 118
AutoFP - Queue 5 - pkts: 22121314 flows: 101
In the example above it’s clearly visible that the number of flows assigned to queues (and thus threads) varies greatly. However the number of packets varies much less. It may appear that Queue 0 is somewhat oversubscribed, but remember that the queue is selected based on how busy it is. In this case the IDS box is not very busy, so queue 0 was available most of the time.
The output above is displayed at shutdown if you use the (now default) “autofp” mode. Take a look at it to see if the load balancing makes sense in your setup!
We recently set up a Planet for Suricata, see the official announcement here.
All my posts tagged “suricata” will automatically appear on it. Excited about it!
My ISP recently started providing 3 F-Secure AV copies to each of their customers. I installed it but noticed that updates timed out.
It turned out that Suricata, which runs in IPS mode, blocked the update. There were 3 Emerging Threats rules that alerted:
[1:2003614:4] ET VIRUS WinUpack Modified PE Header Inbound
[1:2009557:2] ET TROJAN Yoda’s Protector Packed Binary
[1:2012086:2] ET SHELLCODE Possible Call with No Offset TCP Shellcode
It seems that F-Secure uses some form of packed binaries for their updates that is often used by malware.
To allow the updates to go through without disabling the rules altogether, we can use suppressions. All the alerts happened in streams talking to IP addresses in the 18.104.22.168x range. Whois lookup suggested that F-Secure has 22.214.171.124/25 available, so I decided to suppress the rules for that entire block.
To add the suppressions, I added the following lines to my threshold.conf:
# f-secure update matching
suppress gen_id 1, sig_id 2009557, track by_src, ip 126.96.36.199/25
suppress gen_id 1, sig_id 2012086, track by_src, ip 188.8.131.52/25
suppress gen_id 1, sig_id 2003614, track by_src, ip 184.108.40.206/25
After a Suricata restart, the updates now work fine. If you run Suricata in IDS mode you may still want to add the suppressions to reduce the number of alerts.