Introduction
En lisant cet article, si vous êtes un architecte ou que vous êtes un DBA qui va présenter ce logiciel à votre architecte, je connais déjà la remarque qui va arriver : Encore un firewall ! Mais j’en ai déjà 8 dans mon infrastructure ! Oui mais non parce que Oracle Database Firewall est plus qu’un simple firewall…
S’il y avait un produit où j’étais sceptique de sa pertinence et mon boss le premier : c’était Oracle Database Firewall. Sur le papier, il analyse tout le traffic de votre base de données et bloque les requêtes inhabituelle ( SELECT * sans clause WHERE sur une table sensible, injections SQL etc…)
Tous les rapports de sécurité informatique, y compris le Verizon 2010 Data Breach Investigations Report montrent bien que les injections SQL sont parmi les attaques privilégiées des pirates et sont celles qui causent le plus de dégâts/fuites.
J’ai donc décidé de m’y intéresser de plus près et finalement j’ai été agréablement surpris alors prenez le temps de lire cet article. Des réponses à des questions fréquentes est disponible à fin de l’article pour répondre à la plupart de vos interrogations.
Comment ça marche ?
Oracle Database Firewall fonctionne par « Learning Mode ». Vous le mettez quelques temps à analyser le traffic sans bloquer, il enregistre les patterns des requêtes usuels et ensuite vous le mettez en mode « bloquant ». Une intervention humaine sera nécessaire pour lui indiquer quels sont les bons et les mauvais patterns.
Lorsqu’il verra une requête qu’il y a un pattern qu’il n’a pas vu : il bloque ! Cela peut donc vous éviter des individus trop curieux qui utilisent mal votre logiciel ou encore des injections SQL etc…
Des exceptions devront être placées aussi qu’il ne pourra pas connaître dans le « learning mode » comme vos DBAs par exemple qui doivent être mis en liste blanche.
Les différents modes de fonctionnement
A noter que Oracle Database Firewall n’est seulement limité à un blocage de requêtes, il peut avoir 2 modes distincts de fonctionnement :
- White list based : Par défaut, il bloque tout sauf ce que vous lui spécifier comme correct
- Black list based : il autorise tout sauf ce que vous lui spécifier comme mauvais.
A l’intérieur de ces deux modes, vous pouvez y ajouter plusieurs variantes :
Vous pouvez décider de :
- Autoriser
- Autoriser en loggant cet accès
- Alerter quelqu’un de cet accès
- Modifier la requête : rajouter un AND 1=0 dans la requête pour retourner aucune ligne plutôt que de retourner une erreur par exemple
- Bloquer complètement la requête et retourner une erreur au client.
Comment l’installer ?
Oracle Database Firewall est un système d’exploitation complet à installer sur votre serveur. Pourquoi ? Pour être le plus proche possible du Hardware et donc éviter de perdre des performances !
Quelques questions qui vous trottent dans la tête
Comment ça se passe lors d’une nouvelle version de logiciel ?
Lors d’un déploiement d’une nouvelle version de votre logiciel, modifiant les requêtes SQL, il vous suffit de le mettre en learning mode dans votre environnement de développement et il mettra à jour ces règles. Le jour de la mise en production, votre firewall est prêt avec les nouvelles règles et il n’y aura aucun couacs.
Et s’il bloque une requête qui est bonne ?
Dans le jargon, ça s’appelle un Faux positif. Oracle Database Firewall dispose d’un mode de learning automatique qui nous permet d’enregistrer tous les patterns de requêtes qui sont bons. C’est à votre implémenteur de s’assurer d’avoir testé tous les patterns de requêtes pendant la phase de développement. C’est pour ça que vous ferez appel à moi 
Et si je fais des injections SQL pendant le learning mode ?
Il y a très peu de règles qui sont établis par rapport au nombre de requêtes par jour (Voir une des questions d’après). Ces règles, automatiquement créés par Oracle, doivent être validées par un humain pendant la phase de développement et vous, vous ne laisserez pas passer ça non ?
Mon IPS est capable de faire ça. Pourquoi je l’achèterai ?
Oui c’est vrai, votre IPS est largement capable de faire le travail correctement mais vous allez consacrer énormément de temps à le configurer et il y a un risque important de faux positif (Voir question plus haut) . Tout simplement parce que l’IDS a un but généraliste et ne colle pas parfaitement aux besoins des bases de données.
Qui l’administre ?
Pour l’installer, ça concernera votre équipe réseau et vos DBAs. Pour la configuration des règles, il est conseillé que ce soit plus aux DBAs car il y a des connaissances à avoir dans les requêtes SQL. Ça peut être aussi être configuré par une équipe sécurité.
Est-ce compliqué à configurer ? Beaucoup de règles sont créés ?
Le fait qu’il se mette en learning mode rend le déploiement très simplifié. Il suffit de positionner quelques règles pour les exceptions.
En moyenne, il vous diviser par 10000 par rapport à votre nombre de requêtes journalières pour avoir le nombre de règles qu’il crée. Vous avez 1.5 Millions de transactions par jour, cela va vous créer environ 150 règles. Bien sûr, c’est qu’un gros arrondissement, ça peut être très inférieur et très supérieur pour votre application mais c’est pour vous donner une idée. Donc vous voyez qu’il ne crée pas excessivement de règle, donc est relativement facile à maintenir.
Combien de temps pour le déployer ?
Dix jours travaillés à prévoir pour l’installer, le configurer et le mettre en mode learning. 2-3 mois d’exploitation pour faire les règles et gérer les exceptions liées à votre entreprise (DBA, ressources humaines etc…)
Si vous avez une question qui vous trotte encore dans l’esprit, n’hésitez pas à m’en faire part dans les commentaires, je vous y répondrai le plus rapidement possible.
