Database Hardening Guide

Overview

The following covers the core areas and required actions to harden an Oracle database in compliance with Oracle's recommendations. This material is derived from Oracle's Database Security Guide (E16543-14) and Security Checklist (1545816.1 [131752.1]). These sources have many related links. The goal of this material is to provide this in just one concise document. All indicated actions need to be applied and thoroughly tested on your test systems before being implemented on your production systems.

Blindly applying CIS or PCI recommended security changes will break your Oracle database!

It should be noted that while CIS, PCI and other non-Oracle sourced security directives are well intentioned they will break your database because:

1. There are a significant number of recommended actions that are deprecated.
2. Those creating\maintaining the recommendations do not seem to be full time system level DBAs for enterprise environments, i.e. they do not fully understand all the repercussions for the changes they recommend.

Primary Actions (Essential)

1. Change passwords for administrative users: SYS, SYSTEM, SYSMAN and DBSNMP.
   1. Leave MGMT_VIEW as-is. It is an account used by OEM (AKA Database Control). The password is randomly generated at OEM installation or database creation time. If you change it you may need to rebuild OEM. Users do not need to know this password.
2. Lock, expire, and change passwords for default and unused accounts.
   • To determine any users using the default password use:
     SELECT * FROM DBA_USERS_WITH_DEFPWD;
3. Restrict access to the Oracle home and installation files.
   • UNIX\LINUX the oracle account should own all Oracle system files and installation files. If RAC the grid account as required by cluster install.
   • Windows Oracle (11g and earlier) should be installed and maintained using the local administrator account (SR 3-6637494911).
     This means:
     • Not an administrator equivalent account.
     • Not a Domain administrator account.
4. Review database user privileges.
5. Limit privileges to PUBLIC.
   • Be careful not to cause SYS\SYSTEM objects to become INVALID though.
6. Protect the data dictionary from unauthorized users.
   • Prevent users from using the "ANY" system privileges on the data dictionary.
   • Ensure that O7_DICTIONARY_ACCESSIBILITY is set to FALSE (11g default).
     ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=false SCOPE=spfile;
7. Set REMOTE_OS_AUTHENT to FALSE (8i, 9i, 10g)
   Setting this parameter to FALSE does not mean that users cannot connect remotely. It simply means that the database will not trust that the client has already been authenticated, and will perform authentication checks accordingly. This parameter has been deprecated as of Oracle 11.
8. Protect listener and network connections.
   • Monitor listener activity.
   • Prevent online administration by requiring the administrator to have the write privilege on the listener password and on the listener.ora file on the server.
   • Do not set the listener password. Ensure that the password has not been set in the listener.ora file. The local operating system authentication will secure the listener administration. The remote listener administration is disabled when the password has not been set. This prevents brute force attacks of the listener password. Remember that the listener password has been deprecated in this release, and will not be supported in the next release of Oracle Database.
9. Protect the Database Host
   • Run Oracle databases behind at least one corporate firewall; do not open holes in the firewall (such as by opening port 1521 for listener connections from the Internet).
   • Both UNIX and Windows platforms provide a variety of operating system services, most of which are not necessary for most deployments. Such services include FTP, TFTP, TELNET, and so forth. Be sure to close both the UDP and TCP ports for each service that is being disabled.
   • Always apply all relevant and current security patches for the operating system.
10. Check the Oracle support site for new security alerts and critical patches.

Secondary Actions (Recommended)

1. Install only what is required.
   For production systems the custom installation mode should be used to install the minimum set of features and options required. If in the future, you wish to install additional features or options, simply re-run the Oracle installer.
2. Uninstall Oracle sample schemas
3. Use strong passwords.
   • At least 10 values in length
   • A mixture of letters and numbers
   • Contain mixed case (Supported in Oracle Database 11g)
   • Include symbols (Supported in Oracle Database 11g)
   • Little or no relation to an actual word.
4. Enforce password management.
   • Enforce failed login, password expiration, password complexity.
   • Basic password management rules be applied to all user passwords and that all users be required to change their passwords periodically.
   • These can be done using an associated profile.
   • Recommended profiles:
     • user_accounts = Standard user accounts that access database.
     • default = Accounts used by jobs and application software.
5. Secure batch jobs.
   • Avoid keeping usernames and passowrds in clear text.
   • Consider using the Oracle Wallet.
6. Manage access to SYSDBA AND SYSOPER roles.
   • Refrain from connecting with the SYSDBA role except when absolutely required such as called for by an existing Oracle feature or patching.
   • Oracle recommends monitoring the Oracle audit log for unsuccessful SYSDBA and SYSOPER connections.
7. Follow the Principle of Least Privilege
   • Avoid granting powerful privileges to new database users, even privileged users.
   • The Oracle DBA role should be granted with caution and only to those privileged user who need full DBA privileges.
   • Access to the SYSDBA role should be granted with extreme care and only to those in the most trusted position.
8. Use database auditing.
   • Auditing should be used to monitor all activities of users connecting with the SYSDBA role or other administrative roles such as the DBA role, CREATE ANY TABLE privilege and so forth.
   • For optimal auditing performance set your audit destination to point to the operating system.
9. Use Directory Objects to manage the UTL_FILE package.
   • Directories accessible to the UTL _FILE package should be created using the CREATE DIRECTORY command.
   • Grant access to required directories via the created directory object(s).
10. Restrict permissions on run-time facilities.
    • When granting permissions on run-time facilities such as the Oracle Java Virtual Machine (OJVM), grant permissions to the explicit or actual document root file path. This code can be changed to use the explicit file path.
    • dbms_java.grant_permission ('SCOTT','SYS:java.io.FilePermission','<<ALL FILES>>','read');
    • dbms_java.grant_permission ('SCOTT','SYS:java.io.FilePermission','<<actual directory path>>','read');
11. Secure external procedures.
    • The default configuration for external procedures no longer requires a network listener to work with Oracle Database and EXTPROC agent. The EXTPROC agent is spawned directly by Oracle Database and eliminates the risks that extproc might be spawned by Oracle Listener, unexpectedly.
    • This default configuration is recommended for maximum security.
12. Prevent Runtime Changes to LISTENER
    • When the ADMIN_RESTRICTIONS_LISTENER is set to ON (Default) runtime changes to the listener parameters is disabled.
    • To make changes, the LISTENER.ORA file must be modified and manually reloaded.
13. Enforce network listener management.
    Use the Oracle Net valid note checking security feature to allow or deny access to Oracle server processes from network clients with specified IP address. To use this feature, set the following protocol.ora (Oracle Net configuration file) parameters:
    • tcp.validnote_checking = YES
    • tcp.excluded_nodes = {list of IP addresses}
    • tcp.invited_nodes = {list of IP addresses}
14. Encrypt Network Network Traffic
    Consider encrypting network traffic between clients, databases and application servers. Oracle supports both SSL using X.509v3 certificates as well as native network encryption without certificates.
15. Report security issues to Oracle.
    If you believe that you have found a security vulnerability in the Oracle Database, submit an service request to Oracle Support or via email . Include a complete description of the problem including product version and platform, together with any scripts and examples to the following address: secalert_us@oracle.com

<- Security