Как оптимизировать работу BitNinja для слабых серверов

Для работы BitNinja на сервере нужен примерно 1 ГБ свободной оперативной памяти. Рассказываем, как обойти это ограничение. Но предупреждаем —  если пережать, то одни модули  BitNinja могут чаще перезагружаться, а другие — работать медленнее. Это влияет на устойчивость сервера к угрозам.

Ограничиваем потребление памяти

Для некоторых модулей можно ограничить потребление оперативной памяти. 

Malware Detection — антивирус. Сканирует файлы на сервере, выявляет и убирает в карантин вредоносное программное обеспечение. Не нужна ручная настройка — антивирусные базы автоматически обновляются каждый день. Антивирус — собственная разработка вендора без заимствованных решений других компаний.

Как настроить потребление оперативной памяти для Malware Detection:

1. Открываем вкладку Configuration.
2. Выбираем модуль Malware Detection.
3. Меняем значение в поле Memory limit in MB.
4. Сохраняем изменения — кнопка Save появится в верхней части интерфейса.

Shogun — модуль принимает и передает инциденты в «правильные» места. Например, от капчи к IPfilter.

Как настроить потребление оперативной памяти для модуля Shogun:

1. Открываем вкладку Configuration.
2. Выбираем раздел Advanced modules → Shogun.
3. Меняем значение в поле Memory limit for this module. Минимальный порог — 300 МБ, рекомендованное значение — 600 МБ. 
4. Сохраняем изменения — кнопка Save появится в верхней части интерфейса.

Certificate miner — одна из частей модуля Protection on HTTPS. Майнеры собирают информацию о SSL-сертификатах для корректной работы модуля Protection on HTTPS (SSL Terminating).

Как настроить потребление оперативной памяти для Certificate miner:

1. Открываем вкладку Configuration.
2. Выбираем раздел Advanced modules → Certificate miner. 
3. Меняем значение в поле Memory limit for Certificate miner (MB). Минимальный порог — 100 МБ. 
4. Сохраняем изменения — кнопка Save появится в верхней части интерфейса.

Используем облачное AI-сканирование вместо агента

BitNinja сканирует файлы с помощью собственного агента или AI. По умолчанию облачное AI-сканирование отключено — его можно включить, чтобы снизить нагрузку на сервер. Качество и скорость поиска зараженных файлов останется таким же, как и с агентом.

BitNinja не будет сканировать файлы на сервере, а передаст MD5 хэш файлов на центральный сервер, где их просканируют на вирусы.

Как включить облачное AI-сканирование:

1. Открываем вкладку Configuration.
2. Нажимаем Malware Detection.
3. Включаем тумблеры в строках Enable or disable the AI scanner feature и Enable or disable the AI active scanner feature. 
4. Сохраняем изменения — кнопка Save появится в верхней части интерфейса.

Ограничиваем ресурсы CPU для агента BitNinija

Сервер должен поддерживать Cgroup, чтобы можно было настроить ресурсы CPU. Для этого нужно проверить, поддерживает ли сервер Cgroup, найти нужные файлы или создать их. 

Как проверить, поддерживает ли сервер Cgroup.

Выполняем команду в консоли:

grep cgroup /proc/filesystems

Получаем ответ — если ОС поддерживает Cgroup, то в ответе будет информация:

nodev   cgroup

или

nodev   cgroup2

Поддерживается Cgroup (Cgroup V1). Проверяем, существуют ли файлы cpu.cfs_period_us или cpu.cfs_quota_us. Если файлов нет, то их нужно создать — подробнее расскажем в 3 пункте.

Как найти файлы в разных операционных системах: 

• Debian. Переходим в директорию /sys/fs/cgroup и выполняем команду ls /sys/fs/cgroup. Или находим через поиск в файловом менеджере. 
   
• CentOs или Redhat. Переходим в директорию /sys/fs/cgroup/cpu* и выполняем команду ls /sys/fs/cgroup. Или находим через поиск в файловом менеджере.

Поддерживается Cgroup2 (Cgroup V2). Проверяем, существует ли файл cgroup.controllers — для этого выполняем команду cat /sys/fs/cgroup/cgroup.controllers или находим файл с помощью файлового менеджера.

Результат команды может быть таким — отличается в зависимости от ОС: cpuset cpu io memory hugetlb pids rdma

Создаем файлы, если их нет в директориях:

1. Создаем конфигурационный файл в директории grub.d командой echo "GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false" | sudo tee /etc/default/grub.d/cgroup.cfg
2. Обновляем конфигурационный файл командой sudo update-grub
3. Перезапускаем сервер командой sudo reboot

Как ограничить ресурсы оперативной памяти для агента BitNinja:

1. Открываем вкладку Configuration.
2. Выбираем Advanced modules → System.
3. Находим строку Resource usage и указываем значение  от 60 до 100. Чем выше значение, тем больше ресурсов доступно для BitNinja. Если поменять показатель Resource usage, то антивирус может работать медленнее. 
4. Сохраняем изменения — кнопка Save появится в верхней части интерфейса.
5. Проверяем лог агента BitNinja в файле /var/log/bitninja/main.log. В файле не должно быть ошибок, связанных со значением cgroup.  

По информации от вендора, ограничение ресурсов CPU безопасно для сервера.

Какие ресурсы нельзя ограничить

Модули, где нельзя настроить потребление оперативной памяти:

• Внутренние модули BitNinja Dispatcher и BitNinja-mq — используются для работы приложения. Их ресурсы нельзя ограничить, потому что это может привести к потере настроек или сбою обработки инцидентов. 
• HAproxy — используется как база для работы модуля SSL-terminating, и WAF. Если на обработку новых подключений уходит много ресурсов, а они ограничены — сервер может стать недоступным.  

Во всех остальных случаях, если модуль внутри Bitninja расходует больше ресурсов, чем установлено в лимитах — он остановит работу. И если указать низкие значения в настройках, то API-запросы к BitNinja могут работать некорректно — сервер может не отвечать на запросы.