BitBlazr: Monitoring Rules

BitBlazr features a powerful logging engine, allowing users to configure different logging targets and separate regular events from alerts and errors. Logs can output to standard out (stdout), a file, or be sent to the cloud over MQTT connection. They can be in different formats - from "compact" to "json", to "cloud_events".

Apart from basic log target definitions, the sensor also features a full log rule engine, giving customers ultimate flexibility regarding what to log, what to ignore, and what alerts to raise.

Log target definitions

Log target definitions are stored in the main config file . Separate targets can be defined for different log classes. Currently, supported log classes are:

default - this is the only required logging class configuration, if the other classes are missing, the default will be used.
errors - if this log class is configured, errors will be sent to the configured target.
alerts - if this log class is configured, alerts will be sent to the configured target.
events - if this log class is configured, all remaining events will be sent to the configured target.

Each target class can take the following options:

enable - has to be set to "true" to enable the logging class.
target - defines a logging target, values can be: "stdout", "stderr", "file", or "mqtt".
format - log format can be: "full", which is also a default, "compact", "pretty", "json", or "cloudevents". More information on CloudEvents can be found here: https://cloudevents.io/
directory - directory where the log files will be created. This option can only be used for the "file" target.
prefix - log file prefix. This option can only be used for the "file" target.
rotation - Desired file rotation, supported values are: "hourly", "daily", and "never". This option can only be used for the "file" target.
max_files - If file rotation is enabled, this defines how many files to keep. This option can only be used for the "file" target.
mqtt_uri - URI for MQTT client. This option can only be used for "mqtt" target.
mqtt_user - Username to be used by the MQTT client. This option can only be used for "mqtt" target.
mqtt_pwd - Depending on the service used this will be either a password or JWT token used by the MQTT client. This option can only be used for "mqtt" target.
mqtt_topic - Topic uses by MQTT cl. This option can only be used for "mqtt" target.

​Rule Definitions

In addition to log target configuration, specific rules for events and alerts can be configured. This is also where non-blocking security rules, such as ones that rely on timing information, are configured, Example rules can be found here .
The rule engine also allows one to configure "ignore" rules to silence a noisy endpoint.
In other words, this is where one defines what one would like to log or alert on. Or what should be ignored...
Matching is sequential, thus if one configured "ignore" rules, they should go in front of broader log or alert rules.
Actions available here are: 'log', 'alert', or 'ignore', and unlike the kernel side we can match on arrays not just individual entries.

- class: file
  event: exit
  directives:
    path:
      starts_with:
      - /bin
      - /sbin
      - /usr/bin
      - /usr/sbin
      - /usr/local/bin
      - /usr/local/sbin

Monitoring Rule Example

This rule will result in a logging event associated with executing files that start with one of the included path definitions.

Classes and event types

Global Targets

Global targets can be used by any event class. The following global targets are supported:

uid - system user identifier associated with the process.
gid - system group identifier associated with the process.

 

"File" class

File class supports three event types: "exec", "exit" and "open".

"exec" allows matches on command execution, "exit" matches a command termination event, and "open" allows tracking of files being opened by various applications.

The class supports the following match targets:
path - match on the path of a file that is being executed or opened.
exit_code - match available on the "exit" event.
run_time - available on the "exit" event, allows a match against time from process start to exit. Time is in seconds.

"Socket" class

Socket class supports two event types: "listen" and "connect". "listen" detects new ports being open and "connect" matches on connections initiated from the monitored device.

The class supports the following match targets:

ip_type - a type of the IP a connection is attempted to. The values can be: "private", "public", "loopback", and "multicast".
ip_version - can be either "4" or "6".
ip_proto - IP protocol, at this time "tcp", "udp", and "icmp" are supported.
ip_addr - IP address in string form, can include netmask.
port - destination port number (integer) of the connection being made. Or the port number of the new socket.

Matches

Each match target can have an array of matches associated with it. Different matches can be applied to strings and integers.

String matches

The following string matches are currently supported by kernel rules:

contains - matches a string that starts with provided "needle".
starts_with - matches a string that starts with provided "needle".
ends_with - matches a string that ends with provided "needle".
eq - matches an entire string against provided "needle".
neq - negative match, only matches if a string does not match provided "needle".

Integer matches

These are matches supported by integers:
eq - checks if an integer is equal to the provided value.
neq - checks if an integer is not equal to the provided value.
lte - checks if an integer is less or equal to the provided value.
gte - checks if an integer is greater or equal to the provided value.

not:
  starts_with: /usr/bin

Negative match example

A match can be flipped to a negative match by wrapping it in "not" object.