In the previous parts I talked about introduction to the security world and database security. In this post I will dive into the infrastructure aspect of the database.
Links to the previous posts:
Part 1 – general introduction to security
Part 2 – introduction to database security
As I wrote in the first post, we have three general guidelines regarding security:
- Prevent the attack
- If an attack does happen, reduce the damage it can do
- If an attack does happen, be able to know about it and trace it
There are many actions we need to take to do that, and many variables we need to consider. That’s why writing a database security policy for a client takes a few days of work. I will list here several important actions and examples, but remember that this is not everything and there is a lot more to be done.
General
As a general rule, we need to install patches on production environment (after testing of course). OS vendors and Oracle provide periodic patches which include security fixes. Oracle releases a PSU every quarter (includes security patches and specific bug fixes and considered to be safe). The reason that this is important is that hackers don’t always have ways to break into a system. When a security patch is released, the hackers reverse engineer it, and realize how to exploit the original vulnerabilities. The next step is simply look for un-patched systems to attack.
Another important topic is user management. Nobody should have root and oracle passwords for the OS and no one should have sys and system passwords for the database. The right way is to have private username and password for every sysadmin and DBA (for the OS and/or database) with adequate permissions. When sharing a user’s password it is hard to change the password, so employees that left their role or the organization still know the passwords. another reason is auditing. When everyone has their own username and something happens, it’s easier to trace what happened.
OS and Network
As I said before, the database server should not be connected to the internet. There are lists on the internet of Oracle database servers that can simply be accessed from the internet on port 1521. This is bad as hackers can attack the database directly, flood it and brute force passwords until they manage to connect.
On the network side, access control using a regular firewall or even better, a database firewall might give a strong defense.
Oracle
When installing Oracle, a security best practice is to avoid as many defaults as possible. Don’t use “oracle” as the software owner, don’t use 1521 as the listener port and so on. That makes it more difficult for an attacker.
It is important to install only the features you actually use. If you don’t develop in APEX, don’t install it. If you don’t use Java in your database, don’t add it. Some of these features allow external access to the database and therefore increasing the attack surface. Our goal is to minimize the attack surface. The more access options we have to the database, the more it’s likely for an attacker to find a way in. An example for such an increase in the attack surface is the fact that Oracle starts a dispatcher for the database by default, and this dispatcher can be accessed directly. You can read all about it in my post bypassing the listener.
Another very important issue is scripting. I LOVE scripting and I use it all the time (I plan to write a series of posts about that as well in the future). The problem with scripting is that sometimes we need to connect to the database, so we simply write the database password in the script. When there are several database servers that need to run the script, we place the script in a shared directory on the network, and game over. We have no control on this share and the script, and everyone can see the database password. This must not happen! Passwords should be never written in any scripts.
One last thing about the database (and Kadhir mentioned it in a comment to the previous post) is that everything we copy from the database out (such as backups, dump files, etc.) should be treated as production data. This data must be secured, by limiting the access to it, place it behind firewalls and encrypt it with a strong password.
Audit
The third point I mentioned at the top is “If an attack does happen, be able to know about it and trace it”. This means that if something happens, it’s important to know what happened for two reasons. The first, we need to know what the attacker did, if they managed to change data, we need to know what, if they managed to steal data, we need to know which. The second reason is to close the vulnerability so it won’t happen again. Being blind after an attack is bad as the attack itself.
Summary
This concludes the third part in the series. Again, this is only the tip of the iceberg. Remember, an attacker needs only one access path to the server. Our job is not to give him one, and if he manages to find one after all, he shouldn’t be able to do much with it.
In the next part I’ll cover development issues. See you soon.
We have faced attacks, but it was in a different market and that market had a DBA,
But, they asked me to troubleshoot, because they didnt trust their own DBA.
The scenario that we faced was someone was updating a critical billing table from backend and because of this, organisation was facing huge loss, it was happening for few days, only thing that we could do was to harden the database further, so that nobody access that table. We couldn’t find the person doing it.
The question to Liron here is
1) The management didnt want to enable audit to avoid performances issues.
2) They don’t want to use VPD or TDE encryption wallet either.
So what should an organisation do to protect critical data from hackers and what would you do in this scenario to find out the person who updated the table.
We didn’t find the update statement from active session history view or any other v$ or dba_ views.
Hi Kadhir,
This is a very serious thing.
The management needs to understand that they have to audit in some way and/or control the access to these tables.
If this was done using the backend application, doesn’t it have some kind of logging? I can think of several things to check in order to start the analysis:
1. Check the time the rows were updated (according to their SCN)
2. Check the application logs
3. Check the system log for a logon around this time
4. Check the listener log for a logon around this time
In such critical environments I usually see an access control software or database firewall. These software products usually provide good performance and allow both access control and auditing.
Without that or audit or anything similar I can’t see how you can analyze and prevent such cases.
Just as a side note, TDE is irrelevant here as this was done as an update on the database. TDE only encrypts the physical files on the disk.
Liron
He can use “LogMiner” if database auditing is not enabled, although its not good idea at all of not having the auditing enabled on the database.
LogMiner is not easy and hectic to trace especially if he doesn’t know the timing of the incident.
There can be some solutions here:
1- Database Vault – It helps you in restricting DBAs and superusers.Even sys is not allowed to perform certain operations.
2- Data Redaction – It helps you in hiding critical data dynamically.
3- Label Security – Control over critical data
4- DB Firewall – Proactively controls the access.
Hi Vinay,
I didn’t include solutions in the post on purpose. I agree that this is a list of tools that can be relevant to the problems, but some are not part of the database, and all of them cost extra.
There are many other solutions as well (by other vendors) which are very good as well.