Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NSM: add ability to pin snort via IDS_LB_CPUS #1729

Closed
dougburks opened this issue Mar 9, 2020 · 5 comments
Closed

NSM: add ability to pin snort via IDS_LB_CPUS #1729

dougburks opened this issue Mar 9, 2020 · 5 comments
Projects

Comments

@dougburks
Copy link
Contributor

@dougburks dougburks commented Mar 9, 2020

@dougburks dougburks changed the title NSM: add bility NSM: add ability to pin snort via IDS_LB_CPUS Mar 9, 2020
@dougburks dougburks added this to To do in 16.04.6.5 via automation Mar 9, 2020
dougburks added a commit to Security-Onion-Solutions/securityonion-nsmnow-admin-scripts that referenced this issue Mar 16, 2020
dougburks added a commit to Security-Onion-Solutions/securityonion-nsmnow-admin-scripts that referenced this issue Mar 16, 2020
@dougburks dougburks moved this from To do to In progress in 16.04.6.5 Mar 16, 2020
@dougburks

This comment has been minimized.

Copy link
Contributor Author

@dougburks dougburks commented Mar 16, 2020

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

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

Please test/verify as follows:

  • start with a 16.04 box with all stable updates applied

  • run through Setup, choosing Eval Mode

  • snapshot the VM if possible

  • add the test PPA:

sudo add-apt-repository -y ppa:securityonion/test
  • install all updates:
sudo soup -y

Inspired by the comments from Security-Onion-Solutions/securityonion-nsmnow-admin-scripts#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

This comment has been minimized.

Copy link
Contributor Author

@dougburks dougburks commented Mar 17, 2020

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.

@dougburks dougburks moved this from In progress to In Testing in 16.04.6.5 Mar 17, 2020
@bryant-treacle

This comment has been minimized.

Copy link

@bryant-treacle bryant-treacle commented Mar 18, 2020

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 dougburks moved this from In Testing to Tested in 16.04.6.5 Mar 19, 2020
@dougburks

This comment has been minimized.

Copy link
Contributor Author

@dougburks dougburks commented Mar 19, 2020

Thanks for testing @bryant-treacle !

@dougburks

This comment has been minimized.

Copy link
Contributor Author

@dougburks dougburks commented Mar 19, 2020

@dougburks dougburks closed this Mar 19, 2020
16.04.6.5 automation moved this from Tested to Done Mar 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
16.04.6.5
  
Done
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.