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 local
es 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 21.1)
et avoir des fichiers SSL clé et certificat
(Section 19.9). Le client TCP
doit se connecter en utilisant sslmode='verify-ca'
ou
verify-full
et le fichier certificat racine approprié
doit y être installé (Section 34.19.1). Sinon, l'ensemble
CA du système peut être utilisé avec sslrootcert=system
;
dans ce cas, sslmode=verify-full
est forcé pour la sécurité car
il est généralement trivial d'obtenir des certificats qui ont été signés
par un CA public.
Pour éviter l'usurpation de serveur lors de l'utilisation de l'authentification
scram-sha-256 sur un réseau, vous devez
vous assurer que vous vous connectez au serveur en utilisant SSL et une des
méthodes anti-usurpation décrites dans le paragraphe précédent. De plus,
l'implémentation SCRAM dans
libpq ne peut pas protéger l'échange entier
d'authentification mais, utiliser le paramètre de connexion
channel_binding=require
atténue le risque d'usurpation du
serveur. Un attaquant qui utilise un serveur pour intercepter un échange
SCRAM peut utiliser une analyse hors ligne pour déterminer potentiellement
le mot de passe haché du client.
Pour éviter l'usurpation avec GSSAPI, le serveur doit être configuré
pour n'accepter que les connexions hostgssenc
(Section 21.1) et l'authentification
gss
avec elles.
Le client TCP doit se connecter en utilisant gssencmode=require
.