Audit Logs

Logpoint Director generates audit logs, records that provide information on which events occurred and who (or what) caused them. These logs have digital footprints known as audit trails. These trails help trace the type of change, the user who made the change and the time of the change.

Types of Audit Logs

The types of audit logs generated in the Logpoint Director setup are:

• Audit Logs for Fabric Server

  • Audit Logs for Fabric Proxy

  • Audit Logs for Fabric Storage

  • Audit Logs for Fabric Authenticator

• Audit logs for Logpoint Search Master

• Audit Logs for Fabric Connect

• Audit logs for API Server

Fabric Server Audit Logs

Fabric Server generates log records known as audit logs. These logs have digital footprints known as audit trails. The audit trails consist of detailed information about the events that occur in the Fabric Server.

The information defined in the audit logs are:

• Date and time of the event

• User, system or application that launched the event

• The type of event

Audit Log for Fabric Proxy

By default, the logging level for audit logs of Fabric Proxy Server is Info. The logging level tracks and analyzes events. It identifies the type and severity of logged events based on the impact severity on users and how quickly an administrator should respond.

The following are the two types of Fabric Proxy Server audit logs:

1. Request Issued

2. Response Received

Audit Log for Fabric Storage

By default, the logging level for audit logs of the Fabric Storage server is Info.

Format of Fabric Storage audit logs:

Audit Log for Fabric Authenticator

The following are the two types of Fabric Authenticator server audit logs:

1. Request Issued

2. Response Received

Audit Logs for Fabric Connect

Every new request for Fabric Connect contains the incoming request ID, desired action in web server and the data to be sent to the web server.

For example, if the config API sends a new request to add a device in Logpoint, the example audit log for the Fabric Connect is:

After the configuration service gets a response, the following message is logged to notify that the request was processed:

Finally, in the web server audit log, an extra parameter is added to signify that the operation has been conducted from the Config API.

An example of a web server audit log is:

API Server Audit Logs

Audit logs for the Config API and Monitoring API is sent via syslog to any Security Information Management (SIM) device including Logpoint. These logs are also accessible to an authorized user through Director Console. Audit logs for APIs can be displayed, searched and ordered in any field in Logpoint.

• Config API is an asynchronous interface, used to perform various actions on Fabric-enabled Logpoints. The API performs actions such as the creation of devices, the creation of normalization policies, configuring collectors and configuring fetchers.

• Monitoring API is an interface which monitors the status of Config API requests.

Audit Logs for Config API

By default, the logging level for Config API is Info. The logging level tracks and analyzes events. It identifies the type and severity of logged events based on the impact severity on users and how quickly an administrator should respond. When a request is sent through the Config API, the following data are logged:

• Request Issued

• Exception Thrown

• Warning

Request Issued

For every request made from the Config API, the API logs a request message. The request log contains information such as request type, request source and request header.

An example of a request log is:

Request Log

Exception Thrown

For every malformed json data or failed data validation of Config API, the API logs an exception thrown. The log contains information such as status code and error message.

An example of an exception log is:

Exception Log

Warning

For every action where the Config API takes a default value, the API logs a warning message without halting the request issued. The log contains the information such as status code, the source of warning and error message.

An example of a warning log is:

Warning Log

Audit Logs for Monitoring API

By default, the logging level for audit logs of Monitoring API is Info. The Monitoring API request logs the following data:

• Request Issued

• Success Log

• Warning

• Error

Request Issued

Logpoint For every request from the Monitoring API, the API logs a request message.

An example of a request log is:

Request Log

Success Log

If the Monitoring API successfully returns data for a request ID, then an audit log signifying successful response is logged.

An example of a success log is:

Success Log

Warning

If the Monitoring API cannot return data for an issued request, then an audit log signifying warning response is logged.

An example of a warning log is:

Warning Log

Error

If the Monitoring API doesn’t return data for an issued request, then an audit log signifying error response is logged.

An example of an error log is:

Error Log

Access Director Fabric Audit Logs

Director Fabric generates audit logs for Fabric Server and API Server. To view the audit logs, you must forward them to Logpoint or any Logpoint receiving client via Syslog collector.

Forward the Audit Logs

1. Execute the change-rsyslogip command in the server whose logs you want to forward.

2. Enter the IP address of Logpoint or the log receiving client that collects the audit logs forwarded from the server.

You must individually forward the audit logs from the Fabric Server and the API Server.

Collect Audit Logs in Logpoint

You can only add the Fabric Server and API Server as devices when Logpoint Fabric is disabled and configure them with a Syslog collector to collect the audit logs. To learn more, go to Adding a Device.

The following device properties are specific to Audit Logs. It’s important that you configure these properties for Audit Logs to generate correctly.

• Enter the IP address(es) of the server whose logs you want to collect.

• Select _logpoint as Processing Policy for correct normalization of audit logs.

• In Proxy Server, select None.

• You must configure the devices for Fabric Servers and API Server individually.

• You can also collect logs via a Fabric-enabled Logpoint. To collect the logs, you must configure the devices via Director Console API or Director Console UIA.

• Go to Devices to learn how to create a device. Go to Syslog Collectors to learn how to add a Syslog Collector to a device.

View Director Fabric Audit Logs

After configuring the device, you can view, search and order the Director Fabric audit logs using specific Logpoint search queries.

1. Go to Search from the navigation bar.

2. Enter the search query.

3. Click Search to view the audit logs.

Examples of Director Fabric audit logs include:

Example 1: Fabric Proxy Audit Logs

event_source="fabric_proxy"

Fabric Proxy Audit Logs

Example 2: Fabric Storage Audit Logs

event_source="fabric_storage"

Fabric Storage Audit Logs

Example 3: Fabric Authenticator Audit Logs

label="Preauthentication"

Fabric Authenticator Audit Logs

Example 4: API Server Audit Logs

label="API"

API Server Audit Logs

Example 5: Fabric Connect Audit Logs

"source_name"="/opt/immune/var/log/audit/api_config_service.log"

Fabric Connect Audit Logs

Change the log level of Audit Logs

Only users with the partner or support permission can change the log level of Audit logs.

Change the Fabric Proxy log level

1. Stop the running zookeeper process with the commands sudo sv stop zookeeper and sudo /opt/commander/installed/zookeeper/bin/zkServer.sh stop.

2. Edit the file /opt/commander/installed/zookeeper/conf/log4j.properties using the command sudo vi /opt/commander/installed/zookeeper/conf/log4j.properties. Replace the first line with the command log4j.rootCategory=INFO, file. Change the log level from INFO to the required log level like DEBUG, WARN or TRACE.

3. Start the service using the sudo sv start zookeeper command.

Change the Fabric Storage log level

1. Edit the file /opt/commander/etc/hadoop/log4j.properties using the command sudo vi /opt/commander/etc/hadoop/log4j.properties. Replace the first line with the command log4j.rootCategory=INFO, file. Change the log level from INFO to the required log level like DEBUG, WARN or TRACE.

2. Reboot the system for the changes to take effect.

Change the API Server log level

1. Stop the tomcat service using the sudo docker stop directorapi command.

2. Edit the following files:

   /opt/commander/etc/config/{configapi,monitorapi,governingapi}.properties.

   Choose configapi, monitorapi or governingapi according to the requirements.

   For example,

   • Execute the following command to change the loglevel of configapi: sudo vi /opt/commander/etc/config/configapi/configapi.properties

   • Replace the first line with the command log4j.rootCategory=INFO, file.

   • Change the log level from INFO to the required log level like DEBUG, WARN or TRACE.

3. Start the tomcat service using the sudo docker start directorapi command.

Store Transactional Logs of Fabric Proxy on a Different Disk

Users with the partner or support permission can move Fabric Proxy transactional logs to a different disk. These logs include information about read/write operations to and from the Fabric Proxy.

1. Enter the sudo rescan-scsi-bus command to detect newly added devices.

2. Execute one of following commands depending on the number of devices:

   1. To add a single device as a transaction log device, enter the command:

      sudo zpool create -o ashift=12 -O atime=off -O canmount=off -O compression=lz4 fablog_pool /dev/sdc -f

   2. To add two devices in the mirror mode as transaction log devices, enter the command:

      sudo zpool create -o ashift=12 -O atime=off -O canmount=off -O compression=lz4 fablog_pool mirror /dev/sdc /dev/sdd -f

   3. To add three devices in the RaidZ mode as transaction log devices, enter the command:

      sudo zpool create -o ashift=12 -O atime=off -O canmount=off -O compression=lz4 fablog_pool raidz /dev/sdc /dev/sdd /dev/sde -f

3. The new configurations now get stored in the cache. To load the configurations, export and import zpool using the commands:

   sudo zpool export fablog_pool
   sudo zpool import -d /dev/ fablog_pool

4. Make a mountpoint and mount it to fablog_pool using the command:

   sudo zfs create -o mountpoint=/opt/commander/fablog fablog_pool/fablog

5. Stop the Fabric Proxy service by using the command:

   sudo sv stop zookeeper

6. Copy the existing transaction log to a new mountpoint using the command:

   sudo cp -vr /opt/commander/var/zookeeper/log/version-2 /opt/commander/fablog/

7. Modify the fabric configuration file to point to the new mountpoint using the command:

   sudo sed -i ‘s/var/zookeeper/log/fablog/’ /opt/commander/installed/zookeeper/conf/zoo.cfg sed -i ‘s/var/zookeeper/log/fablog/’ /ecd tc/service/fabcleanup/run

8. Start the Fabric Proxy service using the command:

   sudo sv start zookeeper

Transactional logs are now stored on a different disk.

• The Zettabyte File System (ZFS) used in Logpoint Director is a software-defined solution for disk-based redundancy (Mirror, RAIDZ). Logpoint recommends not using hardware-based RAID because it restricts ZFS to only performing self-healing on checksum failures.

• In RAIDZ mode, the first three disks are used for OS and application installation. Any remaining disks can be used to extend the disk space or as Level 2 Adjustable Replacement Cache (L2ARC) or ZFS Intent Log (ZIL) to enhance ZFS’s read/write performance. Use the ZFS commands to configure any remaining disks.