search

Security-Onion-Solutions / security-onion

Security Onion 16.04 - Linux distro for threat hunting, enterprise security monitoring, and log management
https://securityonion.net
3.06k stars 519 forks source link

NSM: add ability to pin snort via IDS_LB_CPUS #1729

Closed dougburks closed 4 years ago

dougburks commented 4 years ago

https://github.com/Security-Onion-Solutions/securityonion-nsmnow-admin-scripts/pull/28

dougburks commented 4 years ago

The following package is now available at ppa:securityonion/test:

securityonion-nsmnow-admin-scripts - 20120724-0ubuntu0securityonion226

Please test/verify as follows:

Inspired by the comments from https://github.com/Security-Onion-Solutions/securityonion-nsmnow-admin-scripts/pull/28:

After the updated package is installed, you can pin snort processes to specific CPUs by adding a line to the /etc/nsm/HOSTNAME-INTERFACE/sensor.conf file like:

IDS_LB_CPUS=1,3,5,7

and then (re)starting the Snort process(es) using sudo so-nids-start or sudo so-nids-restart.

In the example above, the first four snort processes would be pinned to the first four odd-numbered CPU cores. It validates the input as a number before using it, so if there are more than the specified number (eg 5), any processes without a CPU listed would have the default CPU affinity.

To test, you can move all processes to a specific set of CPUs using systemd's CPUAffinity setting in /etc/systemd/system.conf and specify values for --cpuset-cpus in the docker containers using the *_OPTIONS values in /etc/nsm/securityonion.conf. The htop utility can be useful for verifying that the CPUs not given there are idle. Then, you can test this setting and verify that the processes are moved to the CPUs idled earlier.

dougburks commented 4 years ago

You can also verify proper pinning using taskset -p PID where PID is the actual process ID of the Snort process you are checking. The default affinity mask is f, so if pinning is set properly you should see something other than that.

bryant-treacle commented 4 years ago

Everything tested good. I used the following command to check the cpu affinity. taskset -cp PID. It gave me the numerical list of processors instead of a bitmask. Just a little easier to read the results.

Tested IDS_LB_PROCS=3 IDS_LB_CPUS=1,3,5 Here each Snort process was pinned to an individual CPU

Tested IDS_LB_PROCS=3 IDS_LB_CPUS=1,3 The Snort-3 process took the default Affinity set in /etc/systemd/system.conf

The settings persisted through a reboot.

Ran so-test - IDS alerts were generated with no errors in logs or dropped packets.

dougburks commented 4 years ago

Thanks for testing @bryant-treacle !

dougburks commented 4 years ago

Published: https://blog.securityonion.net/2020/03/securityonion-nsmnow-admin-scripts.html