PostgreSQL et Stunnel


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:

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.

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!

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 -h localhost -p 5433 -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: 3

    Installation 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.