PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 10.21 » Administration du serveur » Configuration du serveur et mise en place » Empêcher l'usurpation de serveur

18.7. Empêcher l'usurpation de serveur

Quand le serveur est en cours d'exécution, un utilisateur pernicieux ne peut pas interférer dans les communications client/serveur. Néanmoins, quand le serveur est arrêté, un utilisateur local peut usurper le serveur normal en lançant son propre serveur. Le serveur usurpateur pourrait lire les mots de passe et requêtes envoyées par les clients, mais ne pourrait pas renvoyer de données car le répertoire PGDATA serait toujours sécurisé grâce aux droits d'accès du répertoire. L'usurpation est possible parce que tout utilisateur peut lancer un serveur de bases de données ; un client ne peut pas identifier un serveur invalide sauf s'il est configuré spécialement.

Un moyen d'empêcher les serveurs invalides pour des connexions locales est d'utiliser un répertoire de socket de domaine Unix (unix_socket_directories) qui a un droit en écriture accessible seulement par un utilisateur local de confiance. Ceci empêche un utilisateur mal intentionné de créer son propre fichier socket dans ce répertoire. Si vous êtes concerné que certaines applications pourraient toujours référencer /tmp pour le fichier socket et, du coup, être vulnérable au « spoofing », lors de la création du lien symbolique /tmp/.s.PGSQL.5432 pointant vers le fichier socket déplacé. Vous pouvez aussi avoir besoin de modifier votre script de nettoyage de /tmp pour empêcher la suppression du lien symbolique.

Une autre option pour les connexions de type local est que les clients utilisent requirepeer pour indiquer le propriétaire requis du processus serveur connecté au socket.

Pour empêcher l'usurpation des connexions TCP, le mieux est d'utiliser des certificats SSL et de s'assurer que les clients vérifient le certificat du serveur. Pour cela, le serveur doit être configuré pour accepter les connexions hostssl (Section 20.1) et avoir les fichiers SSL clé et certificat (Section 18.9). Le client TCP doit se connecter en utilisant sslmode='verify-ca' ou 'verify-full' et avoir le certificat racine installé.