PostgreSQLLa base de données la plus sophistiquée au monde.

Version anglaise

18.7. Empêcher l'usurpation de serveur (spoofing)

Quand le serveur est en cours d'exécution, un utilisateur mal intentionné ne peut pas interférer dans les communications client/serveur. Néanmoins, quand le serveur est arrêté, un utilisateur local peut usurper le rôle du serveur normal en lançant son propre serveur. Le serveur usurpateur pourrait lire les mots de passe et les requêtes envoyés par les clients, mais ne pourrait pas renvoyer de données car le répertoire PGDATA est 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 d'usurper des connexions locales est d'utiliser un répertoire de socket de domaine Unix (unix_socket_directories) qui n'a un droit en écriture que pour 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 craignez que certaines applications puissent encore référencer /tmp pour le fichier socket et, du coup, être vulnérable au « spoofing », créez un lien symbolique /tmp/.s.PGSQL.5432 pointant vers le fichier socket déplacé. Vous pourriez alors 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 un propriétaire précis du processus serveur connecté au socket.

Pour éviter l'usurpation sur les connexions TCP, utilisez des certificats SSL, et assurez-vous que les clients vérifient le certificat du serveur, ou bien utilisez le chiffrage GSSAPI (ou les deux, s'il s'agit de connexions séparées).

Pour éviter l'usurpation avec SSL, le serveur doit être configuré pour accepter les connexions hostssl (Section 20.1, « Le fichier pg_hba.conf ») et avoir des fichiers SSL clé et certificat (Section 18.9, « Connexions TCP/IP sécurisées avec SSL »). Le client TCP doit se connecter en utilisant sslmode='verify-ca' ou verify-full et le fichier certificat root approprié doit y être installé (Section 33.18.1, « Vérification par le client du certificat serveur »).

Pour éviter l'usurpation avec GSSAPI, le serveur doit être configuré pour n'accepter que les connexions hostgssenc (Section 20.1, « Le fichier pg_hba.conf ») et l'authentification gss avec elles. Le client TCP doit se connecter en utilisant gssencmode=require.