Le marché du Database Activity Monitoring (DAM) devenant de plus en plus important avec des produits tels que Imperva, Guardium ou Sentrigo, je me suis intéressé au produit Oracle Database Firewall, qu’Oracle présente comme un substitut aux différents acteurs du marché des DAMs.

Oracle Database Firewall est un système élaboré pour sécuriser et surveiller l’activité des bases de données SQL sur le réseau afin de détecter les accès non autorisés, les attributions de rôle avec des privilèges excessifs, d’auditer les procédures stockées, de parer les injections SQL ou autres tentatives d’attaques interne ou externe.

Les bases de données gérées par Oracle Database Firewall sont bien sur Oracle mais également Microsoft SQL Server, Sybase Adaptive Server Enterprise (ASE), Sybase SQL Anywhere, et IBM DB2.

Les principaux composants sont au nombre de trois :

  • un ou plusieurs database firewall qui analysent et enregistrent les transactions SQL et les envoient au Database Firewall Server
  • un ou plusieurs database firewall management server, qui regroupent les données reçues des différents database firewall, et servent également de plate-forme de reporting
  • un ou plusieurs database firewall analyzers qui lisent les fichiers créés par les Database Firewalls pour créer ou mettre à jour les polices utilisées afin de gérer les permissions, les autorisations concernant les requêtes SQL des différentes bases de données.

Il y a des contraintes hardware concernant l’installation des ces différents composants :

  • le database firewall analyzer s’installe uniquement sur un système windows
  • le database firewall et le database firewall management server s’installent sur un système intel x86 et nécessitent chacun 1 Go de RAM, une partition de 80 Go et 3 cartes réseau.
  • l’installation du Database Firewall efface entièrement les données du serveur sur lequel on réalise l’installation.

Je ne vais pas vous décrire la partie installation, mais plutôt décrire la partie configuration ainsi que l’utilisation des fonctionnalités Store Procedure et User Role Auditing.

Une fois les deux systèmes démarrés (Database Firewall et Database Firewall Management Server), l’écran d’accueil de chaque système Linux est le suivant:

Management Serveur :


Database Firewall :

Pour accéder au système proprement dit on utilise une combinaison des touches ALT+F1 … ALT+F5. Le système est complètement configuré lors de l’installation, on ne peut rien paramétrer : =((

Une instance Oracle dbfwdb existe sur les deux serveurs :

L’architecture installée est alors la suivante : source Oracle

La partie que je vais aborder dans ce blog est la configuration à mettre en place pour effectuer le monitoring d’une base de données.
Ce système de test a été élaboré avec les serveurs suivants :

  • un database firewall management server ip 192.168.1.12
  • un database firewall server ip 192.168.1.13
  • un serveur base de données ip 192.168.1.11

On se connecte tout d’abord sur la console d’administration du Database Firewall Management Server avec l’url https://192.168.1.12/user/login :

Il faut intégrer le database firewall dans le database firewall management server.
On se connecte au database firewall server avec l’url https://192.168.1.13/user/login et on clique sur l’onglet system puis dans Management Server :

On renseigne l’adresse ip du serveur de management et on recopie le certificat depuis la console d’administration du management serveur depuis l’onglet System, Certificate :

Puis on clique sur apply:

On se rend ensuite sur la console du management serveur et on crée une ”appliance” pour relier le Database Firewal Management Server au Database Firewall lui même. On se rend donc sur la console d’administration du Management serveur et on clique sur l’onglet Appliances.
On clique ensuite sur add pour renseigner le nom et l’adresse IP du Database firewall :

On clique sur l’onglet monitoring , puis dans Protected Database puis sur l’item Create, on renseigne les champs nécessaires, on clique sur add et enfin sur save settings :

Il faut ensuite créer un ”enforcement point” pour la base de données, on clique sur Create dans le menu Enforcement Point, on définit un nom on choisit l’appliance créée précédemment et on clique sur next :

On choisit le nom de la base à surveiller:

On choisit l’option logall qui récupère toutes les requêtes, attention cette option est consommatrice de place disque :

On clique sur next puis sur finish :

On peut visualiser le statut de l’enforcement point :

Il est affiché Monitoring not currently enabled ce qui signifie que les accès ssh ou en direct sur le serveur ne sont pas pris en compte.
Une fois cette configuration réalisée, nous allons tester deux points intéressants à savoir le Stored Procedure Auditing et le User Role Auditing.
La fonctionnalité Stored Procedure Auditing permet de visualiser les différentes modifications apportées aux procédures actuellement dans la base de données. Il y a tout d’abord une phase de configuration ou un utilisateur de base de données est crée dans la base de données à surveiller, puis une phase d’audit de toutes les procédures de la base de données.
Voici comment opérer :
Il faut tout d’abord récupérer dans les sources d’installation du Database Firewall les scripts spa_setup.sql et spa_drop.sql, puis lancer le script spa_setup.sql qui va créer un utilisateur sur la base de données à surveiller:
oracle@oracle11202:/u00/app/oracle/spa/dbfw-155/database/spa/ [DB112] sq SQL*Plus: Release 11.2.0.2.0 Production on Thu Jan 5 22:23:47 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – Production With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @spa_setup 
SPA setup script for Oracle
Database
username: as parameter 1:
Enter value for 1: spa_audit 
password: as parameter 2:
Enter value for 2:
oracle
old 1: create user &spa_username identified by &spa_username_password
new 1: create user spa_audit identified by oracle 
User created. 
old 1: grant create session to &spa_username
new 1: grant create session to spa_audit 
Grant succeeded. 
old 1: grant select on sys.dba_objects to &spa_username
new 1: grant select on sys.dba_objects to spa_audit
Grant succeeded. 
old 1: grant select on sys.dba_source to &spa_username
new 1: grant select on sys.dba_source to spa_audit 
Grant succeeded.

 
Puis sur la console d’administration dans l’onglet Monitoring, Enforcement Point on clique sur Settings et on active l’option Stored Procedure Auditing et on renseigne les informations demandées :

On voit qu’il est possible de scheduler l’audit des procédures stockées, mais dans le cadre de nos tests nous le lancerons manuellement. Il faut se rendre dans l’onglet Monitoring puis l’item Manage et on clique sur Run Now :

La procédure d’audit est lancée, les procédures stockées de l’instance Oracle sont analysées par la Database Firewall :

On voit qu’il y a 3047 Stored Procedure en mode pending, il faut effectuer un approval, on clique sur l’onglet Stored Procedure Auditing puis dans le sous menu Pending :

Et on clique sur Approve, les procédures stockées auditées passent du mode ”pending” au mode ”Approval” :

Maintenant que toutes les procédures sont en mode Approval, tout changement sera détecté par le Database Firewall.
Créons maintenant un procédure, et lançons à nouveau un audit des procédures stockées :

create or replace procedure test
as
begin
for i in 1..10
LOOP
insert into employe
select * from employe;
END LOOP;
commit;
end;
/

oracle@oracle11202:/u00/app/oracle/database/spa/ [DB112] sqlplus psi/psi

SQL*Plus: Release 11.2.0.2.0
Production on Thu Jan 5 23:00:27 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved.  
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 
SQL> @cr_proc 
Procedure created.

 
On visualise dans le menu Reporting qu’une nouvelle procédure est en mode ”Pending” :

En cliquant sur l’item Pending on visualise la nouvelle procédure PSI.TEST :

En cliquant sur le nom de la procédure PSI.test on visualise son code :

On accepte cette procédure :

Modifions maintenant cette procédure :

create or replace procedure test
as
begin
for i in 1..1000000
LOOP
null;
null
;
END LOOP;
commit;
end;
/

Relançons un audit des procédures on peut visualiser les modifications :



Pour le User Role Auditing, le principe est le même. On récupère les scripts ura_setup.sql et ura_drop.sql sur la distribution oracle et on crée un utilisateur sur la base de données à surveiller :
oracle@oracle11202:/u00/app/oracle/database/ura/ [DB112] sq 

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 
SQL> @ura_setup 
URA setup script for Oracle Database
username: as parameter 1:
Enter value for 1: ura_audit 
password: as parameter 2:
Enter value for 2: oracle
old 1: create user &ura_username identified by &ura_username_password
new 1: create user ura_audit identified by oracle 
User created. 
old 1: grant create session to &ura_username
new 1: grant create session to ura_audit 
Grant succeeded. 
old 1: grant select on sys.dba_users to &ura_username
new 1: grant select on sys.dba_users to ura_audit 
Grant succeeded. 
old 1: grant select on sys.proxy_users to &ura_username
new 1: grant select on sys.proxy_users to ura_audit 
Grant succeeded. 
old 1: grant select on sys.dba_role_privs to &ura_username
new 1: grant select on sys.dba_role_privs to ura_audit 
Grant succeeded. old 1: grant select on sys.dba_sys_privs to &ura_username
new 1: grant select on sys.dba_sys_privs to ura_audit 
Grant succeeded. 
old 1: grant select on sys.v_$pwfile_users to &ura_username
new 1: grant select on sys.v_$pwfile_users to ura_audit 
Grant succeeded.

Puis de la même manière que pour l’audit des procédures stockées, on active l’audit des rôles utilisateurs depuis le menu Enforcement Point , Manage, Settings :

On lance un audit des rôles utilisateurs, qui va analyser les rôles de la base de données, puis on les approuve :


Créons ensuite un nouvel utilisateur scoot et donnons les droits dba par exemple à l’utilisateur scott et relançons un audit manuellement :
On crée un nouvel utilisateur :

SQL> create user scoot identified by tiger; 
User created.

On visualise dans le menu reporting , User Auditing Summary qu’un nouvel utilisateur a été créé :


Affectons le droit dba aux utilisateurs scoot et scott :

SQL> grant dba to scoot; 
Grant suceeded. 
SQL> grant dba to scott; 
Grant suceeded.

 

 

 

Conclusion :

Le produit Oracle Database Firewall est une solution qui travaille au niveau du réseau. Par conséquent il ne peut pas capturer ce qui ne transite pas par le réseau. Cependant il peut être une solution intéressante en conjonction avec les autres outils de sécurité Oracle, tels que Oracle Database Vault ou Oracle Audit Vault.
Dans les points positifs je relèverai la relative facilité d’appréhension et de configuration du produit, ainsi que l’utilisation de la partie reporting du Database Firewall Management Server.
Dans les points négatifs, la partie Linux et base de données Oracle installés sur les deux serveurs ne sont pas configurables lors de l’installation, l’administration UNIX / Oracle de ces serveurs ne doit pas en être facilitée. De plus la partie audit des procédures et des utilisateurs présente un trou de sécurité dès lors que ces audits sont schédulés à certaines heures de la journée.
D’autres fonctionnalités importantes à tester tels que le blocage de transactions SQL vers la base de donnée en utilisant une méthode de White List / Black List, la protection de la base de données contre des injections SQL seront testées prochainement et je vous ferai part de mes conclusions dans un prochain blog.
À suivre …