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. |
Note
Logging configuration keys require a service restart for changes to take effect.
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 areAUDIT
,ANALYSIS
, andAPPLICATION
. Defaults to all values.--log-level
- only retrieve logs of a given level. Allows for a comma-separated list. The possible values areDEBUG
,INFO
,WARNING
, andERROR
. 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 theout-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. |