Database Administration with Style!

Database Diva Presents: Security Tutorials for Overworked Oracle™ Database Administrators

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.

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

Database Diva Presents Random Thoughts on Oracle Database Administration and Security

Random thoughts about Oracle database security


10/07/2008 08:09 PM
Client permissions in 11g
I’m happy to report that I only had to make on adjustment to the 11g client in order to make it available to my customers.  The 751 permissions on sqlplus continue to result in map : Permission Denied errors by users who aren’t in the DBA group, but while this was mostly an annoyance in 10g, in [...]
06/16/2008 08:23 PM
Oracle 10g Client Permissions… Again!
Just when I thought I had the client permission issue put to bed, one of my customers announces that he is getting errors when trying to run oerr from the client machine. oerr: Unknown facility ‘ora’ The oerr command depends on $ORACLE_HOME/lib/facility.lis to work correctly. The $ORACLE_HOME/lib/facility.lis file must be readable by other, and the directory [...]

Last update 05/12/2008

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates.