lundi 8 janvier 2007
Sécurité avec PostgreSQL - Stunnel
Par david techer, lundi 8 janvier 2007 à 02:48 :: PostGIS et PostgreSQL
Introduction
Pour protéger ses données lors d'une connexion entre un serveur et un client avec PostgreSQL, il existe plusieurs façons de faire. Soit en utilisant PostgreSQL compilé avec OpenSSL en natif, uriliser un tunnel SSH avec redirection de Port ect...Un des moyens que j'aime bien et d'utiliser Stunnel/OpenSSL.
Stunnel est une enveloppe SSL, permettant donc d'étendre les fonctionnalités de SSL à un démon qui à l'origine n'est pas prévu pour être une couche de sécurité. On peut donc par exemple créer une connexion sécurisée entre vers une base de données, consolidant ainsi la connexion du système,
Un autre intérêt de l'installation avec Stunnel est qu'il peut-être installé en tant que service (automatiquement relancé au démarrage de la machine). Ce que ne propose pas une redirection par SSH. Je ne propose pas ici l'installation de stunnel avec xinetd, trop contrariant à mon sens.
1. Pré-requis
Je pars du principe ici que les configurations réseaux avec PostgreSQL sont acquises par le lecteur. Pour les test ici, nous aurons besoin de deux machines. Sur mon réseau domestique, j'ai deux machines dont les noms sont respectivement jenna et bremko:
jennadont l'IP est192.168.0.5fera office de serveur. Je lui ai installé un serveur PostgreSQL 8.1.5;bremkodont l'IP est192.168.0.4fera office de client PostgreSQL 8.1.5 pour lequel je n'aurais besoin que de psql fourni par la 8.1.5 de PostgreSQL;
Pour vérifier que les données sont bien chiffrées où non, nous avons besoin d'installer un sniffer comme nast ou etherreal (...) entre jenna et bremko! J'opte ici pour NAST (Network Analize Sniffer Tool/http://nast.berlios.de/) que j'installe en faisant - en tant que root - sur bremko
apt-get install nast
Pour les besoins de mes tests, je crée un super-utilisateur damien sur jenna dont le mot de passe sera 'morphine'
root@jenna:/root$ su postgres postgres@jenna:/root$createuser -sEPe damien Entrez le mot de passe pour le nouvel rôle : Entrez-le de nouveau : CREATE ROLE damien ENCRYPTED PASSWORD 'morphine' SUPERUSER CREATEDB CREATEROLE INHERIT LOGIN; CREATE ROLE
Remarques: mes machines sont ici toutes les deux sous Ubuntu Dapper. Pour de plus amples informations sur nast, n'oubliez pas de faire man nast
2. Motivations: sniffer une connexion non sécurisée avec NAST, limites d'une connexion par mot de passe en md5!
2.1 Test sans mot de passe
Commençons donc par vérifier que si je laisse le mot de passe par défaut sur à 'password' sur le réseau on arrive quand même à le récupérer. Pour celà , dans le pg_hba.conf de jenna, je fais la modification suivante
host 192.168.0.4 255.255.255.255 password
et je redémarre ensuite mon serveur
/etc/init.d/postgresql restart
Sur bremko, dans un terminal pour sniffer les connexion je fais
nast -i eth0 -pd -f "dst 192.168.0.5" -f "port 5432"
Dans un autre terminal (toujous depuis bremko), j'ouvre ma connexion à jenna en faisant
psql -h jenna -U damien template1
Dans le terminal que contient le processus actif de nast, je vois a un moment passé le message
---[ TCP Data ]------------------------------------------------------ ( user damien database template1 ---[ TCP ]----------------------------------------------------------- 192.168.0.5:5432(postgresql) -> 192.168.0.4:50884(unknown) TTL: 64 Window: 1448 Version: 4 Lenght: 61 FLAGS: ---PA-- SEQ: 1495197601 - ACK: 923679297 Packet Number: 26 ---[ TCP Data ]------------------------------------------------------ R ---[ TCP ]----------------------------------------------------------- 192.168.0.4:50884(unknown) -> 192.168.0.5:5432(postgresql) TTL: 64 Window: 1460 Version: 4 Lenght: 66 FLAGS: ---PA-- SEQ: 923679297 - ACK: 1495197610 Packet Number: 27 ---[ TCP Data ]------------------------------------------------------ morphine ---[ TCP ]-----------------------------------------------------------
preuve que ça ne suffit pas!
2.2 Test avec MD5
Allons donc! Changeons donc le mot-clé 'password' par 'md5' dans le fichier pg_hba.conf de jenna,
host 192.168.0.4 255.255.255.255 md5
et redémarrons le serveur (/etc/init.d/postgresql restart). Relançons donc une connexion au serveur depusi bremko. Maintenant depuis nast, j'obtiens
---[ TCP Data ]------------------------------------------------------ ( user damien database template1 ---[ TCP ]----------------------------------------------------------- 192.168.0.5:5432(postgresql) -> 192.168.0.4:45585(unknown) TTL: 64 Window: 1448 Version: 4 Lenght: 65 FLAGS: ---PA-- SEQ: 1852264915 - ACK: 1258303094 Packet Number: 85 ---[ TCP Data ]------------------------------------------------------ R +F ---[ TCP ]----------------------------------------------------------- 192.168.0.4:45585(unknown) -> 192.168.0.5:5432(postgresql) TTL: 64 Window: 1460 Version: 4 Lenght: 93 FLAGS: ---PA-- SEQ: 1258303094 - ACK: 1852264928 Packet Number: 86 ---[ TCP Data ]------------------------------------------------------ p (md5063971165646bb85c855953e66c01196 ---[ TCP ]-----------------------------------------------------------
Gagné 
! Enfin ne nous réjouisson pas trop vite car si je tape une requête depuis le client je vois apparaître par exemple
---[ TCP Data ]------------------------------------------------------ Q %select * from geometry_columns ; ---[ TCP ]----------------------------------------------------------- 192.168.0.5:5432(postgresql) -> 192.168.0.4:48508(unknown) TTL: 64 Window: 6091 Version: 4 Lenght: 52 FLAGS: ----A-- SEQ: 2056534420 - ACK: 1484467451 Packet Number: 161 ---[ TCP ]----------------------------------------------------------- 192.168.0.5:5432(postgresql) -> 192.168.0.4:48508(unknown) TTL: 64 Window: 6091 Version: 4 Lenght: 1500 FLAGS: ----A-- SEQ: 2056534420 - ACK: 1484467451 Packet Number: 162 ---[ TCP Data ]------------------------------------------------------ T f_table_catalog f_table_schema f_table_name f_geometry_column coord_dimension srid type " D E public apb_lr the_geom 2 -1 MULTIPOLYGOND U public a_cours_d_eau_n2_v3 the_geom 2 -1 MULTILINESTRING
Oups!
Première conclusion Bon md5 protège bien mon mot de passe mais pas mes requêtes ainsi que les résultats renvoyés par le serveur! Et c'est là justement qu'intervient Stunnel 
!
3. Stunnel: sécurisation de la connexion
3.1 Pré-requis: OpenSSL
Stunnel a besoin de OpenSSL pour pouvoir fonctionner
apt-get install openssl libssl-dev
3.2 Installation de Stunnel
Le site de stunnel est http://www.stunnel.org. Nous aurons besoin ici de l'installer à la fois sur le serveur et sur le client. Je fournis ici les commandes que j'ai utilisé pour l'installer sans plus de détails
wget http://www.stunnel.org/download/stunnel/src/stunnel-4.20.tar.gz tar xvzf stunnel-4.20.tar.gz cd stunnel-4.20 ./configure --with-ssl=/usr --prefix=/opt/stunnel make make install
Lors de l'installation un fichier stunnel.pem sera généré dotn voici une copie d'écran de ce que j'ai renseigné pour jenna
Generating a 1024 bit RSA private key .................++++++ ............++++++ writing new private key to 'stunnel.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [PL]:FR State or Province Name (full name) [Some-State]:Hérault Locality Name (eg, city) []:Castelnau-Le-Lez Organization Name (eg, company) [Stunnel Developers Ltd]:01MAP Organizational Unit Name (eg, section) []:01MAP Common Name (FQDN of your server) [localhost]:jenna
Je renouvelle l'instalaltion sur bremko, en changeant la ligne Common Name (FQDN of your server) [localhost]:bremko
3.3 Mise en oeuvre
J'ouvre maintenant un terminal sur jenna et j'y tape
root@jenna:/opt/stunnel/sbin/stunnel3 -D 7 -f -P /opt/stunnel/stunnel.pid \ -o /opt/stunnel/log/stunnel.log -p /opt/stunnel/etc/stunnel/stunnel.pem -d 9000 -r localhost:5432
Sur bremko, je lance
root@bremko:/opt/stunnel# /opt/stunnel/sbin/stunnel3 -D 7 -f \ -P/opt/stunnel/stunnel.pid -o /opt/stunnel/log/stunnel.log -c -d localhost:5433 \ -o /opt/stunnel/log/stunnel.log -c -d localhost:5433 -r 192.168.0.5:9000
Et pour m'assurer que les connexions seront chiffrées dans un troisème terminal sur bremko, je fais
nast -pd -i eth0 -f "dst 192.168.0.5" -f "port 9000"
Dans un nouveau terminal toujours - sur bremko - j'ouvre maintenant une connexon PostgreSQL en faisant
psql -hlocalhost-p5433-U damien template1
Je saisis quelques requêtes et j'apprécie le travail en regardant les lignes retournées par nast depuis le troisième terminal en question
3.4 Installation de Stunnel en tant que service
Pour l'installtion en service sur les deux machines, il suffit de modifer le script de démarrage de Ubuntu à savoir /etc/init.d/rc.local. J'y ai par exemple effectuer les modifications suivantes sur jenna
#! /bin/sh
# Modications du PATH pour accéder à stunnel
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/stunnel/sbin
[ -f /etc/default/rcS ] && . /etc/default/rcS
. /lib/lsb/init-functions
do_start() {
if [ -x /etc/rc.local ]; then
log_begin_msg "Running local boot scripts (/etc/rc.local)"
/etc/rc.local
log_end_msg $?
fi
}
# Ma ligne pour lancer stunnel sur jenna
# à adapter en conséquence sur bremko (voir ci-dessus dans la doc)
/opt/stunnel/sbin/stunnel3 -D 7 -f -P /opt/stunnel/stunnel.pid -p /opt/stunnel/etc/stunnel/stunnel.pem -d 9000 -r localhost:5432 -o /opt/stunnel/log/stunnel.log
case "$1" in
start)
do_start
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
;;
*)
echo "Usage: $0 start|stop" >&2
exit 3
;;
esac
Liens
- Documentations sur PostgreSQL: http://www.davidgis.fr/documentation/win32/html/index.html et http://docs.postgresqlfr.org/8.2/
- Stunnel: http://www.stunnel.org
- openssl: http://www.openssl.org/
!!!
! 
...