Comment crypter le trafic réseau entre une base de données Oracle et un client ?

Problématique :

Dans la plupart des cas, les DBAs négligent de sécuriser le flux d'information qui circule entre les base de données Oracle et les postes client ou les serveurs d'applications.  Ce flux qui transite ainsi en clair via le réseau peux être intercepté et adieu !!! la confidentialité.

Solution :

Oracle Advanced Security inclus la possibilité de crypter le trafic entre les base de données et les clients. 

Le scénario est le suivant :
Nous allons installer Oracle database 11gR2 et créer une base de données.
Nous utiliserons un sniffer de réseau tel que TCPDUMP (sur le serveur de base de données) pour écouter le trafic réseau. 
Par la suite nous allons lancer des requêtes vers notre base de données et voir les données non cryptées qui transitent via le réseau; ensuite nous allons crypter nos données et refaire les mêmes requêtes.

Test effectué dans les environnements suivant :
      - Environnement virtuel VMWare Workstation

      - OS : RHEL 5

      - DB : Oracle 11gR2 

1. Installer Oracle 11gR2 et créer une base de données que vous pourriez appeler orcl; optez pour les ''schémas exemple'' lors de la création de la base.

2. Se connecter en tant que root et vérifier que le package tcpdump est bien installer sur notre système dans le cas contraire l'installer. Ne fermer pas ce terminal, il nous servira dans la suite.

3. Ouvrez un autre terminal en tant user oracle et démarrer tous les services services et connectez vous à votre base de données.

     

Le listener

La base de données

4. Connectez-vous à votre base de données puis créez une table et y insérer des données

NB:

Ne pas oublier de vous connecter en précisant le nom du service pour que les données transitent via le réseau: sqlplus hr@orcl

Nous allons créer une table clients (customers) de 4 colonnes qui contiendra:
customer_id : L'identifiant du client
customer_name : Nom du client
customer_ccnumber : Numéro de carte de crédit du client
city : Ville de résidence du client

Puis y insérer des données, ne fermer pas le terminal

5. Nous allons maintenant lancer tcpdump puis exécuter une requête sur notre base de données et voir le résultat.

Lancer TCPDUMP dans le terminal de la session root via la commande :

/usr/sbin/tcpdump -Xs 1500 -i lo port 1521

Cela vous permettra de voir le trafic réseau sur l'adaptateur lo et le port 1521, ce port doit être celui de votre listener, dans mon cas c'est le 1521; pour le reste, je vous ferai l'économie de l'explication des options de la commande, il y'a des sites bien plus élaborés à cet effet tel que: 

http://lea-linux.org/documentations/Tcpdump

Au bout de quelque seconde, une fenêtre de ce type s'affiche :

6. Dans le terminal ayant servi à créer notre table, nous allons afficher toutes les lignes de cette dernière

7. Observer dans le terminal tcpdump les données qui transitent via le réseau, vous remarquerez qu'elles ne sont pas cryptées.

Si les données passent rapidement et que vous n'avez pas le temps de voir, vous pouvez ré-exécutez la requête dans le terminal sqlplus en tapant la barre oblique '/'. Ou tout simplement, vous pouvez rediriger tout le trafic  vers un fichier précis.

L'idéal est de mettre les 2 fenêtres côte à côte.

Sur l'image ci-dessous, nous pouvons voir le texte de la requête exécutée

Sur celle-ci nous voyons bien le résultat de cette requête

Ainsi des données sensibles ou confidentielles peuvent tomber dans les mains d'une personne qui n'en a pas droit.
Faite les touches <<Ctl>>+<<C>> pour arrêter l'action de tcpdump

8. Nous allons maintenant crypter les données; pour cela, nous avons besoins de modifier notre fichier SQLNET.ORA situé dans $ORACLE_HOME/network/admin

Nous allons y ajouter un certain nombre de paramètres :
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED

SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(MD5)
SQLNET.ENCRYPTION_TYPES_SERVER=(DES40,RC4_40)
SQLNET.CRYPTO_SEED="Mettre ici une chaîne de 10 à 70 caractères"

SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(MD5)
SQLNET.ENCRYPTION_TYPES_CLIENT(DES40,RC4_40)
CRYPTO_CHECKSUM_TYPES_SERVER = (MD5)

Pour plus de détails sur les paramètres, rien de plus précis que la doc Oracle https://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#NETRF006

9. Relancez tcpdump dans le terminal root puis ré-exécutez la requête

Cette fois-ci, vous remarquez que le résultat de la requête est cryptée. Ainsi le risque de voir des informations confidentielles tombées dans des mains non autorisées est éliminée.

Bien entendu, il faudra également configurer le fichier sqlnet.ora du côté client; dans le cas contraire, les connexions au serveur seront refusées.

Dans la pratique, il est indéniable que le sniffer de réseau sera utilisé sur un post différent du serveur de base de données. Dans ses options, tcpdump vous permet d'écouter un hôte précis.

Comment imposer le mot de passe pour l'accès SYSDBA ?

Problématique :

Dans une entreprise où plusieurs DBA travaillent sur la même base de données, pouvoir se connecter avec le privilège sysdba sans fournir de compte et de mot de passe peut constituer une faille de sécurité d'autant plus que la base de données ne retiendra que l'utilisateur générique SYS.

Comment éviter alors de se connecter de la sorte :  "sqlplus / as sysdba" ou "conn / as sysdba" sans fournir de mot de passe ?

Solution :

Tests effectués dans les environnements suivant :
      - Environnement virtuel VMWare Workstation

      - OS : RHEL 5

      - DB : Oracle 11gR2 

1. Paramètre SQLNET.AUTHENTICATION_SERVICES du fichier sqlnet.ora

Ce paramètre permet d'activer ou non les services d'authentification mis en place pour les bases de données.

        a- Editer le fichier $ORACLE_HOME/network/admin/sqlnet.ora

        b- Y ajouter la ligne SQLNET.AUTHENTICATION_SERVICES=NONE puis enregistrer et fermer.

Ceci permet de forcer les utilisateurs os définit dans le group dba à fournir un login et un mot de passe valide pour se connecter à la base de données.

Cependant un utilisateur aguerrit peux facilement contourner cette solution en modifiant le paramètre pour pouvoir se connecter sans mot de passe puis remettre la valeur initiale.

2. Groupes os DBA et OPER...

Cette second option consiste à supprimer l'utilisateur os oracle (ou tout autre que vous aurez utilisé) des groupes DBA et OPER

        a- [root@ladollhost01~]# gpasswd -d oracle dba

        b- [root@ladollhost01~]# gpasswd -d oracle oper

Une fois cette manipulation effectuée, l'utilisateur os oracle ne pourra plus se connecter sans fournir de mot de passe.

Cependant, la faille de cette méthode est que si l'utilisateur qui cherche à accéder à la base de données est le root, il a la possibilité d'ajouter l'utilisateur oracle aux groupes ou encore de créer de nouveaux utilisateurs et les ajouter aux groupes dba et oper afin de se connecter sans mot de passe.

3. Fichier $ORACLE_HOME/rdbms/lib/config.c

Cette option permet de modifier le groupe dba et oper qui sont les groupes classique que l'on créé pour installer Oracle. 

L'objectif ici est de tromper celui qui cherche à se connecter sans mot de passe par le biais de l'utilisateur os Oracle.

Tous les processus oracle doivent être arrêtés.

       a- Editer et modifier le fichier $ORACLE_HOME/rdbms/lib/config.c

           [root@ladollhost01~]# vi $ORACLE_HOME/rdbms/lib/config.c

             ----------

             #define SS_DBA_GRP "dba"

             #define SS_OPER_GRP "oper"

             #define SS_ASM_GRP ""

             char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};

       b- Après modification, enregistrer et fermer le fichier

           Le contenu du fichier peut ressembler à celui-dessous :

             [root@ladollhost01~]# cat $ORACLE_HOME/rdbms/lib/config.c

              ----------

             #define SS_DBA_GRP "laddba"

             #define SS_OPER_GRP "ladoper"

             #define SS_ASM_GRP ""

             char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};

         Pour les système UNIX tel que SOLARIS SPARC ce sera :

             .ascii "laddba\0"
             .ascii "ladoper\0"

        c- Faire un relink des binaires

             [root@ladollhost01~]# $ORACLE_HOME/bin/relink all

    

Une fois vous aurez redémarré votre base de données et tous les services afférents, il sera impossible à quiconque de se connecter sans fournir de login et de mot de passe.

Une fois n'étant pas coutume, l'utilisateur root expérimenter en Oracle pour réussir à contourner cette protection; il lui suffira pour cela de créer au niveau os les nouveaux groupes que vous ajouter au fichier $ORACLE_HOME/rdbms/lib/config.c puis d'ajouter l'utilisateur oracle dans ces groupes. Il peut encore tout simplement remettre les noms des anciens groupes.

L’idéal est de ne pas préciser de groupe, cela rendra les choses plus difficile à contourner l'accès sans mot de passe.

             #define SS_DBA_GRP ""

             #define SS_OPER_GRP ""

 3. Database Vault 

La solution la plus fiable pourrait être d'implémenter Database Vault, sujet que nous pourrons traiter dans nos posts futur.