BitNinja CloudConfiguration

Overview

BitNinja CloudConfiguration is a centralized configuration management system for BitNinja agents across multiple servers. It allows administrators to manage security rules, firewall policies, and module settings centrally via the BitNinja dashboard instead of editing config files individually on each server. You can define settings at different levels (account‑level, server‑group level, or per‑server), and then when a BitNinja agent runs on a server, it fetches the configuration from the cloud.

Key benefits:

• Centralized management of configurations.
• Consistent security policies across servers.
• Easy scaling for multiple servers.
• Automatic synchronization with BitNinja agents.

Local edits vs cloud configs

You can modify module configs directly on the server (i.e. manually edit the config.ini files).

If you want to keep local changes and sync them to the cloud (so the cloud copy matches local), there’s a CLI command:
bitninjacli --syncconfigs
After that, you should also reload the module to apply changes:
bitninjacli --module=ModuleNameHere --reload

If later you change that module’s configuration via the BitNinja dashboard (cloud) the cloud config will overwrite the local manual changes.

Binary (State-based) Configurations

Definition: Settings that have a single state, typically on/off, or options like auditd vs inotify.
Behavior:
BitNinja State-based configurations support hierarchical configuration:
Server-level: highest priority, overrides all other levels.
Server-group level: overrides account-level but can be overridden by server-level.
Account-level: global defaults for all servers, lowest priority.
Default: Newly created accounts will inherit the recommended BitNinja configurations.

Example:

• The module Malware Scanner is set to disabled on a server.
• You try re-enabling/disabling the module multiple times at the server group or account level.
• Result: The module will still be set as disabled on that server, even as a new setting has been applied on higher levels.

Key takeaway:

For binary configurations, the last applied value is authoritative, even if a lower-level configuration was previously set.

Array-based Configurations

Definition: Settings that allow multiple entries in a list, such as excluded malware paths, whitelisted URLs, or excluded ports, etc.

Behavior:

• Entries from all levels are combined.
• The final applied configuration is a union of all entries from account, group, and server levels.

Example:

• Account-level excluded malware paths: /var/log
• Server group-level excluded paths: /home/user/tmp
• Server-level excluded paths: /opt/data
• Result: On the server, all three paths are excluded (/var/log, /home/user/tmp, /opt/data).

Key takeaway:

For array configurations, entries are cumulative, not overwritten.

MaxVersion Feature

The MaxVersion feature allows developers to tie specific configurations to agent versions. This ensures that certain settings are only applied to servers running agents up to a defined version, while newer agents may receive updated or different configurations.

Each configuration can now include a MaxVersion=X.Y.Z attribute.

Configurations are applied only to agents whose version is ≤ MaxVersion.

Agents with higher versions ignore configurations that are restricted by MaxVersion, allowing new or updated values to be applied instead.

For user-level or server-group-level configurations, the system always considers the latest agent version in that scope while opening the page. However, the downloaded configurations will always match the ones you see at the individual server levels.

Example: If a server group has agents 3.12.0, 3.13.0, 3.13.13, then configurations with MaxVersion=3.13.0 apply only to the first two agents, while 3.13.13 ignores them.