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.
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.
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.
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.
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.
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.