Oracle database security blueprint against network attacks

Databases play a vital role in many current enterprise systems. They are commonly used to store vital, critical and confidential data about customers, finance, logistics and other operations within the company. Due to the central role a lot of database play in an overall architectural landscape of a company it can be expected that companies do take all measures to ensure the security of a database. Security can be seen from many different angles. For example availability is a security point which is often not considered to be part of security. When people talk about security in general they think about how to protect unwanted and unauthorised people from accessing a system or data.

When thinking about how to protect a system, a database in this case from being accessed by people who are not intended to a lot of people do think in the following order about security. User accounts, networking, applications, operating systems and then the rest. All are evenly important however thinking about security is something that needs to be taken very carefully. For example the network security is not simply placing a firewall between the database and the application server or directly to the rest of the world.

Below is a start of a blueprint which might help you to start your own database security blueprint. In this case we have taken a situation in which the database is used in combination with an application server which is connected to the public internet. A couple of things to remind, we only take network security as a topic in this blogpost and we do only think about security in a way to prevent users from attacking the database via the network to gain access. Meaning this rules out DDOS kind of attacks and this rules out any attacks on the application server (directly).

In the image below you can see the implementation of the blueprint for a database in a more then average secured landscape. This however is not yet considered a full secure architecture however is providing you security against a large number of the general attacks towards the database that might be undertaken on a web-facing application.

It is common practice for most companies to place web-facing application servers in a DMZ for security reasons. What is not common practice is that both firewalls should be of a different make and model. Reason for this is that if an attacker would be able to compromise the first firewall it would be very simple to hack the second DMZ-inside firewall when this was of the same make and model.

Next to this you can notice that the application server is attached to two different (V)lan's. Reason for this is that on the user (V)LAN you most likely only want to have one singel port open which is exactly the same port you will allow to be accessed from the outside world. Due to this setup it is important that you have at least two different NIC's. One NIC attached to the User VLAN and one attached to the application VLAN. On the application VLAN you can have more ports open then you will have on the  user VLAN. As you can see all servers in the above shown blueprint design are hardend by themselves by making also use from a local firewall. This means that even though you have firewalls available on network level you also have on every server a local firewall as an extra layer of security. On Linux servers you would use ipTables for this.

In your application design and your database schema and user design you have to already have to made sure most common security features are available. For example by making use of deep application boundary validation in your code which I already discussed in a previous blogpost.

On a more database security topic, in the blueprint design shown above you can see that the application server is not connected to the database server directly. Instead it is connected to the a database firewall server which sits in its own Oracle database firewall DMZ. The reason the Oracle database firewall is placed here is that all the other firewalls, also the Linux internal firewalls, are only there to protect against unauthorised network routing. Those firewalls simply state if a connection between 2 systems on a specified port is allowed. The Oracle database firewall is adding to this that it is checking the actual SQL statements that are executed. The Oracle database firewall is protection you against a potential attack via, for example, SQL injection. I have been discussing the Oracle database firewall in more detail in a previous blogpost.

The Oracle database firewall will be the point to which your application server will connect to like it is a normal database. The Oracle database firewall will check the statements it receive for a specific database against a whitelist of statements and if approved act as a "proxy" towards the database. This is shown in the below image from Oracle.

Now we have in place firewalls on the hosts protecting the hosts with IPtables. we also have firewalls in between the network segments and have separated the different network segments. We have also deployed a Oracle database firewall to ensure that not only the network traffic is controlled we have also ensured that the statements that are send to the database are valid and do not contain any statements that could be used to exploit the database.

As a last line of defence we use a technique that is less known even by most Oracle DBA's. We limit the hosts that can connect to the database on the database itself. In case someone is able to circumvent all firewalls and bypass the Oracle database firewall we have an option to state in the database instance itself which hosts can connect. A sort of whitelist of hosts, a sidenode to this is that you will have to add for example your application servers on this list and the Oracle database firewall. If someone gains access to a shell on those servers and starts a SQL session from this server it is considered valid. However it will hold back all the SQL sessions from IP's that are not in the whitelist.

To enable this valid node checking function you have to add some information to your $TNS_ADMIN/sqlnet.ora configuration. You have to change (add) the following to the file:

tcp.validnode_checking = YES
tcp.invited_nodes = ( X.X.X.X, hostname, ... )

Do note that if you do not add the IP's or hostnames of the machines your DBA is using they will also be unable to connect to the system. Adding the tcp.validnode_checking option to YES is in the security best practices of Oracle and should (in my opinion) be done always unless you have a very valid point to not do this.

A good thing to note is that if you use tcp.validnode_checking in an Oracle eBS setup this is supported by the autoconfig functionality. AutoConfig supports automated configuration of this setting. If the profile option “SQLNet Access” (FND_SQLNET_ACCESS) is set to “ALLOW_RESTRICTED” at the Site level when AutoConfig is run on the database server, AutoConfig will add IP restrictions to sqlnet.ora. The list of host will be all those from the FND_NODES table that are registered as an EBS node.

For more information, refer to MOS Note 387859.1: Using AutoConfig to Manage System Configurations with Oracle Applications Release 12 - or the Oracle Applications Concepts manual.