Protect your databases
Every company has one or more firewalls that control access to their servers and PC’s.
Almost every company has a Windows domain where policies and access to resources are configured.
But only a few companies control the SQL traffic to their databases.
Of course, database administrators can define access rights in the database.
But this will not solve that
- leaked database credentials can be misused
- unforeseen clients access and modify the database
- you are missing a central point with policies for database access
- your database access is incompliant to specific regulations, e.g. SOX (Sarbanes-Oxley act), DPA (Data Protection Act),…
- attacks from a specific network, application or users are not detected on time
- there is no central point where all database access is monitored
To solve these issues you need a SQL firewall, which controls and audits SQL traffic.
We should only allow
- specific actions (select, DML, DDL)
- from specific database users, OS users, applications, network
- to specific tables in specific database
All other access should be blocked or alerted.
I had the opportunity to test the SQL firewall of Oracle for a customer. The product name is “Oracle Audit Vault and Database Firewall”
Oracle Audit Vault and Database Firewall
The product of Oracle consists of the following 2 components:
- Report on audited data and control audit settings, e.g. on Oracle FGA (Fined Grained Auditing)
- SQL firewall, to control and report on SQL traffic
In this article, I will focus on the firewall functionality.
Oracle Database Firewall ships with a set of plug-ins for following databases : Oracle Database, Microsoft SQL Server, IBM DB2, MySQL and Sybase. But, you can also develop your own plug-ins.
In the minimal configuration there is
- One Vault Server
- One Database Firewall Server
All management, configuration and reporting is done on the Vault Server so you have one interface to control and monitor all SQL traffic.
The Database Firewall Server controls the SQL traffic. The firewall policy can be set up in blocking mode or in monitor only mode. My customer wanted blocking mode.
A firewall policy contains the rules for the SQL traffic. It defines what SQL traffic is passed, logged, alerted, blocked or substituted.
This policy is pushed from the Vault Server to the Firewall Server.
The firewall server will report all events and logged SQL’s to the Vault server.
Clients will have to connect to a port on the database firewall. The firewall will forward the connection to the database.
In a firewall policy you define actions in rules based on
- SQL statements (Analyzed SQL)
- OS user
- DB user
- IP addresses
- Profile (based on OS user and/or DB user and/or application and/or IP addresses)
- Used table or tables (Novelty Policies)
An action can be
You can define exception rules. These are evaluated before other rules. E.g. you can define a exception rule for the profile of the DBA to allow more actions. I defined an exception rule for the traffic from my PC and my OS user.
A firewall policy also contains a default rule. This rule is evaluated after all other rules.
Configuration of a firewall policy is done in a user friendly GUI.
The Database Firewall Server and Vault Server are installed as appliance: there is one installation that will install Linux and all application software.
Some points of attention
Defining firewall policies
Defining firewall policies is an iterative process. So, you should start by logging all SQL traffic. This can be done by implementing the pre-defined firewall policy LogAll.
Then you can define a firewall policy that
- allows all normal SQL traffic
- alerts or blocks abnormal SQL traffic
Based on the alerts of the abnormal SQL traffic a new version of the firewall policy can be implemented.
For high availability you can set up pair (cluster) of Vault servers or pair (cluster) of Firewall servers. However, this is not supported for blocking mode.
To have high availability in blocking mode, you could put a load balancer before the database firewalls. Because then the database firewalls are not clustered, some configuration will have to be repeated for each database firewall. This can be done with GUI or CLI.
However, a load balancer will mostly modify the source IP address (of the client). So, you are no more able to create rules based on the IP address of the client.
A firewall can not analyze encrypted data. So, if SQL traffic is encrypted, it needs to be decrypted first.
Decryption in Oracle Database Firewall is only possible with Oracle Native encryption.
But often TLS (Transport Layer Security) is used. When TLS is used, SSL termination has to be implemented before the firewall, e.g. in the load balancer.
Substitute blocked statements
When an SQL is blocked, without substitution a client will receive no response. It can hang very long or a timeout can occur.
Therefor, I advice to use a substitute SQL.
E.g. you could substitute a query on salaries done by non-authorized profile by “select ‘you do not have access to this table’ from dual“.
Oracle Audit Vault and Database Firewall is a good product to prevent misuse of your Oracle and SQL server databases.
It gives you a one interface for controlling all SQL traffic.
It’s easy to install and configure.
However you will need some time for
- deciding what functionality your will use (monitoring, blocking, auditing, all or some databases, …)
- when high availability in blocking mode is needed, implementing a load balancer
- the design, implementation and test of the network set up for databases, clients and firewall’s
- creating, testing and improving the firewall policies
- when traffic is encrypted, implementing SSL termination before the firewall (when Oracle Native Encryption is used, the traffic can be decrypted in the database firewall)