Mientras el servidor se está ejecutando, no es posible que un usuario malicioso tome el lugar del servidor de bases de datos normal. Sin embargo, cuando el servidor está apagado, es posible que un usuario local suplante al servidor normal iniciando su propio servidor. El servidor suplantador podría leer las contraseñas y las consultas enviadas por los clientes, pero no podría devolver ningún dato porque el directorio PGDATA seguiría estando protegido gracias a los permisos del directorio. La suplantación es posible porque cualquier usuario puede iniciar un servidor de bases de datos; un cliente no puede identificar un servidor inválido a menos que esté configurado de forma especial.

Una forma de evitar la suplantación de conexiones local es utilizar un directorio de sockets de dominio Unix (unix_socket_directories) que tenga permisos de escritura únicamente para un usuario local de confianza. Esto evita que un usuario malicioso cree su propio archivo de socket en ese directorio. Si te preocupa que algunas aplicaciones todavía hagan referencia a /tmp para el archivo de socket y por lo tanto sean vulnerables a la suplantación, durante el inicio del sistema operativo crea un enlace simbólico /tmp/.s.PGSQL.5432 que apunte al archivo de socket reubicado. También es posible que necesites modificar el script de limpieza de /tmp para evitar la eliminación del enlace simbólico.

Otra opción para las conexiones local es que los clientes utilicen requirepeer para especificar el propietario requerido del proceso del servidor conectado al socket.

Para evitar la suplantación en conexiones TCP, puedes utilizar certificados SSL y asegurarte de que los clientes verifiquen el certificado del servidor, o utilizar cifrado GSSAPI (o ambos, si se encuentran en conexiones independientes).

Para evitar la suplantación con SSL, el servidor debe estar configurado para aceptar únicamente conexiones hostssl (Section 20.1) y disponer de los archivos de clave y certificado SSL (Section 18.9). El cliente TCP debe conectarse utilizando sslmode=verify-ca o verify-full y tener instalado el archivo de certificado raíz correspondiente (Section 32.19.1). Alternativamente, se puede utilizar el pool de CA del sistema, tal como lo define la implementación de SSL, mediante sslrootcert=system; en este caso, se fuerza sslmode=verify-full por seguridad, ya que generalmente es trivial obtener certificados firmados por una CA pública.

Para evitar que se produzca la suplantación del servidor cuando utilizas la autenticación por contraseña scram-sha-256 a través de una red, debes asegurarte de conectarte al servidor utilizando SSL y con uno de los métodos contra la suplantación descritos en el párrafo anterior. Además, la implementación de SCRAM en libpq no puede proteger todo el intercambio de autenticación, pero el uso del parámetro de conexión channel_binding=require proporciona una mitigación contra la suplantación del servidor. Un atacante que utilice un servidor falso para interceptar un intercambio SCRAM puede utilizar análisis fuera de línea para determinar potencialmente la contraseña con hash del cliente.

Para evitar la suplantación con GSSAPI, el servidor debe estar configurado para aceptar únicamente conexiones hostgssenc (Section 20.1) y utilizar la autenticación gss con ellas. El cliente TCP debe conectarse utilizando gssencmode=require.