Documentation PostgreSQL 9.0.23 > Administration du serveur > Configuration du serveur et mise en place > Empêcher l'usurpation de serveur | |
Arrêter le serveur | Options de chiffrement |
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.
Le moyen le plus simple d'empêcher les serveurs invalides pour des connexions locales est d'utiliser un répertoire de socket de domaine Unix (unix_socket_directory) 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.
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 19.1, « Le fichier pg_hba.conf ») et avoir les fichiers SSL pour la clé, server.key, et pour le certificat, server.crt (Section 17.8, « Connexions tcp/ip sécurisées avec ssl »). Le client TCP doit se connecter en utilisant sslmode='verify-ca' ou 'verify-full' et avoir le certificat racine installé (Section 31.1, « Fonctions de contrôle de connexion à la base de données »).