Securing Oracle Databases

1. Securing Oracle Databases CSS-DSG JTrumbo

2. Audit Recommendations • Make sure databases are current with patches. • Ensure all current default accounts & passwords (for example, scott/tiger) are disabled or changed • Institute a password change for existing accounts; minimally those where the password=username (a large effort in itself, but the audit team and countless others /probably/ have most or all of the password hashes) • Make it difficult to query the TNS Listener for available databases. The listener password accomplishes this, but may cause problems with database restarts.

3. Audit Recommendations • Hide the password field in the SYS.USERS$ table from normal users (if possible) • Hide data on the SYS tables that would allow identification of users with high privilege. • Encrypt database links • If you have multiple logons, use different passwords for each. • Audit and lockout accounts with higher than normal invalid password counts. • Use Oracle’s Audit tools. We have found this too expensive in disk and cpu cycles. We have a home grown solution instead.

4. Basic Maintenance • Keep database up to current version • Keep database up to current patch level • Keep OS up to current version • Keep OS to current patch level No excuses on this. The Lab Director has dictated that patches will be applied in a timely manner. Reasonable downtime must be planned & granted to accomplish patching. • Restrict OS access • Restrict database server machines to the database only and db monitoring. NO web servers, NO users except Oracle.

5. Passwords • Change all the default pwds upon installation including: • Sys • System • Dbsnmp (edit snmp_rw.ora) • Scott/tiger • A host of others See The Database Hackers Handbook, Litchfield/Anley/Heasman/Grindlay for complete list. NOTE*** some db installations, (mysql), auto start with the default pwds. These must be changed IMMEDIATELY, as a hack can occur within minutes. • Make a reasonable parameter list in utlpwdmg.sql, and run it against your databases to enforce complex passwords. • Make sure the utlpwdmg includes a max # of login attempts an lock out accounts trying unsuccessfully to log in.

6. Enforce Complex Passwords • Make sure pwds have a recycle schema (no recyclability is an option) • Annual resetting of pwds (hopefully oracle will get kerberos working) • The password complexity verification routine ensures that the password meets the following requirements: • Is at least eight characters long • Differs from the username • Has at least one alpha, one numeric, and one punctuation mark character (underscore counts!) • Is not simple or obvious, such as welcome, account, database, or user • Differs from the previous password by at least 3 characters Accounts that do not update the database can be the exception to complex password/expiration requirements, with the exception of any read only accounts that has access to SYS tables.

7. Database Roles • Practice principle of least privilege. Insure users have only the roles & privs they need to complete their function.

8. Dictionary • Sys and system tables need to be hidden from users. Do not allow users with see sensitive hashed password columns in the dictionary. • change the 07_dict=false in the init.ora • retain 'select any table' for users allowing them can look at each others stuff if necessary • grant select any dictionary table only to the user that needs dictionary read access. (this is probably limited to dba or monitoring users, not application owners or end users). • Create a role with the limited and acceptable SYS tables users need to monitor their apps, (v$session, v$instance), and apply role as needed.

9. Steps Taken • Password protect listeners, although till 10g, this opens up other issues. • Drop obsolete dblinks, drop any dev-prod links. Where possible made links read only. • Change external authenticated accounts to password protected accounts. • Implement the complex pwd function (utlpwdmg). • Set up additional login profile(s) to handle read only and group accounts (accounts with globally known passwords that are read only). • Protected the read-only accounts from the modification of the password. • Force password changes for blatantly soft accounts, locking the accounts if necessary.

10. Steps Taken • Restricting access to the oracle dictionary (SYS objects). We wished to use fine grain access to mask the sensitive columns, however we discovered fine grain was not available to be used on dictionary tables. This forced a review of all the applications’ use of dictionary tables and creation of new role(s) to handle the needed but very limited access to some dictionary tables containing no sensitive columns. • Kerberize logins – on the docket with Oracle, should automatically force & synchronize regular scheduled password changes. Currently, standard MIT kerberos is not supported by Oracle thus kerberos cannot be implemented.

11. References • Oracle Database Security Checklist http://www.oracle.com/technology/deploy/security/pdf/twp_security_checklist_db_database.pdf • The Database Hackers Handbook, Litchfield/Anley/Heasman/Grindlay • A copy of the Oracle baseline security document available http://www-css.fnal.gov/dsg/internal/briefings_and_projects/index.html CIS_ORACLE_BASELINE.