Protect Your Database

Database security could easily be a full time job. The problem is, most DBAs already have a full time job keeping their databases running efficiently and meeting the demands of customers, developers and management. We tend to emphasize availablity over the other aspects of security. After all, any organization that is willing to pay for Oracle database software and skilled Oracle database administrators is likely to be very concerned with availability. The purpose of this site is to help you maintain the confidentiality and integrity of your data by preventing unauthorized access. To keep things simple, I've organized and prioritized them into 10 steps. These steps would not be enough to stop an informed and determined attacker, but they would make the job more difficult, and increase the attacker's risk of being caught. If you are concerned about the security of your databases, but don't know where to start, start here.

If your data is important enough to keep in an Oracle™ database, chances are, someone will think it is important enough to try and obtain unauthorized access. Whether it is a competitor engaging in espionage, a disgruntled employee, or a "script kiddie" out for some malicious fun, don't let your databases develop a reputation for being "easy".

Insecure by Default

The job would be much simpler if the security features in Oracle software were enabled by default, but an Oracle™ database as installed "out of the box" has almost no security features in place. This makes our jobs more difficult, but if the job were too easy, salaries would start to drop, and nobody wants that! Here are just a few of the "insecurities" you need to address if you want to defend the "virtue" of your database:

• The default passwords are well known, making it easy for an attacker to gain access to the database.
• By default the listener is not password protected and remote administration is enabled, making it vulnerable to takeover by anyone with network access.
• By default there is no minimum password length, no password expiration, no limit to the number of failed login attempts, and no visibility on failed login attempts.
• The default CONNECT role grants the CREATE DATABASE LINK privilege and other privileges that users may not need.
• Auditing is turned off.

Even if your server is located in a fortress, and all of your hardware and software are patched to the most current level, your database will be vulnerable until you change the default settings.

Oracle 10gR2 started moving in the right direction by tightening up file permissions. Oracle 11g has made huge strides toward securing the database out of the box. I hope to begin an update/expansion of the tutorials in March, 2009.

Ten Simple Steps To Keep Your Databases Out Of Compromising Situations

1. Isolate databases on a server that will only be used as a database server. Restrict login access to the system administrators and database administrators.
   More about server security.
2. When installing Oracle™, don't accept the default installation. Install only the functionality that you need. Attackers can't exploit vulnerabilities if the products aren't installed.
   More about installation.
3. When creating databases, don't use the GUI. Build a script that enables only the features you need. Unused packages can be exploited to gain access to your database.
   More about building databases.
4. Change the default passwords for all accounts. Use impossible passwords, or lock accounts that won't be logged in.
   More about passwords.
5. Password protect the Oracle listener. Listeners that aren't password protected are vulnerable to take over by anyone with network access. Unpatched listeners can be compromised to gain access to the databases.
   More about listener security.
6. Remain as current as possible with patches (especially Critical Patch Updates) and Oracle releases. Most attacks occur after a patch is released. Patch releases provide attackers with a "shopping list" of potential vulnerabilities.
   More about patches.
7. Use profiles to limit failed login attempts, enable password expiration and limit password reuse.
   More about profiles.
8. Don't use Oracle supplied roles like CONNECT and RESOURCE. Create your own roles, and always grant the minimum privileges needed to perform the work.
   More about roles and privileges.
9. Enable auditing of failed login attempts, user creation, grants and other privileged activities.
   More about auditing.
10. Keep informed about security issues pertaining to Oracle™ and to the server it runs on. Subscribe to Oracle Security Alerts. Visit security Web sites for the latest information.
    More information.

Database Diva Presents Random Thoughts on Oracle Database Administration and Security

Random thoughts about Oracle database security