Information
A large number of authentication METHODs are available for hosts connecting using TCP/IP sockets, including:
- trust
- reject
- md5
- scram-sha-256
- password
- gss
- sspi
- ident
- pam
- ldap
- radius
- cert
METHODs trust, password, and ident are not to be used for remote logins.
METHOD md5 is the most popular and can be used in both encrypted and unencrypted sessions; however, it is vulnerable to packet replay attacks. It is recommended that scram-sha-256 be used instead of md5.
Use of the gss, sspi, pam, ldap, radius, and cert METHODs is dependent upon the availability of external authenticating processes/services and thus are not covered in this benchmark.
An attacker with network access who can intercept traffic between a client and the PostgreSQL server can capture credentials and session data from unencrypted connections, or replay captured authentication exchanges when weaker methods like md5 are used. Requiring scram-sha-256 over SSL/TLS for all remote TCP/IP connections ensures credentials are protected against both eavesdropping and replay attacks, as scram-sha-256 uses a challenge-response mechanism that prevents captured authentication data from being reused.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.
Solution
Confirm a login attempt has been made by looking for a logged error message detailing the nature of the authenticating failure. In the case of failed login attempts, whether encrypted or unencrypted, check the following:
- The server should be sitting on a port exposed to the remote connecting host, i.e. NOT IP address 127.0.0.1
listen_addresses = '*'
```
* An authenticating rule must exist in the file `pg_hba.conf`
This example permits encrypted sessions for the `postgres` role and denies all unencrypted sessions for the `postgres` role:
# TYPE DATABASE USER ADDRESS METHOD
hostssl all postgres 0.0.0.0/0 scram-sha-256
hostnossl all postgres 0.0.0.0/0 reject
The following examples illustrate other possible configurations. The resultant "rule" of success/failure depends upon the first matching line.
# allow 'postgres' user only from 'localhost/loopback' connections
# and only if you know the password
# (accepts both SSL and non-SSL connections)
# TYPE DATABASE USER ADDRESS METHOD
host all postgres 127.0.0.1/32 scram-sha-256
# allow users to connect remotely only to the database named after them,
# with the correct user password:
# (accepts both SSL and non-SSL connections)
# TYPE DATABASE USER ADDRESS METHOD
host samerole all 0.0.0.0/0 scram-sha-256
# allow only those users who are a member of the 'rw' role to connect
# only to the database named after them, with the correct user password:
# (accepts both SSL and non-SSL connections)
# TYPE DATABASE USER ADDRESS METHOD
host samerole +rw 0.0.0.0/0 scram-sha-256