PostgreSQL must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.

From PostgreSQL 9.x Security Technical Implementation Guide

Part of SRG-APP-000099-DB-000043

Associated with: CCI-000134

SV-87495r2_rule PostgreSQL must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.

Vulnerability discussion

Information system auditing capability is critical for accurate forensic analysis. Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system.Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.

Check content

Review locations of audit logs, both internal to the database and database audit logs located at the operating system level.  Verify there are appropriate controls and permissions to protect the audit information from unauthorized modification.  Note: The following instructions use the PGDATA environment variable. See supplementary content APPENDIX-F for instructions on configuring PGDATA.  #### stderr Logging  If the PostgreSQL server is configured to use stderr for logging, the logs will be owned by the database owner (usually postgres user) with a default permissions level of 0600. The permissions can be configured in postgresql.conf.  To check the permissions for log files in postgresql.conf, as the database owner (shown here as "postgres"), run the following command:  $ sudo su - postgres  $ grep "log_file_mode" ${PGDATA?}/postgresql.conf  If the permissions are not 0600, this is a finding.  Next, navigate to where the logs are stored. This can be found by running the following command against postgresql.conf as the database owner (shown here as "postgres"):  $ sudo su - postgres  $ grep "log_directory" ${PGDATA?}/postgresql.conf  With the log directory identified, as the database owner (shown here as "postgres"), list the permissions of the logs:  $ sudo su - postgres  $ ls -la ${PGDATA?}/pg_log  If logs are not owned by the database owner (shown here as "postgres") and are not the same permissions as configured in postgresql.conf, this is a finding.  #### syslog Logging  If the PostgreSQL server is configured to use syslog for logging, consult organization syslog setting for permissions and ownership of logs.

Fix text

Using pgaudit PostgreSQL can be configured to audit various facets of PostgreSQL. See supplementary content APPENDIX-B for documentation on installing pgaudit. All errors, denials and unsuccessful requests are logged if logging is enabled. See supplementary content APPENDIX-C for documentation on enabling logging. Note: The following instructions use the PGDATA and PGVER environment variables. See supplementary content APPENDIX-F for instructions on configuring PGDATA and APPENDIX-H for PGVER. With pgaudit and logging enabled, set the following configuration settings in postgresql.conf, as the database administrator (shown here as "postgres"), to the following: $ sudo su - postgres $ vi ${PGDATA?}/postgresql.conf pgaudit.log_catalog='on' pgaudit.log_level='log' pgaudit.log_parameter='on' pgaudit.log_statement_once='off' pgaudit.log='all, -misc' Next, tune the following logging configurations in postgresql.conf: $ sudo su - postgres $ vi ${PGDATA?}/postgresql.conf log_line_prefix = '< %m %u %d %e: >' log_error_verbosity = default Last, as the system administrator, restart PostgreSQL: # SYSTEMD SERVER ONLY $ sudo systemctl reload postgresql-${PGVER?} # INITD SERVER ONLY $ sudo service postgresql-${PGVER?} reload

Pro Tips

Powered by sagemincer