Skip to content

LoggingπŸ”—

Logging is controlled by several configuration keys. The configuration is stored at /etc/cryptosense-analyzer/config on each AQtive Guard VM.

For more configuration information, refer to the Configuration Key reference.

Important

It is strongly recommended to use identical configuration settings for all AQtive Guard machines in a high-availability setting.

Logging Configuration KeysπŸ”—

Key Required? Description
LOG_LEVEL Yes Minimal level of logs appearing in the output. Possible values: debug, info, warning, error, critical
LOG_FILE No If present, write logs to a file instead of journalctl.
LOG_ROTATE_DAILY No Requires LOG_FILE to be set. If set ‘true’, a new log file is created every day. Defaults to ‘false’.
LOG_ROTATE_MAX No Requires LOG_ROTATE_DAILY. Sets the maximum amount of log files that are kept. Old files are automatically deleted.
LOG_LEVEL_AUDIT No Defaults to “info”. Minimal level of audit logs.
LOG_FILE_AUDIT No If present, write audit logs to a file instead of journalctl.
LOG_ROTATE_DAILY_AUDIT Β No Requires LOG_FILE_AUDIT. Enables log rotation for audit logs.
LOG_ROTATE_MAX_AUDIT No Requires LOG_ROTATE_DAILY_AUDIT. Sets the maximum amount of audit log files.

Logging outputπŸ”—

Every VM running AQtive Guard generates its own logs and they are not transferred to another machine or centralized.

By default, logs are written to journalctl, but an option can be enabled to write them to a file instead.

  • This option can be enabled separately for the different types of logs produced.
  • The log level can be controlled separately for every type of log.
  • Make these configurations using the configuration file on every VM.

All logs contain the fields and data specified in the following sections.

Sending error logsπŸ”—

If you encounter issues, we may request logs to assist with troubleshooting.

Run the following command on the machine that you want to collect logs from:

cs logs bundle

Note

For high-availability environments, you’ll need to run the command on every machine.

This command generates a compressed file that contains the logs. The generated file will be located in the directory where you ran the command.

This command can be used with the following options:

  • --date-from - retrieve logs after a given date. The format is YYYY-MM-DD or YYYY-MM-DD HH:MM:SS. The default is no limit.
  • --date-to - stop the retrieval at logs at a given date. The format is YYYY-MM-DD or YYYY-MM-DD HH:MM:SS. The default is no limit.
  • --log-type - only retrieve logs of a given type. Allows for a comma-separated list of multiple values. The possible values are AUDIT, ANALYSIS, and APPLICATION. Defaults to all values.
  • --log-level - only retrieve logs of a given level. Allows for a comma-separated list. The possible values are DEBUG, INFO, WARNING, and ERROR. Defaults to all values.
  • --out-file - specify a path for the output file. If nothing is specified, logs are printed to the console.
  • --compress - compress the output file. This option can only be used if the out-file option is used.

Once you’ve collected the logs, send them to us.

Structured logs schemaπŸ”—

Audit logs are structured into JSON objects. They are serialized into strings and logged in journalctl or the specified files.

The structure of the logs is a flat key-value object. The specific keys and their content depend on the type of log.

All logs have a baseline of required fields:

Field Description
id Unique ID, generated using UUIDv4
created_at UTC timestamp
hostname Hostname of the machine
level From lowest to highest, debug, info, warning, error or critical
log_type audit, web, application, analysis or tanium
pid PID of the process generating the log

In addition, all logs may have additional fields:

Field Description
request_id Unique ID, generated using UUIDv4, of the incoming request. Several logs may share this value
user_id User ID of the logged-in user
user_name Username of the logged-in user
stacktrace Formatted stack trace of the exception(s) encountered

Audit logsπŸ”—

Login attemptsπŸ”—

Field Description
action “login_attempt”
access_granted True if the login attempt was successful.
client_ip IP address of client sending login request.
forwarded_for_client_ip Original client IP address if behind proxy.

User activityπŸ”—

Field Description
action “access”, “create”, “update”, “remove”, “export_jira”
access_granted True if the action was allowed.
access_denied_reason Β If the action was not allowed, contains the explanation.
element The type of element that is being acted upon.
element_id The ID of the element that is being acted upon.
client_ip IP address of client sending action request.
forwarded_for_client_ip Original client IP address if behind proxy.

Setting changesπŸ”—

Field Description
action “setting_change”
access_granted True if the change was allowed.
setting The name of the setting that is being changed.
old_value Value before the change.
new_value Β Requested new value.
access_denied_reason If the action was not allowed, contains the explanation.
element_id Additional ID if applicable to the specific setting.
client_ip IP address of client sending setting change request.
forwarded_for_client_ip Original client IP address if behind proxy.

API RequestπŸ”—

Field Description
action “api_request”
access_granted True if the request was allowed.
access_denied_reason If the action was not allowed, contains the explanation.
api_key Present only if the API key was invalid.
client_ip IP address of client sending api request.
forwarded_for_client_ip Original client IP address if behind proxy.

Web LogsπŸ”—

Web ActivityπŸ”—

Field Description
method Method of the query
path URL that was queried
status_code HTTP return code

Analysis LogsπŸ”—

Field Description
memory_mb Memory usage of the analyzer process, in MB
module Internal
message Logged message

Application LogsπŸ”—

This is a generic log for uncategorized messages.

Field Description
message Logged message

Tanium LogsπŸ”—

Operations of the Tanium integration generate a dedicated type of logs.

Field Description
computer_group (optional) The ComputerGroup targeted by the operation.
endpoint_id (optional) The Endpoint ID targeted by the operation.
message Logged message

Tanium API RequestsπŸ”—

API requests made to the Tanium server generate logs with the general Tanium fields, and the following additional fields:

Field Description
target Tanium Server that the request is sent to.
path URL that is being requested.
status_code (optional) HTTP response code of the request.
error (optional) Error description if no response is received.