5.2 Ensure login via 'host' TCP/IP Socket is configured correctly - host TCP/IP Socket is configured correctly

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

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 are dependent upon the availability of external authenticating processes/services and thus are not covered in this benchmark.

Rationale:

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 only 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

Default Value:

The availability of the different password-based authentication methods depends on how a user's password on the server is encrypted (or hashed, more accurately). This is controlled by the configuration parameter password_encryption at the time the password is set.

If a password was encrypted using the scram-sha-256 setting, then it can be used for the authentication methods scram-sha-256, md5, and password (but password transmission will be in plain text in the latter case).

If a password was encrypted using the md5 setting, then it can be used only for the md5 and password authentication method specifications (again, with the password transmitted in plain text in the latter case).

Previous PostgreSQL releases supported storing the password on the server in plain text. This is no longer possible.

To check the currently stored password hashes, see the system catalog pg_authid.

To upgrade an existing installation from md5 to scram-sha-256, after having ensured that all client libraries in use are new enough to support SCRAM, set password_encryption = 'scram-sha-256' in postgresql.conf, reload the postmaster, make all users set new passwords, and change the authentication method specifications in pg_hba.conf to scram-sha-256.

See Also

https://workbench.cisecurity.org/files/3558