Update zeekdeploy.sh to add warning to not directly edit node.cfg

[ObsidianKnife]

🗣 Description

Adds a warning to not directly edit node.cfg.

💭 Motivation and context

My Zeek instance was being reset to sub optimal settings via edits to node.cfg of unknown origin. This warning would have saved me a bit of time tracking down the script responsible for the changes.

🧪 Testing

ran modified script and node.cfg included warning without other content.

[mmguero]

Thanks for the update. What settings in node.cfg do you feel would ideally be user-definable so that I could preserve them or read them from another location and integrate them into node.cfg when it's created?

[ObsidianKnife]

I have a few ideas:

1. You could check for a special string in node.cfg to know you just need to leave it alone such as a line matching the regex"^## NOCLOBBER ##$" this very easy to do but cuts the user off from some of the advantages of the automation but after installation this may not be a big deal especially considering how updates are currently performed (i.e. reinstall)
2. You could implement more variables in /opt/sensor/sensor_ctl/control_vars.conf to correspond to the following:
   a. logger, manager, proxy and worker - pin_cpus
   b. worker lb_procs

The need for these is because I was experiencing a packet drop rate as high as 30% with 20 hardware cores working. I reduced this to 0.007% by dedicating 8 cores to worker processes and two dedicated to IRQ processing one of which is also doing logger and proxy processes while the other handles IRQ and and manager process. I told the kernel to not use these ten cores for anything so only zeek runs on them and the other ten cores are running the yara rules, clam_av etc. I would love to see this level of optimization in hedgehog but it seems like a heavier lift as the program would have to identify what cores are on the NUMA node that handles the PCI bus the capture card is on to reduce latency as that is what seems to be the limiting factor here. I have more details on this if you are interested, I am still tinkering with some of the finer points.

[mmguero]

Thanks for the suggestions. I'm going to open an issue on the subject for the implementation of more variables to expand from control_vars.conf into node.cfg.