This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
OWASP Backend Security Project Oracle Hardening
Overview
Description
Installation security
This section is useful to understand how the installation will introduce vulnerabilities if it is not made “security oriented”.
Options and products
The Oracle Database installation pack contains a lot of options and products beside to the database server, so a custom installation should be done to avoid installing options and products not needed. The Oracle components other than the list below should be removed if not specifically required by any database applications.
Oracle database components |
---|
Assistant Common Files |
Generic Connectivity Common Files |
Generic Connectivity Using Open Database Connectivity (ODBC) |
Oracle Net |
Oracle Net Listener |
Oracle Net Manager |
Oracle Net Required Support Files |
Oracle Net Services |
Oracle Core Required Support Files |
Oracle Call Interface |
Oracle9i/8i/10g |
Oracle9i/8i/10g Database |
Oracle9i/8i/10g Development Kit |
Oracle9i/8i/10g Windows Documentation (Windows only) |
Parser Generator Required Support Files |
Programming Language / Structured Query Language (PL/SQL) |
PL/SQL Embedded Gateway |
PL/SQL Required Support Files |
Platform Required Support Files |
Relational Database Management System (RDBMS) Required Support Files |
Required Support Files |
Sample schemas
Oracle Corporation provides sample schemas in order to provide a common platform for examples. Review, after the installation, installed schema and remove any schema you do not need, using the follow SQL statement:
SQL> DROP USER <user_name> CASCADE;
Patching
Apply, always, all security patches for Oracle Database itself, and for all the options and components that are installed. Periodically check the security site on Oracle Technology Network for details on security alerts released by Oracle Corporation:
http://otn.oracle.com/deploy/security/alerts.htm
Further, if you subscribe the security mailing lists you will be able to catch any new security issues that are not reported to Oracle but are announced to the public (maybe without a patch). In such cases, it will be relevant to find a way to mitigate the risk of the new vulnerability in the absence of an Oracle-supplied patch.
Initialization parameters
This section cover the Oracle Initialization parameters that are relevant for the security aspects. All the following initialization parameters have to be specified for all Oracle instances.
Parameter name | Description | Security value |
---|---|---|
REMOTE_OS_AUTHENTICATION | This parameter, when set to TRUE, allows the authentication of remote clients by the host operating system. The default value for this parameter is FALSE. This parameter will remain set to FALSE because of the risk of an impersonation attack, otherwise known as spoofing. | FALSE |
REMOTE_LOGIN_PASSWORDFILE | Specifies whether Oracle uses a password file and, if in use, how many databases can use the password file. Setting the parameter to EXCLUSIVE signifies that the password file can be used by only one database. The password file requires remote DBAs to use their own individual DBA accounts to authenticate to the database for administrative database operations. | EXCLUSIVE |
RESOURCE_LIMIT | Specifies whether or not enforcement of resource limits is enabled. If not enabled, the required idle time limits would not be enforced. The default is FALSE. | TRUE |
REMOTE_OS_ROLES | Allow operating system roles to be used from remote clients. | FALSE |
OS_ROLES | Determines whether Oracle or the operating system identifies and manages the roles of each username.
Set to FALSE to configure Oracle to identifies and manages the roles. Default value false. |
FALSE |
UTL_FILE_DIR | Specifies one or more directories that Oracle should use for PL/SQL
file I/O. |
NULL |
AUDIT_SYS_OPERATIONS | Enables or disables the auditing of operations issued by user SYS, and users connecting with SYSDBA or SYSOPER privileges. The audit records are written to the operating system's audit trail if the AUDIT_TRAIL initialization parameter is set to OS. The default is FALSE. | TRUE |
AUDIT_TRAIL | Enables or disables database auditing. Default value none. | OS |
AUDIT_FILE_DEST (UNIX only) | Specifies the operating system directory into which the audit trail is written when the AUDIT_TRAIL initialization parameter is set to os, xml, or xml,extended.
The audit records will be written in XML format if the AUDIT_TRAIL initialization parameter is set to XML. It is also the location to which mandatory auditing information is written and, if so specified by the AUDIT_SYS_OPERATIONS initialization parameter, audit records for user SYS. |
<Protected Directory> |
USER_DUMP_DEST | Specifies the pathname for a directory where the server will write debugging trace files on behalf of a user process. | <Protected Directory> |
BACKGROUND_DUMP_DEST | Specifies the pathname (directory or disk) where debugging trace files for the background processes (LGWR, DBWn, and so on) are written during Oracle operations. | <Protected Directory> |
CORE_DUMP_DEST | Specifies the directory where Oracle dumps core files. | <Protected Directory> |
07_DICTIONARY_ACCESSIBILITY | Controls restrictions on SYSTEM privileges. If this parameter is set to FALSE, SYSTEM privileges that allow access to objects in other schemas do not allow access to objects in the dictionary or SYS schema. | FALSE |
Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:
SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH
Scope:
- MEMORY: This affects the database now; but will not remain after a restart.
- SPFILE: This does not change the instance immediately, but it will will take effect after a restart.
- BOTH: changes the current instance as well as the spfile.
Operating system security
Owner account
The Oracle OS installation account, owner of all Oracle application and datafiles, should be used only for the update and maintenance of the Oracle software and will not be used during the standard DBA activities. The individual DBAs will have to use their assigned OS personal accounts, so the auditing process will be able to actions performed with the correct OS account. The Oracle software installation account will not be a member of the administrative group.
Files and directories
All files and directories generated during the installation process of Oracle will be restricted to the Oracle software owner or the DBA OS user group, especially the file list below:
File name | Description |
---|---|
init.ora and/or init<SID>.ora
Spfile.ora |
The file houses Oracle initialization parameter files. Replace SID with the name of your SID. |
orapw<SID> | The file contain SYS password and the password of accounts granted the SYSDBA or SYSOPER role. Replace SID with the name of your SID. |
listener.ora | The file houses listener configuration parameters and password. |
snmp_rw.ora | The file contains the password for the DBSNMP database account in cleartext. |
snmp_ro.ora | The file houses configuration information for the Oracle Intelligent Agent. |
sqlnet.ora | The file contains network configuration information for the host database and listener. |
Other accounts should be denied access except to executables under the “bin” directory as specifically required. All files stored in the “bin” directory will be owned by the Oracle software installation account. These files and directories will be secured by using access control methods native to the operating system.
Account management
Lock and expire unused accounts
A number of default database server user accounts are create during the installation process so, if you do not use the Database Configuration Assistant, you should lock and expire all default database user accounts. Unlock only those accounts that need to be accessed on a regular basis and assign a strong password to each of these unlocked accounts.
Example SQL for reviewing the Oracle Default Accounts with status “OPEN”:
SQL> SELECT <user_name> FROM dba_users WHERE account_status <> ’OPEN’ ORDER BY <user_name>;
Example SQL for Locking Accounts:
SQL> ALTER USER <user_name> ACCOUNT LOCK;
Change default password
The most trivial method by which Oracle Database can be compromised is a default database server user account which still has a default password associated with it even after installation, so the passwords of all default accounts (SYS, SYSTEM, CTXSYS, MDSYS, DBSNMP, and OUTLN) should be changed.
Enforce password policy
The password policy should be enforced by password verification function setting password parameter (list below) and providing password complexity feature like minimum length, password not same as the username, the password contains repeating characters, the password differs from the previous password by at least a maximal number of letters.
Example SQL for setting a password verification function to a profile:
SQL> CREATE PROFILE <profile_name> LIMIT PASSWORD_VERIFICATION_FUCTION <newvalue>
Example SQL for assigning profile profile to a user:
SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;
Roles
Automated processing database accounts
Network security
Encrypt network logins
The password information in a connection request should be encrypted to protect against network eavesdropping. The value of the follow parameter should e review:
ORA_ENCRYPT_LOGIN (on the client machine) DBLINK_ENCRYPT_LOGIN (on the server machine)
Once these parameters have been set to TRUE, passwords will be encrypted in connection requests. On Oracle version 9.02 and later these parameter are not available, this is automatically handled when transmitting over a network. Note that the setting or changing of passwords across the network is NOT encrypted without other encryption configuration such as Oracle Advanced Security (OAS).
Protect network communications
As mentioned in the previous paragraph, administrative connections that may contain confidential information such as “account password changes” should be protected by encryption. If local encryption is not implemented (VPN), the Oracle Advanced Security (OAS) should be used and configured to use Secure Socket Layer (SSL) to encrypt network traffic between clients, databases, and application servers.
XML database (XDB) protocol server
The XML Database (XDB) offers access to the Oracle XML DB resources using the standard Internet protocols FTP, listening on TCP port 2100, and HTTP, listening on TCP port 8080. The Oracle XML DB Protocol Server is a specific type of Oracle shared server dispatcher and is specified in the Oracle database initialization parameter file for startup, so if XDB is not used it should be turned off editing the init<SID>.ora or spfile<SID>.ora (replace SID with the name of your SID) file and remove or comment the follow line:
dispatchers="(PROTOCOL=TCP) (SERVICE=<SID>XDB)"
If access via the Internet protocols is required, logging should be enabled by setting the “ftp-log-level” and “http-log-level” parameters to a value of 1 in xdbconfig.xml file.
Oracle TNS Listner security
Password
A listener password should be set after listener configuration to avoid unauthorized users starting, stopping, and configuring the listener service. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility.
From the OS command prompt, type LSNRCTL and press Enter:
LSNRCTL> set password Password: (blank since there is initially no password assigned) The command completed successfully LSNRCTL> change_password Old password: (blank) New password: xxxxxx Reenter new password: xxxxxx […] The command completed successfully LSNRCTL> save_config (required to save the password ! !) […] Saved LISTENER configuration parameters. Listener Parameter File […] Old Parameter File […] The command completed successfully LSNRCTL> exit
The Listener password must be set on all listeners running on the system.
Admin restrictions
The remote administration of the Oracle listener should be prevent by setting to TRUE the ADMIN_RESTRICTIONS parameter in the listener.ora file:
ADMIN_RESTRICTIONS_<listener_name> = TRUE
Replace listener_name with the name of your listener.
This will require that any configuration changes be made to the listener through direct edits to the listener.ora file.
Network address restriction
The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access. Network address restriction is required when the PLSQL EXTPROC is in use to protect against unauthenticated access to the database. To enable network address restriction, edit the SQLNET.ORA to add the follow line:
TCP.VALIDNODE_CHECKING = YES
Then, to defines TCP/IP addresses that are allowed to connect to database add the follow line:
TCP.INVITED_NODES = <list of IP addresses>
At the end, to defines TCP/IP addresses that are refused connections to the database set the follow parameter
TCP.EXCLUDED_NODES = <list of IP addresses>
External procedures
Inbound connection timeout
The controls of the amount of time, in second, the listener waits for a network client to complete the connection request should be configure to prevent a denial of service attack. The name of parameter, to set to configure inbound connection timeout and the name of the file to add it, depends on Oracle version. This parameter protects the listener from consuming and holding resources for client connection requests that do not complete. A malicious user could use this to flood the listener with requests that result in a denial of service to authorized users. To prevent this, secify, also, the expire_time parameter probes for dead connections and terminates them when found. This setting does cause a slight increase in network traffic.
Packages, procedures and functions
Audit
References
[1] The Oracle Hacker's Handbook: Hacking and Defending Oracle by David Litchfield
[2] The Database Hacker's Handbook: Defending Database Servers by David Litchfield
[3] Database Security Technical Implementation Guide by DISA for the DOD
[4] Oracle Database Security Guide by Oracle Corporation
[5] Oracle Database Security Checklist by Oracle Corporation