How to optimize BitNinja for weak servers

BitNinja needs about 1 GB of free RAM to run on a server. Read on to find out how to bypass this limitation. However, be warned — if you over-compress it, some BitNinja modules may reboot too often and others may run slower. This will affect the server's resistance to threats.

Limit memory consumption

You can limit memory consumption for some modules.

Malware Detection: antivirus. Scans files on the server to detect and quarantine malware. No manual configuration is needed — the antivirus databases are automatically updated daily. The antivirus program is developed by the vendor in-house without borrowing any solutions from other companies.

How to configure RAM consumption for the antivirus program:

1. Open the Configuration tab.
2. Select the Malware Detection module.
3. Set the desired value in the Memory limit in the MB field.
4. Save the changes by clicking the Save button at the top of the interface.

Shogun — this module accepts and passes incidents to the right places. For example, from captcha to IPfilter.

How to configure RAM consumption for the Shogun module:

1. Open the Configuration tab.
2. Select Advanced modules → Shogun.
3. Set the desired value in the Memory Limit for this Module field. The minimum threshold is 300 MB, the recommended value is 600 MB.
4. Save the changes by clicking the Save button at the top of the interface.

Certificate Miner is a component of the protection present on the HTTPS module. The miners collect information about SSL certificates for the protection used on the HTTPS module (SSL Termination) to operate correctly.

How to configure RAM consumption for Certificate Miner:

1. Open the Configuration tab.
2. Select Advanced modules → Certificate miner.
3. Set the desired value in the Memory limit for Certificate Miner (MB) field. The minimum threshold is 100 MB.
4. Save the changes by clicking the Save button at the top of the interface.

Using cloud AI scanning instead of an agent

BitNinja scans files using its own agent or AI. By default, cloud AI scanning is disabled. You can enable it to reduce the load on the server. The quality and speed by which infected files are found will remain the same as with the agent.

BitNinja will not scan files on the server but will send the MD5 hash files to a central server where they will be processed to find viruses.

How to enable cloud AI scanning:

1. Open the Configuration tab.
2. Click Malware Detection.
3. Turn on the toggle switches to enable the AI scanner feature and enable or disable the AI active scanner feature.
4. Save the changes by clicking the Save button at the top of the interface.

Limit CPU resources for the BitNinija agent

The server must support Cgroup for you to configure CPU resources, i.e., RAM. First, check whether the server supports Cgroup, find the necessary files, or create them.

Cgroup is a group of Linux processes where you can adjust the CPU load. A Cgroup can be v1 or v2. In v1, resource limits for a process are set in separate hierarchies for each resource class. It is usually used in older versions of Linux-based distributions. v2 implements a single hierarchy, simplifying the constraint structure for processes, and is used by default in newer distributions.

How to check whether the server supports Cgroup:

1.Execute this command in the console:

grep cgroup /proc/filesystems

2.Check the response — if the OS supports Cgroup, the response will contain this information:

nodev cgroup

Or

nodev cgroup2

If Cgroup is supported (Cgroup V1). Check whether the files cpu.cfs_period_us or cpu.cfs_quota_us exist. If not, they need to be created. We’ll get to that in the 3rd point.

How to find the files in different operating systems:

• In Debian: go to the /sys/fs/cgroup directory and run ls /sys/fs/cgroup or search in the file manager.

• In CentOs or Redhat: go to the /sys/fs/cgroup/cpu* directory and run ls /sys/fs/cgroup or search in the file manager.

If Cgroup2 (Cgroup V2) is supported. Check if the file cgroup.controllers exists. To do so, execute the cat /sys/fs/cgroup/cgroup.controllers command or find the file using a file manager.

The output from the command may look like this but it differs depending on the OS: cpuset cpu io memory hugetlb pids rdma

3.Create files if they do not exist:

• Create a configuration file in the grub.d directory with the echo "GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false" | sudo tee /etc/default/grub.d/cgroup.cfg command
• Update the configuration file with the sudo update-grub command
• Restart the server with the sudo reboot command

How to limit RAM resources for the BitNinja agent:

1. Open the Configuration tab.
2. Select Advanced modules → System.
3. Find the Resource usage line and set a value from 60 to 100. The higher the value, the more resources are available for BitNinja. If you change the resource usage, the antivirus may work slower.
4. Save the changes by clicking the Save button at the top of the interface.
5. Check the BitNinja agent log in the file /var/log/bitninja/main.log . There should be no errors related to the cgroup value in the file.

According to the vendor, limiting CPU resources is safe for the server.

Which resources cannot be limited?

Modules for which RAM consumption cannot be changed:

• WAF and HAproxy, which are used as a base on which the SSL-terminating module runs. If new connections take up a lot of resources to process but they are limited, the server may go down.

• The internal BitNinja Dispatcher and BitNinja-mq modules, which are used to run the program. Their resources cannot be limited, because it may cause loss of settings or failure in incident handling.

In all other cases, if a module consumes more resources than the set limits, the module will stop working. Besides, if you specify low values in the settings, API requests to BitNinja may not work properly; the server may not respond to requests.

If you have any questions on how to optimize Bitninja, write to us at help@ispmanager.com, we’re always ready to help.

This article was originally published on the ispmanager blog