Optimizing BitNinja
Optimizing BitNinja might be neccessary on low performance servers, hence this documentation page will be focusing on helping you to make BitNinja use the lowest possible resources on your server(s).
Noticed high load on your server?
On your first BitNinja installation, our MalwareDetection module will run a deep scan, which scans your server completely for any hidden or existing malwares. This is to ensure that your server is completely malware free. Once it is finished the load will drop back to the normal.
Please note that our system requirements are still very important key here to use BitNinja efficiently and have a healthy server protection.
Quickest way to limit BitNinja's resource usage
The feature understands values from 40-100. This represents the percentage of CPU time that the BitNinja agent can use overall. If no value is added or it is set to 100, then the feature is disabled.
If a value lower than 40 is added then the feature will set it to 40.
If the cpuUsageLimit is set to a value greater than 100, then it will be set to 100% which means the feature is disabled, and there is no limit given.
Kernel limitations
BitNinja's CPU limitation feature works on all Linux distributions supported by BitNinja, as long as Cgroup is enabled on your server.
How to Check if Cgroup is enabled and supported?
You can check if Cgroup is compatible with your system by running the following command on your server:
grep cgroup /proc/filesystems
If your system supports cgroupv1 or cgroupv2, you would see:
nodev cgroup
nodev cgroup2
Cgroup V1: On Debian-based servers, check the /sys/fs/cgroup directory if the cpu.cfs_quota_us or cpu.cfs_period_us files exist. On CentOS/Redhat systems the cpu.cfs_period_us or cpu.cfs_quota_us files are present in the /sys/fs/cgroup/cpu* directory.
Cgroup V2:
In case of cgroup v2 you can check for the existence of cgroup.controllers with ne next command:
cat /sys/fs/cgroup/cgroup.controllers
If the file exists the command's output should look similar to:
cpuset cpu io memory hugetlb pids rdma
If these directories do not exist, create a config file in the grub.d directory with the command below:
echo "GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false" | sudo tee /etc/default/grub.d/cgroup.cfg
Update grub: sudo update-grub
Reboot the server: sudo reboot
There are no known dangers of changing this setting.
After setting up the limit, you can check the BitNinja agent's main log file under /var/log/bitninja/main.log to ensure no Warning messages are referring to the cgroup value.
Memory Optimization
There is also a way to limit BitNinja's memory usage, but this is only possible for modules.
The following modules support memory limits:
- Malware Detection
- Backup
- Shogun
- Protection on HTTPS (SslTerminating) for CertMiners
Please be careful when adjusting these limitation to lower values as this can result in slower malware scans and other possible issues.
Exceptions
The WAF module's Nginx server cannot be limited in this manner as limiting them would make the server unavailable if the connections could not be accepted if serving them would mean crossing the CPU limit threshold. This means the limit does not affect the WAF module's Nginx workers and the HAproxy used by the SSL terminating module. Also, the BitNinja Dispatcher and bitninja-mq modules are not limited by the cpuUsageLimit variable, as limiting them might cause settings and incidents to be lost in some instances.
All other modules will use the CPU in a percentage lower than or the same as the cpuUsageLimit variable. The processes/workers that are running would cross the threshold and will be paused. This means setting the limit too low will slow down the malware scan.
Further limiting the Malware detection module's effect on the load with the module-specific settings is not recommended if the system-level CPU usage limitation is enabled. Applying both load reduction methods will significantly slow down the malware scans.
The limit will also affect the Inotify-wait file system monitor's CPU usage as well. However the AuditD file system monitor cannot be limited by this feature as it is outside of BitNinja.
After setting up a limit, the agent might start up slower after the agent was restarted or after the agent was updated. Also, setting the value too low might cause API request timeout errors and curl request timeout errors in any of the BitNinja logs. In such cases, the limit should be raised.