[Oisf-users] Questions about suricata.yaml
Chris Boley
ilgtech75 at gmail.com
Sat Jun 30 13:39:36 UTC 2018
When I answered this post originally, it got me thinking:
If you set queues with your suricata start command, how does suricata
coordinate queue distribution across the IPTABLES “—queue-balance 0:3”
portion of the iptables command.
If one was to also add “—queue-cpu-fanout” option to the iptables command,
would that break the way iptables interacts with Suricata or cause
unpredictable behavior? Or would it help optimize. As I understand things,
the queue balance functionality can be based on flows OR CPUID.
Maybe this needs to be forked to a separate post, but I found this detail
intriguing.
Thoughts??
On Thu, Jun 28, 2018 at 8:57 AM Chris Boley <ilgtech75 at gmail.com> wrote:
> I’m not 100% sure if suricata does auto load balancer functionality on
> cores by default now? Maybe it does. I’m no SME on Suri.
>
> In nfqueue mode, can you not set —queue-balance 0:3 in iptables and run
> Suricata like; suricata -c /etc/suricata.yaml -S
> /etc/suricata/sample.rules -q 0 -q 1 -q 2 -q 3 -vv ?
>
> I was under the impression that nfqueue mode load balancing was achieved
> in this way? My thoughts on this are probably outdated. Could we help his
> performance by offering that as a method?
>
>
> On Thu, Jun 28, 2018 at 8:20 AM Amar Rathore - CounterSnipe Systems <
> amar at countersnipe.com> wrote:
>
>> Hello Tanaka
>>
>> The configuration you have described is something we use all the time. It
>> seems to work fine for us...even with most of the rules loaded.
>>
>> The main reason for bridging is the flexibility it offers....we bridge 6
>> interfaces together and any one of the can be in or out. Have to say we are
>> still on a previous version.
>>
>> I notice that you are loading 1 rule specifying the HOME_NET variable,
>> have you tried running with no rules loaded at all? Just to see if the base
>> configuration is all ok?
>>
>> Have you configured the HOME_NET variable?
>>
>> Is there a specific reason for using 'reject' as opposed to 'drop'?
>>
>> If all of that is good, then it may be something to do with V4.
>>
>> Just some thoughts.
>>
>>
>> Amar Rathore
>>
>> amar at countersnipe.com
>>
>> Delivering Suricata based Network Security.
>>
>> On June 28, 2018 at 3:34 AM tanaka yusuke <net1234 at hotmail.co.jp> wrote:
>>
>>
>> Hi.
>>
>> I am trying to build an IPS box at work using suricata, but my suricata
>> box is showing very poor performance for some reason.
>>
>> Measured performance with wrk (https://github.com/wg/wrk) in isolated
>> testing environment like this:
>>
>> client ---> suricata box ---> server
>>
>> With default suricata.yaml, the box throughput drops below 10% of a dumb
>> bridge configuration.
>> I tried to tweak some of suricata.yaml settings and found improvement
>> somehow but still way too low.
>> I would appreciate if you have any other suggestions for performance
>> improvement.
>> Thanks in advance.
>>
>> Suricata box:
>> OS: CentOS 7.5 (simple install)
>> suricata: version 4.0.4 (suricata-4.0.4-1.el7.x86_64)
>> CPU: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz (4Core/4Thread)
>>
>> Suricata launch procedure:
>> #> systemctl stop firewalld
>> #> iptables -A FORWARD -J NFQUEUE --queue-num 0
>> #> suricata -c /etc/suricata.yaml -S /etc/suricata/sample.rules -q 0
>> -vv
>>
>> Rules activated (/etc/suricata/sample.rules)
>> reject ip $HOME_NET any -> 192.168.10.142 any (msg:"test rules";
>> gid:10000; sid:10000; rev:1;)
>>
>> Testing patterns:
>> 1. suricata off (dumb bridge mode)
>> 2. suricata on (default suricata.yaml)
>> 3. suricata on (log suppressed)
>> 4. suricata on (log suppressed + cpu-affinity set)
>>
>> Results:
>> [client]# ./wrk -t10 -c1000 -d30s http://192.168.100.101/
>> Running 30s test @ http://192.168.100.101/
>> 10 threads and 1000 connections
>>
>> 1. 3296109 requests in 30.09s, 3.20GB read
>> Requests/sec: 109536.50
>> Transfer/sec: 108.85MB
>>
>> 2. 229685 requests in 30.10s, 228.24MB read
>> Requests/sec: 7630.75
>> Transfer/sec: 7.58MB
>>
>> 3. 341039 requests in 30.04s, 338.90MB read
>> Requests/sec: 11354.15
>> Transfer/sec: 11.28MB
>>
>> 4. 417160 requests in 30.03s, 414.54MB read
>> Requests/sec: 13892.03
>> Transfer/sec: 13.80MB
>>
>> Modifications to suricata.yaml:
>>
>> 3. suppressed log output
>> -----------------------------------------
>> stats:
>> enabled: no
>> outputs:
>> - eve-log:
>> enabled: no
>> -----------------------------------------
>>
>> 4. cpu-affinity setting added
>> -----------------------------------------
>> threading:
>> set-cpu-affinity: yes
>> cpu-affinity:
>> - management-cpu-set:
>> cpu: [ "all" ]
>> prio:
>> default: "low"
>> - receive-cpu-set:
>> cpu: [ "all" ]
>> prio:
>> default: "low"
>> - worker-cpu-set:
>> cpu: [ 1,2,3 ]
>> mode: "exclusive"
>> threads: 3
>> prio:
>> default: "medium"
>> - verdict-cpu-set:
>> cpu: [ 0 ]
>> prio:
>> default: "high"
>> -----------------------------------------
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>> Conference: https://suricon.net
>> Trainings: https://suricata-ids.org/training/
>>
>>
>>
>> _______________________________________________
>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>> Conference: https://suricon.net
>> Trainings: https://suricata-ids.org/training/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20180630/01eceb45/attachment.html>
More information about the Oisf-users
mailing list