securiday 2012 pro edition - securinets.com base de... · visualisation des enregistrements daudit...

SECURINETS

CLUB DE LA SECURITE INFORMATIQUE INSAT

SECURIDAY 2012 Pro Edition

Atelier audit de base de données

Chef Atelier : Bilel BARHOUMI (GL 3) Ahmed BEN REHAYEM (RT 3)

Maha ROMDHANI (RT 3) Oussema KHLIFI (RT 3) Said IBRAHIM (GL 3)

28/04/2012

Securinets Securiday 2012 pro Edition Audit de base de données

2

Table des matières I. Présentation de l’atelier : .................................................................................................. 4

1. But : ............................................................................................................................... 4

2. Quelques notions : ........................................................................................................ 4

i. Base de données : ...................................................................................................... 4

ii. SGBD : ........................................................................................................................ 4

iii. Audit : ........................................................................................................................ 5

3. Les différents niveaux de l'audit de base de données : ................................................ 5

i. Audit de structure :.................................................................................................... 5

ii. Audit de qualité des données : .................................................................................. 5

iii. Audit de configuration et de performances : ............................................................ 5

iv. Audit des requêtes clientes : ..................................................................................... 6

v. Audit d'infrastructure réseau : .................................................................................. 6

II. Présentation des outils utilisés : ........................................................................................ 6

SGBDs : .................................................................................................................................. 6

Outils d’investigation : ........................................................................................................... 6

III. Topologie du réseau : .................................................................................................... 7

IV. Configuration des outils : .............................................................................................. 7

1. Microsoft Sql Server : .................................................................................................... 7

i. Création des instances d’objets de SQL Server : ....................................................... 8

ii. Création des objets de spécification d’audit serveur .............................................. 10

iii. Création des objets de spécification d’audit de bases de données : ...................... 12

iv. Visualisation des enregistrements d’audit : ............................................................ 12

2. Oracle 11g : .................................................................................................................. 16

i. Logminer : Explorer les fichiers Redo Logs et Archive Logs : ................................... 16

ii. Le Flash-Back : ......................................................................................................... 19

3. MySql 5.5 : ................................................................................................................... 22

i. Préparation du serveur ............................................................................................ 22

ii. Activation du log à la volée ..................................................................................... 22

iii. Désactivation des logs ............................................................................................. 22

iv. Visualisation du fichier log :..................................................................................... 23


3

V. Un scénario de test : ........................................................................................................ 23

VI. Conclusion: .................................................................................................................. 29

1. Changer le mot de passe par défaut ........................................................................... 29

2. Refuser les connexions distantes ................................................................................ 29

3. Supprimer les comptes inutiles ................................................................................... 29

4. Supprimer la base de données d’exemple .................................................................. 29

5. Activer les logs et les externaliser ............................................................................... 29

6. Exécuter le service avec un compte de service ........................................................... 29

7. Restreindre les privilèges des utilisateurs ................................................................... 30

8. Chiffrer les données stockées ...................................................................................... 30

9. Appliquer les patchs de l’éditeur................................................................................. 30


4

I. Présentation de l’atelier :

1. But : Notre atelier consiste à analyser l'existant d'une base de données (ou d'un ensemble

cohérent de bases de données) plus ou moins profondément afin d'en diagnostiquer l'état et

de préconiser des améliorations, essentiellement sur le plan de la conformité et des

performances.

2. Quelques notions :

i. Base de données :

Une base de est une entité dans laquelle il est possible de stocker des données de

façon structurée et avec le moins de redondance possible. Ces données doivent pouvoir être

utilisées par des programmes, par des utilisateurs différents.

ii. SGBD :

Un système de gestion de base de données (SGBD) est un ensemble de logiciels qui

manipulent le contenu des bases de données. Il sert à effectuer les opérations ordinaires

telles que rechercher, ajouter ou supprimer des enregistrements, manipuler les index, créer

ou copier des bases de données.

Les SGBD sont équipés de mécanismes qui effectuent des vérifications à l'insu de

l'utilisateur, en vue d'assurer la réussite des transactions, éviter des problèmes dus à la

concurrence et assurer la sécurité des données.


5

Les principaux systèmes de gestion de base de données sur le marché : IBM DB2,

Oracle Database, MySQL, PostgreSQL et Microsoft SQL Server

iii. Audit :

L'audit, exercé par un auditeur, est un processus systématique, indépendant et

documenté permettant de recueillir des informations objectives pour déterminer dans

quelle mesure les éléments du système cible satisfont aux exigences des référentiels du

domaine concerné.

3. Les différents niveaux de l'audit de base de données :

i. Audit de structure :

Il s'agit de montrer si la structure de la base est en adéquation avec les exigences

fonctionnelles et particulièrement adaptée à l'usage qui en est fait (requêtes). On vérifiera

en particulier que le modèle de données a été respectueux des règles de l'art : modélisation

relationnelle (MCD, MLD), respect des formes normales, contraintes de domaine, schéma

externe... et correspond à la nécessité de service.

ii. Audit de qualité des données :

Il s'agit de vérifier que la base n'est pas polluée par de nombreuses données inutiles

ou erronées. En particulier on vérifiera l'existence de contraintes telles que : contraintes de

domaine, intégrité référentielles, unicité, validation, format (notamment les formats

normalisés de données)...

iii. Audit de configuration et de performances :

Il s'agit de vérifier si la configuration du serveur logique (SGBDR) et du serveur

physique (hardware) est conforme aux exigences du service des données : en particulier

RAM, disques, processeurs, paramétrages à tous niveau.


6

Cela nécessite de tracer l'activité du serveur sur divers plans techniques puis

d'analyser les données recueillies à l'aide de différentes techniques et moyens qui peuvent

faire l'objet de plusieurs passes successives pour affinement.

iv. Audit des requêtes clientes :

Il s'agit de vérifier :

- le style de développement adopté (requêtes adhoc, emploi de procédures stockées,

mapping relationnel objet...),

- la qualité de l'écriture des requêtes et l'indexation des tables.

On procède à l'aide de différentes techniques en fonction de la façon dont est écrit

le programme applicatif, techniques qui peuvent être combinées (analyse d'échantillon,

traçage de l'activité du moteur SQL, revue de code...).

v. Audit d'infrastructure réseau :

Il s'agit de vérifier ce qui se passe entre les serveurs SQL et les "clients". Ces clients

pouvant être d'autres serveurs (Web, objet...) ou des clients applicatifs finaux.

Il faut mesurer les temps de réponse effectifs (trames) et ressentis (utilisateur).

II. Présentation des outils utilisés :

SGBDs : Pour la réalisation de cet atelier, on a choisi quelques SGBQ qui sont très utilisés

dans les entreprises :

Oracle 11g : Oracle est un système de gestion de base de données relationnelle

produite par Oracle Corporation, c’est un des SGBD les plus rapide et performant disponible

sur le marché.

Microsoft SQL Server 2008 R2: SQL Server est un SGBD relationnel produit par

Microsoft, c’est un des concurrents direct d’oracle.

MySQL 5.5: MySQL est un SGBD relationnel open source très populaire, il est

largement utilisé dans les sites web vu sa licence flexible et son faible cout.

Outils d’investigation :

SQLMap : c’est un outil permettant d’effectuer des requêtes SQL de manières

automatisées dans le but de trouver et d’exploiter une mauvaise configuration sur un

serveur Web.

Tamper Data : est une extension (add-on) Firefox qui vous donne le pouvoir de

visionner, enregistrer et même de modifier les requêtes HTTP sortantes.


7

III. Topologie du réseau : Pour la configuration des SGBDs on va travailler sur la même machine contenant le

SGBD.

Pour la partie injection Sql on utilise notre ordinateur qui doit être connecté au

serveur web contenant le web : soit via internet soit réseau locale.

IV. Configuration des outils : Cette partie concerne tous ce qui est configuration de chaque outil. Elle doit comporter

toutes les commandes que vous avez utilisés (en expliquant bien sûr à quoi elles servent) et

éventuellement des imprimes écran qui montrent les résultats obtenus.

1. Microsoft Sql Server : SQL Server 2008 propose une nouvelle fonctionnalité d'audit unifiée qui permet de

mettre en place facilement ces audits ce qui permet à un administrateur de bases de

données de se concentrer uniquement sur le véritable enjeu : trouver les audits qui seront

en adéquation avec les besoins de l'entreprise.

Nous utiliserons le langage TSQL pour créer nos objets d'audits. Il est cependant

possible d'arriver au même résultat avec la console graphique de gestion des bases de

données SQL Server Management Studio.


8

i. Création des instances d’objets de SQL Server :

Commençons par créer 3 instances d’audit :

Comme résultat, les 3 instances sont créées :


9

Après avoir créé et activé les objets d'audit SQL Server pour les 3 cibles concernées,

il faut ensuite effectuer un paramétrage supplémentaire pour que SQL Server soit autorisé à

écrire dans le journal de sécurité Windows. Pour cela nous utiliserons la console de gestion

des stratégies locales du serveur.

Autoriser le compte de service SQL Server à générer des audits de sécurité :

Panneau de configuration > Système et sécurité > Outils d’administration > Attribut de des

droits utilisateurs > Générer des audits de sécurité.

Ajouter le compte de service du serveur SQL :

Dans notre cas nous ajouterons le compte LOCAL SYSTEM


10

Activer les audits d'accès sur les objets :

Console de gestion des stratégies locales > Stratégie d'audit > Auditer l'accès aux objets.

Activer les audits pour les 2 types d'accès : Réussite et Echec

ii. Création des objets de spécification d’audit serveur

Il faut maintenant créer deux objets de spécification d'audit au niveau de l'instance

SQL Server :

Un objet de spécification d'audit sera à l'écoute des événements ou actions

concernant les changements sur les comptes de connexion.

Un deuxième objet de spécification d'audit sera, quant à lui, destiné aux

changements d'état intervenant sur le serveur.


11

On peut vérifier la création des deux spécifications d’audit créées comme indiqué dans la

figure ci-dessous :

Ajouter à l'objet de spécification d'audit serveur nommé audit_modif_users_login le

groupe d'événement SERVER_PRINCIPAL_CHANGE_GROUP qui permet de surveiller, entre

autres, les événements de création, de suppression et de modification de compte de

connexion.

Il faudra, au préalable, le désactiver pour pouvoir le modifier.


12

iii. Création des objets de spécification d’audit de bases de données :

iv. Visualisation des enregistrements d’audit :

Audit de sécurité des comptes de connexion :

On va simuler quelque action sur les comptes de connexion pour pouvoir après les

récupérer dans les fichiers journaux :

Création des comptes de connexion :


13

Modification de mot de passe des comptes :

Ajout de compte de connexion test1 au role fixe de serveur sysadmin

Regarder dans le journal de sécurité de Windows :


14

Voici un exemple de ce que l'on trouve dans le journal après avoir exécuté les scripts

TSQL ci-dessus :

Audit de changement d’état du serveur SQL :

Initions maintenant un changement dans les options de configuration du serveur.

Nous autorisons la procédure xp_cmdshell.


15

Redémarrer le serveur de bases de données en utilisant l’invite de commande :

Audit des accès à la table dbo.users :

Tout d’abord, on commence par faire des requetes SQL : Select, Update, Insert,

Delete…

Pour consulter les journaux d’audit de la base de données :


16

Le résultat est le suivant :

On voie que SQL Server 2008 possède un outil d'audit extrêmement puissant. Cette nouvelle

fonctionnalité permet de répondre parfaitement aux aspects sécurité, performance et

gestion.

2. Oracle 11g :

i. Logminer : Explorer les fichiers Redo Logs et Archive Logs :

Logminer permet de scruter les fichiers REDOLOG (en ligne ou archivés) et dévoiler

les transactions s'y trouvant. Les transactions sont trouvées sur la base des requêtes SQL.

La vue V$LOGMNR_CONTENTS fournit les instructions SQL que ORACLE a exécuté

ainsi que les ordres SQL nécessaires pour revenir en arrière (UNDO). Cette vue doit être

peuplée avec le contenu des fichiers REDOLOG.

Grâce à l’outil logminer on peut :

Repérer l’heure exacte d’exécution d’une commande

Identifier les commandes passées

Générer un script permettant de passer l’inverse des commandes sans passer par

une restauration incomplète


17

Répertorier l’ensemble des instructions passées dans une même transaction

Calculer des statistiques d’accès aux objets

Trouver l’origine de la génération d’un gros volume de redo logs

La lecture du fichier REDOLOG :

Etape N° 1 :

Connexion en user SYS : en utilisant l’invite de commande Sqlplus d’Oracle (menu

démarrer > tous les programmes > Oracle Data Base > Outil d’administration)

On exécute le DBMS_LOGMNR avec le path des fichiers redolog à analyser :

SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(logfilename =>

‘C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG\O1_MF_1_7OT7NDO0_.LOG’,o

ptions => DBMS_LOGMNR.new);

SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(logfilename => '

C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG\O1_MF_2_7OT7NHON_.LOG,op

tions => DBMS_LOGMNR.new);


18

Vous pouvez voir les dates/heures des switch logfile et les SCN par cette requête :

SQL> SELECT FILENAME, LOW_TIME, HIGH_TIME, LOW_SCN, NEXT_SCN

FROM V$LOGMNR_LOGS;

Etape N° 2 :

On démarre LOGMINER.

A partir de cet instant une vue V_$LOGMNR_CONTENTS sera disponible et alimentée.

SQl> EXECUTE DBMS_LOGMNR.START_LOGMNR(options=>

DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.NO_ROWID_IN_STMT +

DBMS_LOGMNR.NO_SQL_DELIMITER);

Etape N° 3 :

On interroge la vue V_$LOGMNR_CONTENTS ou la table V$LOGMNR_CONTENTS.


19

SQL> SELECT USERNAME AS USR, SEG_OWNER AS OWNER, Table_name, Operation,

SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS;

Etape N° 4 :

On ferme LOGMINER. La vue V_$LOGMNR_CONTENTS est purgée.

SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR();

On ré exécute l’étape 1 à 4 pour analyser un autre redolog.

ii. Le Flash-Back :

Le flashback permet de récupérer un ensemble de données ou d’objets dans le passé

puis de les réinjecter dans la base de données. La technologie d’Oracle 10g ou 11g, offre la capacité d’interroger des versions anciennes de schéma d’objets ou de données.

Le « flashback » a été créé pour réparer facilement les données corrompues d’une table par un batch, en réinjectant dans la base de données les données récupérées avant le passage du batch grâce au flashback.

Le flashback permet un retour arrière dans la base de données afin de sélectionner des objets ou parties d’objets pour les réinjecter dans la version actuelle de la base de données.


20

La technologie flashback permet d’assurer vite et facilement une réparation à tous les niveaux :

Flashback database : vous laisse rapidement ramener votre base à un point dans le temps en réparant toutes les modifications apportées depuis cet instant.

Flashback table : vous permet de retrouver rapidement une table et son contenu à un moment dans le passé.

Flashback Query : vous laisse voir les modifications apportées par une transaction à une ou plusieurs données, accompagnées de ses métadonnées.

SIMULATION :

Instructions étape par étape sur la configuration de base de données flash-back dans base de données Oracle 11gR2 est donnée ci-dessous:

1> La base de données doit être en mode ARCHIVELOG. Si ce n'est pas configurer le mode ARCHIVELOG

SQL> select log_mode from v$database;

2> Définissez les paramètres d'initialisation SQL> alter system set db_recovery_file_dest_size=3G;

SQL> show parameter db_recovery_file_dest

SQL> alter system set db_flashback_retention_target=120;


21

3> Effectuez un arrêt de la base de données SQL> shutdown immediate;

4> Démarrage de l'instance de base de données oracle et l'amener à monter Etat SQL> startup mount;

5> Activer la journalisation flashback. À ce stade, la base de données flash-back est activé. SQL> alter database flashback on; SQL> select * from v$bgprocess where name='RVWR';

6> Ouvrez la base de données SQL> alter database open ;


22

3. MySql 5.5 :

MySQL a plusieurs fichiers de log qui peuvent vous aider à savoir ce qui se passe à l'intérieur

de mysqld:

Fichier Description

Le log d'erreurs Problèmes rencontrés lors du démarrage, de l'exécution ou de l'arrêt de mysqld.

Le log ISAM Garde une trace des changements liés au tables ISAM. Utilisé uniquement pour déboguer le code ISAM.

Le log de requêtes Connexions établies et requêtes exécutées.

Le log de mises à jour

Désapprouvé : Enregistre toutes les commandes qui changent les données.

Le log binaire Enregistre toutes les commandes qui changent quelque chose. Utilisé pour la réplication.

Le log des requêtes lentes

Enregistre toutes les requêtes qui ont pris plus de long_query_time à s'exécuter ou celles qui n'ont pas utilisé d'index.

i. Préparation du serveur

Il va quand même falloir redémarrer le service au moins une fois pour activer un

paramètre par défaut : l'emplacement du fichier de log.

Pour ce faire, il suffit d'éditer le fichier my.ini (ou my.cnf sous Linux) et

d'ajouter/modifier la directive suivante :

general_log_file = c:/MySQL/Logs/query.log

Il faut donc logiquement redémarrer le service pour prendre en compte ce

paramètre.

ii. Activation du log à la volée

Dans une invite de commande MySQL ou tout autre outil capable d'exécuter des

requêtes mysql avec un utilisateur ayant des droits d'admin, il faut lancer la commande

suivante :

SET GLOBAL general_log = 'ON';

Les logs sont activés et ajoutés au fichier défini ci-dessus.

iii. Désactivation des logs

Il suffit de repasser le paramètre à OFF :

SET GLOBAL general_log = 'OFF';

Le fichier de log est alors déverrouillé par MySQL et nous pouvons le manipuler comme nous

le souhaitons (déplacement, suppression,...)


23

iv. Visualisation du fichier log :

Accéder au fichier « c:/MySQL/Logs/query.log »

On trouve tous les requêtes exécutées par le SGBD avec les dates.

V. Un scénario de test : L’administration de la bibliothèque de l’INSAT a demandé à des étudiants de créer

un site web qui facilite la gestion de la bibliothèque. Ce site permet aux étudiants de

chercher de livres dans la bibliothèque. Il permet aussi aux bibliothécaires d’ajouter des

livres et de faire les emprunts des livres.

Vu que ce site va être à la disposition des étudiants, on nous a appelés pour vérifier

la sécurité des données contre la suppression et la modification.

Pour faire ce diagnostic on va utiliser l’injection sql à travers le site.

Voilà le site que on va travailler dessous. :


24

On choisit l’url encerclé pour faire notre injection.

On a besoin aussi de récupérer le cookie : pour cela on utilise Tamper data (menu

outil de Firefox).

Et l’injection est réalisé par l’outil Sqlmap qui est un outil gratuit et inclue dans la

distribution Backtrack.


25

i. Tester si l’url est vulnérable ou pas.

-u (url) : l’url choisie

--cookie : le cookie fourni par le serveur web pris de Tamper Data

--dbs (data base system) : pour afficher le SGBD

Le résultat de la requête :

l’url est vulnérable

il retourne les informations concernant le sgbd, la technologie web et les différents

bases de données.


26

Notre site permet la recherche des livres dans une bibliothèque. Donc, on va choisir

la base de données Bibliothèque comme cible.

ii. Affichage des tables :

-D : la base de données

--tables : afficher tous les tables

On s’intéresse à la table « user » car on voit qu’elle peut contenir les mots de passe des

administrateurs.

iii. Affichage de structure de la table use :


27

iv. Affichage du contenue de la table user :

On peut aussi voir le contenu de la base de données mysql qui contient tous les

informations en relation avec le SGBD :

Affichage des différentes tables :


28

Affichage et téléchargement du contenue de la table user :

Résultat : Sqlmap sauvegarde le résultat dans un fichier comme le suivant :

Sécurisation contre les injection Sql :


29

Dans le cas où on utilise un entier dans notre variable :

$id = $_GET["id"];

if ((!$id) || (!ereg("^[0-9]+$", $id))) exit("Pas de page à cette addresse");

Vérifier si la variable entré est un nombre ou non

VI. Conclusion: Comme conclusion voici quelques conseils de première nécessité pour sécuriser

votre base de données. Ceux-ci doivent néanmoins être accompagnés de mesures de

sécurisation de votre système d’exploitation et de votre moteur d’application.

1. Changer le mot de passe par défaut Avant de passer à table, Scott et Tiger se lavent les mains. Même chose lorsque nous

avons terminé l’installation de notre base de données : il faut systématiquement modifier

les mots de passe par défaut.

2. Refuser les connexions distantes Pour ne pas tenter le diable, nous allons également nous assurer que le service de

base de données n’est pas exposé sur une adresse IP publique. Par défaut, nous devrons

nous assurer qu’il est en écoute sur l’interface loopback (127.0.0.1) ou une socket système.

3. Supprimer les comptes inutiles Nous allons ensuite supprimer les accès aux données qui nous paraissant inutiles :

c’est assez simple, nous supprimons tous les comptes d’accès configurés après l’installation,

à l’exception bien entendu du compte d’administration principal (root, sa, …).

4. Supprimer la base de données d’exemple Suivant la règle « tout ce qui ne nous sert pas doit être supprimé », nous allons faire

de même avec les bases ou tables de données livrées à l’installation pour servir d’exemples.

Attention, tous les moteurs ne sont pas livrés avec ce type de données.

5. Activer les logs et les externaliser L’activation des fichiers de logs doit être un réflexe de la première heure. En cas

d’interruption du service, d’incidents logiciels ou matériels, ou d’intrusion sur le système, les

journaux d’activités permettront de mieux analyser la situation et de prendre les mesures

nécessaires.

6. Exécuter le service avec un compte de service Les moteurs de bases de données sont généralement conçus pour n’utiliser que des

droits limités sur le système d’exploitation. Les répertoires et les ports d’écoute utilisés en

standard sont en effet au sein d’un contexte utilisateur et non celui du noyau.


30

7. Restreindre les privilèges des utilisateurs Dans une démarche toujours pragmatique, nous allons nous assurer que les

privilèges fournis aux utilisateurs de la base de données sont en adéquation avec le besoin

fonctionnel. Le compte utilisé pour se connecter à la base et y consulter des données au

travers d’un script PHP, n’aura nullement besoin de droits d’écriture ou de suppression.

8. Chiffrer les données stockées Les moteurs les plus récents proposent tous en standard ou via un module

additionnel, des options de chiffrement des données. Ne nous gênons pas pour activer

l’option si nos bases de données sont constituées de données sensibles.

9. Appliquer les patchs de l’éditeur Cela semble relever de l'évidence même, mais une fois les phases d'installation, de

configuration et de recette terminées, beaucoup d’entre nous oublient que nos logiciels

s’inscrivent dans un cycle de vie parfois mouvementé.

securiday 2012 pro edition - securinets.com base de... · visualisation des enregistrements daudit...

Documents