Administrators can stream event logs and keystroke (IO) logs from a client to a sudo log audit server (or compatible server) that implements the sudo logsrv protocol. This feature is disabled by default. Enable the recording service through configuring the policy server with pmsrvconfig or by editing pm.settings.
The stored keystroke (IO) logs can be rotated, trimmed, and compressed to manage storage space.
A syslog output of streamed keystroke (IO) logs can be used to send the data to a Security Information and Event Management (SIEM) tool.
pmmasterd sends I/O logs to the audit server when a command is run via pmrun. I/O logs are sent in real-time. A setting in pm.settings determines whether I/O logs are stored locally too.
You can configure the audit server in pm.settings or interactive mode The pm.settings file sincludes settings for the CA bundle, client certificate, and client key files as well as other settings.
Configuration with pm.settings
One or more audit servers can be specified in the pm.settings file along with the associated port (which defaults to port 30344).
When pmmasterd receives an event from the client, it relays the event to sudo_logsrvd. Events that are supported include: Accept, Reject, and Alert. Logging to the audit server is in addition to local logging. A setting in the pm.settings file specifies whether an unreachable audit server is considered a fatal error or not.
See PM settings variables for more information about modifying the following configuration settings:
-
auditsrvCAbundle
-
auditsrvCert
-
auditsrvEnabled
-
auditsrvEnforced
-
auditsrvHosts
-
auditsrvKeepalive
-
auditsrvLocaliologs
-
auditsrvLogdir
-
auditsrvPkey
-
auditsrvPSpaceMB
-
auditsrvTimeout
-
auditsrvTLS
-
auditsrvTLSCheckpeer
-
auditsrvTLSVerify
Configuration with pmsrvconfig
You can also use the interactive mode of pmsrvconfig to perform most configuration.
Example for interactive mode
In this example, you can see the how interactive mode works.
$ pmsrvconfig -i
[...]
** Where would you like to store errors reported by the Privilege Manager policy server daemon? [/var/log/pmmasterd.log]
- Policy server log location: /var/log/pmmasterd.log
*** Configure Audit Server for Privilege Manager
** Audit Server configuration for pmmasterd
- The Audit Server can receive event and kestroke logs in real time.
- If enabled, pmmasterd streams all logs to the Audit Server.
** Would like you to configure Audit Server(s) for Privilege Manager [YES]
- Configuring Audit Server(s) for pmmasterd: YES
** Audit Server availability
- If none of the configured audit servers are available, the policy server can either
- - Reject all commands until an audit server becomes available
- - Save audit trails locally on the policy server.
These trails will be transferred automatically to an audit server when it becomes available.
- When configured audit server(s) become unavailable,
- 1) I want the policy server to reject all requests
- 2) I want to use audit trail caching on the policy server
** Please select an option [1] 2
** Enter the directory where pmmasterd can save audit trails
[/var/opt/quest/qpm4u/auditserver]
- Audit trails will be saved to directory:
/var/opt/quest/qpm4u/auditserver
** How much disk space shall be preserved in megabytes? [100]
- Command execution will not be permitted if the available disk space drops below
100 megabytes
** Would you like to retain old format IO logs locally? [YES]
- Retaining old IO logs locally: YES
** Enter connection timeout in seconds: [3] 10
- Connection timeout: 10
** Would you like to enable TCP keepalive messages? [YES]
- TCP keepalive messages enabled: YES
** Would you like to secure connection with TLS? [YES]
- Communication between policy server and audit server is secured with TLS: YES
** Audit Servers are already configured:
- qpmdevel1.qpmdomain:30344
** Would you like to reconfigure the Audit Servers? [NO]
- Overwriting Audit Server list: YES
** Please enter the address (hostname | ip_v4 | ip_v6): 127.0.0.1
- Audit Server address: 127.0.0.1
** What port number would you like to use for the audit server daemon? [30344]
- Audit Server port: 30344
** Do you want to add an additional Audit Server to the configuration? [NO]
- 127.0.0.1:30344** Configure TLS parameters
- You need to provide the following files in order to configure TLS:
- * CA bundle file
- * Private key file
- * Certificate file
** Please enter the full path to the CA bundle file
[/etc/ssl/sudo/ca.bundle.pem]:
** Checking that CA bundle is in PEM format [ OK ]
- CA bundle file is set: /etc/ssl/sudo/ca.bundle.pem
** Please enter the full path to the private key file
[/etc/ssl/sudo/qpm_qpmdevel1.key.pem]:
** Checking that private key is in PEM format [ OK ]
- Private key file is set: /etc/ssl/sudo/qpm_qpmdevel1.key.pem
** Please enter the full path to the certificate file
[/etc/ssl/sudo/qpm_qpmdevel1.cert.pem]:
** Checking certificate against the private key [ OK ]
** Checking certificate chain of trust [ OK ]
** Checking certificate expiration [ OK ]
** Checking hostname/IP address [WARN]
- WARNING: Could not verify hostname/IP
- Client certificate file is set:
/etc/ssl/sudo/qpm_qpmdevel1.cert.pem
** Would like you to check connection to the audit server(s)? [YES]
Using pmsrvconfig
You can use the pmauditsrv and options for the following:
- Verifies that the configured audit servers are accessible and configured properly and exchanges a "hello" message with the server.
- If the audit server is not accessible, stores the events and keystroke (IO) logs temporarily offline and sent to the audit server when it is available.
The connection from pmmasterd to sudo_logsrvd uses TLS to secure data transmission. If none of the audit servers are reachable, event logs and keystroke I/O logs are queued locally on the policy server and sent to the audit server once it is available. Offline logs are encrypted until they are transferred to the log server.
For more information, see pmauditsrv.
Using command line tools, you can list events and replay log files directly from the primary policy server using the pmlogsearch, pmreplay, and pmremlog commands.
pmlogsearch
pmlogsearch is a simple search utility based on common criteria. Run pmlogsearch on the primary server to query the logs on all servers in the policy group. pmlogsearch provides a summary report on events and keystroke logs matching at least one criteria. pmlog provides a more detailed report on events than pmlogsearch.
Hostnames may appear in the event logs and keystroke log files in either fully qualified format (myhost.mycompany.com) or in short name format (myhost), depending on how hostnames are resolved and the use of the short name setting in the pm.settings file. To ensure that either format is matched, use the short host name format with an asterisk wildcard (myhost*) when specifying a hostname search criteria.
See pmlogsearch for more information about the syntax and usage of the pmlogsearch command.
pmlogsearch performs a search across all policy servers in the policy group and returns a list of events (and associated keystroke log file names) for requests matching the specified criteria. You specify search criteria using the following options (you must specify at least one search option):
Table 9: Search criteria options
| --after "YYYY/MM/DD hh:mm:ss" |
Search for sessions initiated after the specified date and time. |
| --before "YYYY/MM/DD hh:mm:ss" |
Search for sessions initiated before the specified date and time. |
| --host hostname |
Search for sessions that run on the specified host. |
| --result accept|reject |
Return only events with the indicated result. |
| --text keyword |
Search for sessions containing the specified text. |
|
--user username |
Search for sessions by the specified requesting user. |
The following pmlogsearch options support the use of wildcards, such as * and ?:
To match one or more characters, you can use wild card characters (such as ? and *) with the --host, --text, and --user options; but you must enclose arguments with wild cards in quotes to prevent the shell from interpreting the wild cards.
If there is a keystroke log associated with the event, it displays the log host and pathname along with the rest of the event information.
The following example lists two events with keystroke (IO) logs:
# pmlogsearch --user sally
Search matches 2 events
2013/03/16 10:40:02 : Accept : sally@qpmsrv1.example.com
Request: sally@qpmsrv1.example.com : id
Executed: root@qpmsrv1.example.com : id
IO Log: qpmsrv1.example.com:/opt/quest/qpm4u/iologs/demo/sally/id_20120316_1040_ESpL6L
2013/03/16 09:56:22 : Accept : sally@qpmsrv2.example.com
Request: sally@qpmsrv2.example.com : id
Executed: root@qpmsrv2.example.com : id
IO Log: qpmsrv2.example.com:/opt/quest/qpm4u/iologs/demo/sally/id_20120316_0956_mrVu4I
pmreplay
You can use the pmreplay command to replay a keystroke log file if it resides on the local policy server.
To replay the log, run:
# pmreplay <path_to_keystroke_log>
For example, the following command replays the first ls -l /etc log from the previous example:
# pmreplay /opt/quest/qpm4u/iologs/demo/sally/id_20120316_1040_ESpL6L
pmremlog
If the keystroke log resides on a remote policy server, you can use the pmremlog command with the -h <remote_host> and -p pmreplay options to remotely replay a keystroke log file. You specify the path argument to the remote pmreplay after the -- flag.
For example, enter the following command all on one line:
# pmremlog -h qpmsrv2 -p pmreplay -- /opt/quest/qpm4u/iologs/demo/sally/id_20120316_0956_mrVu4I
Host names may appear in the event logs and keystroke log files in either fully qualified format (myhost.mycompany.com) or in short-name format (myhost), depending on how host names are resolved and the use of the shortnames setting in the pm.settings file. To ensure that either format is matched, when you specify a host name search criteria, use the short-host name format with an asterisk wild card (For example, myhost*).
You can list the events that are logged when you run a command, whether accepted or rejected by the policy server.
Keystroke logs are related to events. When you run a command, such as sudo whoami, the policy server either accepts or rejects the command based on the policy. When the policy server accepts the command, it creates an event and a corresponding keystroke log. If it rejects the event, it does not create a keystroke log. In order to view a keystroke log, you must first list events to find a particular keystroke log.
The pmlog command displays event log entries, such as events by date and time, host, user, run user, command, and result.
To display a list of events from the command line on the policy server
- From the command line, enter:
# pmlog --after "2011/05/06 00:00:00" --user "tuser"
pmlog provides direct and flexible access to the event logs on the local policy server and is capable of complex queries.
If you run a command, you might see output similar to the following which indicates the policy server has successfully accepted or rejected commands:
Accept 2011/05/11 13:20:04 tuser@ myhost.example.com -> root@ myhost.example.com
whoami
Command finished with exit status 0
Accept 2011/05/11 14:05:58 tuser@ myhost.example.com -> root@ myhost.example.com
whoami
Command finished with exit status 0
Reject 2011/05/11 14:06:17 tuser@ myhost.example.com
Fakecmd
The following pmlog options support the use of wildcards, such as * and ?:
- --user
- --runuser
- --reqhost
- --runhost
- --masterhost
You can also use the pmremlog command on the primary policy server to run pmlog on secondary policy servers. For example:
# pmremlog -h polsrv2 -p pmlog -- --user myuser --command sh
Related Topics
pmlog
pmremlog
