Introduction
Pour protéger ses données lors d'une connexion entre un serveur et un client avec PostgreSQL, plusieurs solutions existent: soit en utilisant PostgreSQL compilé avec OpenSSL en natif, utiliser un tunnel SSH avec redirection de Port ect...Un des moyens que j'aime bien est 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.
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:
- jenna dont l'IP est 192.168.0.5 fera office de serveur. Je lui ai installé un serveur PostgreSQL 8.1.5; On s'assurea aussi que le paramètre
listen_adresses = '*'est activé dans le fichierpostgresql.confde configuration de PostgreSQL - bremko dont l'IP est 192.168.0.4 fera office de client. On s'assurera d'avoir un logiciel client de PostgreSQL comme pgadmin3 ou psql sur la machine cliente. Ici c'est psql que j'utiliserai.
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
Motivations: sniffer une connexion non sécurisée avec NAST, limites d'une connexion par mot de passe en md5!
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!
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éjouissons 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!
En effet, depuis bremko j'ai envoyé la requête
selectfrom geometry_columns
à jenna. Les résultats me sont envoyés en claire comme me le confirme la ligne 192.168.0.5:5432(postgresql) 192.168.0.4:48508(unknown) ainsi que le reste des résultats.
Stunnel: sécurisation de la connexion
Nous devons commencer par installer OpenSSL pour utiliser Stunnel par la suite
Pré-requis: OpenSSL
Stunnel a besoin de OpenSSL pour pouvoir fonctionner
apt-get install openssl libssl-dev
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
L'installation aura donc lieu ici dans le répertoire /opt/stunnelmais vous pouvez l'installer où bon vous semble.
Lors de l'installation, un certificat auto-signé stunnel.pem sera généré dont 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'installaltion sur bremko, en changeant la ligne Common Name (FQDN of your server) [localhost]:bremko
Le certificat autu-signé stunnel.pem est utilisé ici uniquement sur la base de test et pour les besoins de l'article. Il pourra être remplacé plus tard par un certificat signé par une autorité de certification (CA).
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/stunnel.log -p /opt/stunnel/etc/stunnel/stunnel.pem -d 9000 -r localhost:5432
avec les options suivantes:
-D 7: pour spécifier le niveau de déboggage afin de collecter le maximum d'informatios;
-f: me permet de faire tourner le processus en arrière-plan dans le terminal. Un simple [CTRL]+[C] me suffira
donc pour arrêter le processus si besoin est;
-P /opt/stunnel/stunnel.pid pour le PID du processus;
-o /opt/stunnel/stunnel.log pour spécifier un fichier de log;
-p /opt/stunnel/etc/stunnel/stunnel.pem pour le certificat auto-signé
Un processus démon de Stunnel par cette commande est donc lancée. Le paramètre -d 9000 est le port d'écoute du démon et lui demande d'attendres de données chiffrées sur ce port. Le paramètre -r localhost:5432 indique au démon que les données reçues sur son port d'écoute (9000), il devra les déchiffrer et les envoyer sur le port 5432 de la machine locale. Or ce dernier port n'est autre que le port d'écoute du serveur PostgreSQL sur jenna.
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 \ -c -d localhost:5433 -r 192.168.0.5:9000
Dans la commande précédente c'estla potion -c -d localhost:5433 -r 192.168.0.5:9000 qui nous intéresse. Une instance de Stunnel est ainsi lancée en mode client grâce au paramètre c et lui demander d'écouter sur le port 5433.Le paramètre -r 192.168.0.5:9000 indique à cette instance que la machine-serveur (jenna) a pour adresse 192.168.0.5 et que son port d'écoute est le 9000.
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 direnlr
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. Par exemple pour la requête
direnlr=# select * from geometry_columns limit 1; -[ RECORD 1 ]-----+------------- f_table_catalog | f_table_schema | public f_table_name | apb_lr f_geometry_column | the_geom coord_dimension | 2 srid | -1 type | MULTIPOLYGON
j'obtiens avec nast
---[ TCP ]-----------------------------------------------------------
192.168.0.4:45480(unknown) -> 192.168.0.5:9000(unknown)
TTL: 64 Window: 2546 Version: 4 Lenght: 126
FLAGS: ---PA-- SEQ: 2814905551 - ACK: 2149157549
Packet Number: 1
---[ TCP Data ]------------------------------------------------------
' jP;o , 9 e nH} .
---[ TCP ]-----------------------------------------------------------
192.168.0.5:9000(unknown) -> 192.168.0.4:45480(unknown)
TTL: 64 Window: 1984 Version: 4 Lenght: 126
FLAGS: ---PA-- SEQ: 2149157549 - ACK: 2814905625
Packet Number: 2
---[ TCP Data ]------------------------------------------------------
D n~ % N 4; r M { g.X= > q v 1 -N{W u @ A 9 *4l _K
---[ TCP ]-----------------------------------------------------------
192.168.0.4:45480(unknown) -> 192.168.0.5:9000(unknown)
TTL: 64 Window: 2546 Version: 4 Lenght: 52
FLAGS: ----A-- SEQ: 2814905625 - ACK: 2149157623
Packet Number: 3Installation en service de Stunnel
Pour l'installation 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 (Serveur PostgreSQL)
# à 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
Ne pas oublier d'adapter votre script de démarrage ( /etc/init.d/rc.local (pour Ubuntu) ou /etc/rc.d/rc.local...) sur la machine-cliente pour le commande/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
Pour aller plus loin
Il est tout à fait possible avec Stunnel d'utiliser le fichier de configuration de stunnel dans /opt/stunnel/etc/stunnel ou lui proposer un fichier personnel de configuration. Je ne me suis pas attarder à le proposer dans cette article afin de ne pas trop le surcharger.
Posted in version imprimable | Vous devez vous connecter ou vous enregistrer pour écrire des commentaires | 10129 lectures
Posté par david le 10 Janvier, 2007 - 16:50.