OWASP - User contributions [en]

OWASP Backend Security Project Oracle Hardening

2008-08-15T21:23:59Z

Pderinaldis: /* Client side */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)
SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===

Consider configuring the Oracle Advanced Security component to use Secure Socket Layer (SSL) encrypting network traffic between clients and databases to avoid network eavesdropping.
Below, you can see an example of a basic configuration:

==== Server side ====

To enable SSL database connection you should create an Oracle wallet (with the autologin feature) and generate a certificate request by using Wallet Manager component. Then you should send it to the Certificate Authority; when you receive CA trusted and the user certificate, you should import these certificate into your wallet.
Then you should configure the Oracle Advanced Security component by using the Net Manager utility (recommended) or modify the sqlnet.ora and listener.ora file.
At the end, the sqlnet.ora and listener.ora files should contain the following entries:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

==== Client side ====

After the wallet is configured, you should configure the client to use SSL connection to connect to databases by configuring sqlnet.ora file.
Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_SERVER_DN_MATCH = OFF
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

Now, you should define a network connection to the SSL listener by configuring the tnsname.ora file:

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = <host_name>)(PORT = <port>))
)
(CONNECT_DATA =
(SID = <SID_name>)
)
)

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== Audit ==

To properly protect database access you should implement auditing of user database activities in order to identify any suspicious activity or to check if an user has more privileges than expected.

=== Start Audit Service ===

To start the audit service you should execute “cataudit.sql” as SYS account. Then, you should choose if you want store the audit record to DataBase or Operating System file by setting the parameter “AUDIT_TRAIL” to DB or OS.
The database audit trail is a single table named SYS.AUD$, but there are predefined views that help you use the information in this table, while as regard operating system audit trail the audit records are written into the directory that you choose by setting the “AUDIT_FILE_DEST” parameter.

=== Enable Audit ===

Once you start the audit service, you can choose to audit the sys operation by setting the AUDIT_SYS_OPERATION to TRUE. So that, Oracle Database audit connections to the database with administrator privileges, database startup and shutdown.
Then, you can enable other options, by using AUDIT SQL statement:

* Statement Auditing.
* Privilege Auditing.
* Schema Object Auditing.

An example to audit some activities on table “test” owned by OWASP (Schema Object Auditing):

SQL> AUDIT INSERT, UPDATE, DELETE ON owasp.test BY ACCESS;

Oracle Database allow to write a single audit record for all SQL statements in the same session, using the “by session” option in the audit SQL command or to write one record for each access, using the “by access” option.
Then, Oracle Database allows, also, to write the successful executions of statements, using the “whenever successful” option in the audit SQL command or unsuccessful attempts to execute statements, using the “whenever not successful”.

=== Disable Audit ===

To turning off an audit options you should use the statement “NOAUDIT”, such as:

SQL> NOAUDIT ALL PRIVILEGES;

=== Check Audit ===

If you are using the database audit trail you should use the “SELECT” statement from the follow view to show the enabled audit:

{| class="wikitable"
! Type of Audit !! View Name
|-
| Default Auditing || ALL_DEF_AUDIT_OPTS
|-
|-
| Statment Auditing || DBA_STMT_AUDIT_OPTS
|-
|-
| Object Auditing || DBA_OBJ_AUDIT_OPTS
|-
|-
| Privilege Auditing || DBA_PRIV_AUDIT_OPT
|-
|}

An example:

SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;

USER_NAME AUDIT_OPTION SUCCESS FAILURE
-------------------- ------------------- ---------- ---------
OWASP SESSION BY SESSION BY SESSION

= 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

OWASP Backend Security Project Oracle Hardening

2008-08-15T21:23:24Z

Pderinaldis: /* Server side */

OWASP Backend Security Project Oracle Hardening

2008-08-15T21:22:31Z

Pderinaldis: /* Automated processing database accounts */

OWASP Backend Security Project Oracle Hardening

2008-08-15T21:20:46Z

Pderinaldis: /* Privileges and Roles */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===

Consider configuring the Oracle Advanced Security component to use Secure Socket Layer (SSL) encrypting network traffic between clients and databases to avoid network eavesdropping.
Below, you can see an example of a basic configuration:

==== Server side ====

To enable SSL database connection you should create an Oracle wallet (with the autologin feature) and generate a certificate request by using Wallet Manager component. Then you should send it to the Certificate Authority; when you receive CA trusted and the user certificate, you should import these certificate into your wallet.
Then you should configure the Oracle Advanced Security component by using the Net Manager utility (recommended) or modify the sqlnet.ora and listener.ora file.
At the end, the sqlnet.ora and listener.ora files should contain the following entries:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

==== Client side ====

After the wallet is configured, you should configure the client to use SSL connection to connect to databases by configuring sqlnet.ora file.
Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_SERVER_DN_MATCH = OFF
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

Now, you should define a network connection to the SSL listener by configuring the tnsname.ora file:

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = <host_name>)(PORT = <port>))
)
(CONNECT_DATA =
(SID = <SID_name>)
)
)

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== Audit ==

To properly protect database access you should implement auditing of user database activities in order to identify any suspicious activity or to check if an user has more privileges than expected.

=== Start Audit Service ===

To start the audit service you should execute “cataudit.sql” as SYS account. Then, you should choose if you want store the audit record to DataBase or Operating System file by setting the parameter “AUDIT_TRAIL” to DB or OS.
The database audit trail is a single table named SYS.AUD$, but there are predefined views that help you use the information in this table, while as regard operating system audit trail the audit records are written into the directory that you choose by setting the “AUDIT_FILE_DEST” parameter.

=== Enable Audit ===

Once you start the audit service, you can choose to audit the sys operation by setting the AUDIT_SYS_OPERATION to TRUE. So that, Oracle Database audit connections to the database with administrator privileges, database startup and shutdown.
Then, you can enable other options, by using AUDIT SQL statement:

* Statement Auditing.
* Privilege Auditing.
* Schema Object Auditing.

An example to audit some activities on table “test” owned by OWASP (Schema Object Auditing):

SQL> AUDIT INSERT, UPDATE, DELETE ON owasp.test BY ACCESS;

Oracle Database allow to write a single audit record for all SQL statements in the same session, using the “by session” option in the audit SQL command or to write one record for each access, using the “by access” option.
Then, Oracle Database allows, also, to write the successful executions of statements, using the “whenever successful” option in the audit SQL command or unsuccessful attempts to execute statements, using the “whenever not successful”.

=== Disable Audit ===

To turning off an audit options you should use the statement “NOAUDIT”, such as:

SQL> NOAUDIT ALL PRIVILEGES;

=== Check Audit ===

If you are using the database audit trail you should use the “SELECT” statement from the follow view to show the enabled audit:

{| class="wikitable"
! Type of Audit !! View Name
|-
| Default Auditing || ALL_DEF_AUDIT_OPTS
|-
|-
| Statment Auditing || DBA_STMT_AUDIT_OPTS
|-
|-
| Object Auditing || DBA_OBJ_AUDIT_OPTS
|-
|-
| Privilege Auditing || DBA_PRIV_AUDIT_OPT
|-
|}

An example:

SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;

USER_NAME AUDIT_OPTION SUCCESS FAILURE
-------------------- ------------------- ---------- ---------
OWASP SESSION BY SESSION BY SESSION

= 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

OWASP Backend Security Project Oracle Hardening

2008-08-12T10:51:09Z

Pderinaldis: /* CHECK AUDIT */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===

Consider configuring the Oracle Advanced Security component to use Secure Socket Layer (SSL) encrypting network traffic between clients and databases to avoid network eavesdropping.
Below, you can see an example of a basic configuration:

==== Server side ====

To enable SSL database connection you should create an Oracle wallet (with the autologin feature) and generate a certificate request by using Wallet Manager component. Then you should send it to the Certificate Authority; when you receive CA trusted and the user certificate, you should import these certificate into your wallet.
Then you should configure the Oracle Advanced Security component by using the Net Manager utility (recommended) or modify the sqlnet.ora and listener.ora file.
At the end, the sqlnet.ora and listener.ora files should contain the following entries:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

==== Client side ====

After the wallet is configured, you should configure the client to use SSL connection to connect to databases by configuring sqlnet.ora file.
Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_SERVER_DN_MATCH = OFF
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

Now, you should define a network connection to the SSL listener by configuring the tnsname.ora file:

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = <host_name>)(PORT = <port>))
)
(CONNECT_DATA =
(SID = <SID_name>)
)
)

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== Audit ==

To properly protect database access you should implement auditing of user database activities in order to identify any suspicious activity or to check if an user has more privileges than expected.

=== Start Audit Service ===

To start the audit service you should execute “cataudit.sql” as SYS account. Then, you should choose if you want store the audit record to DataBase or Operating System file by setting the parameter “AUDIT_TRAIL” to DB or OS.
The database audit trail is a single table named SYS.AUD$, but there are predefined views that help you use the information in this table, while as regard operating system audit trail the audit records are written into the directory that you choose by setting the “AUDIT_FILE_DEST” parameter.

=== Enable Audit ===

Once you start the audit service, you can choose to audit the sys operation by setting the AUDIT_SYS_OPERATION to TRUE. So that, Oracle Database audit connections to the database with administrator privileges, database startup and shutdown.
Then, you can enable other options, by using AUDIT SQL statement:

* Statement Auditing.
* Privilege Auditing.
* Schema Object Auditing.

An example to audit some activities on table “test” owned by OWASP (Schema Object Auditing):

SQL> AUDIT INSERT, UPDATE, DELETE ON owasp.test BY ACCESS;

Oracle Database allow to write a single audit record for all SQL statements in the same session, using the “by session” option in the audit SQL command or to write one record for each access, using the “by access” option.
Then, Oracle Database allows, also, to write the successful executions of statements, using the “whenever successful” option in the audit SQL command or unsuccessful attempts to execute statements, using the “whenever not successful”.

=== Disable Audit ===

To turning off an audit options you should use the statement “NOAUDIT”, such as:

SQL> NOAUDIT ALL PRIVILEGES;

=== Check Audit ===

If you are using the database audit trail you should use the “SELECT” statement from the follow view to show the enabled audit:

{| class="wikitable"
! Type of Audit !! View Name
|-
| Default Auditing || ALL_DEF_AUDIT_OPTS
|-
|-
| Statment Auditing || DBA_STMT_AUDIT_OPTS
|-
|-
| Object Auditing || DBA_OBJ_AUDIT_OPTS
|-
|-
| Privilege Auditing || DBA_PRIV_AUDIT_OPT
|-
|}

An example:

SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;

USER_NAME AUDIT_OPTION SUCCESS FAILURE
-------------------- ------------------- ---------- ---------
OWASP SESSION BY SESSION BY SESSION

= 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

OWASP Backend Security Project Oracle Hardening

2008-08-12T10:49:16Z

Pderinaldis: /* CHECK AUDIT */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===

Consider configuring the Oracle Advanced Security component to use Secure Socket Layer (SSL) encrypting network traffic between clients and databases to avoid network eavesdropping.
Below, you can see an example of a basic configuration:

==== Server side ====

To enable SSL database connection you should create an Oracle wallet (with the autologin feature) and generate a certificate request by using Wallet Manager component. Then you should send it to the Certificate Authority; when you receive CA trusted and the user certificate, you should import these certificate into your wallet.
Then you should configure the Oracle Advanced Security component by using the Net Manager utility (recommended) or modify the sqlnet.ora and listener.ora file.
At the end, the sqlnet.ora and listener.ora files should contain the following entries:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

==== Client side ====

After the wallet is configured, you should configure the client to use SSL connection to connect to databases by configuring sqlnet.ora file.
Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_SERVER_DN_MATCH = OFF
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

Now, you should define a network connection to the SSL listener by configuring the tnsname.ora file:

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = <host_name>)(PORT = <port>))
)
(CONNECT_DATA =
(SID = <SID_name>)
)
)

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== Audit ==

To properly protect database access you should implement auditing of user database activities in order to identify any suspicious activity or to check if an user has more privileges than expected.

=== Start Audit Service ===

To start the audit service you should execute “cataudit.sql” as SYS account. Then, you should choose if you want store the audit record to DataBase or Operating System file by setting the parameter “AUDIT_TRAIL” to DB or OS.
The database audit trail is a single table named SYS.AUD$, but there are predefined views that help you use the information in this table, while as regard operating system audit trail the audit records are written into the directory that you choose by setting the “AUDIT_FILE_DEST” parameter.

=== Enable Audit ===

Once you start the audit service, you can choose to audit the sys operation by setting the AUDIT_SYS_OPERATION to TRUE. So that, Oracle Database audit connections to the database with administrator privileges, database startup and shutdown.
Then, you can enable other options, by using AUDIT SQL statement:

* Statement Auditing.
* Privilege Auditing.
* Schema Object Auditing.

An example to audit some activities on table “test” owned by OWASP (Schema Object Auditing):

SQL> AUDIT INSERT, UPDATE, DELETE ON owasp.test BY ACCESS;

Oracle Database allow to write a single audit record for all SQL statements in the same session, using the “by session” option in the audit SQL command or to write one record for each access, using the “by access” option.
Then, Oracle Database allows, also, to write the successful executions of statements, using the “whenever successful” option in the audit SQL command or unsuccessful attempts to execute statements, using the “whenever not successful”.

=== Disable Audit ===

To turning off an audit options you should use the statement “NOAUDIT”, such as:

SQL> NOAUDIT ALL PRIVILEGES;

=== CHECK AUDIT ===

If you are using the database audit trail you should use the “SELECT” statement from the follow view to show the enabled audit:

{| class="wikitable"
! Type of Audit !! View Name
|-
| Default Auditing || ALL_DEF_AUDIT_OPTS
|-
|-
| Statment Auditing || DBA_STMT_AUDIT_OPTS
|-
|-
| Object Auditing || DBA_OBJ_AUDIT_OPTS
|-
|-
| Privilege Auditing || DBA_PRIV_AUDIT_OPT
|-

An example:

SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;

USER_NAME AUDIT_OPTION SUCCESS FAILURE
-------------------- ------------------- ---------- ---------
OWASP SESSION BY SESSION BY SESSION

= 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

OWASP Backend Security Project Oracle Hardening

2008-08-12T10:45:17Z

Pderinaldis: /* Enable Audit */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===

Consider configuring the Oracle Advanced Security component to use Secure Socket Layer (SSL) encrypting network traffic between clients and databases to avoid network eavesdropping.
Below, you can see an example of a basic configuration:

==== Server side ====

To enable SSL database connection you should create an Oracle wallet (with the autologin feature) and generate a certificate request by using Wallet Manager component. Then you should send it to the Certificate Authority; when you receive CA trusted and the user certificate, you should import these certificate into your wallet.
Then you should configure the Oracle Advanced Security component by using the Net Manager utility (recommended) or modify the sqlnet.ora and listener.ora file.
At the end, the sqlnet.ora and listener.ora files should contain the following entries:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

==== Client side ====

After the wallet is configured, you should configure the client to use SSL connection to connect to databases by configuring sqlnet.ora file.
Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_SERVER_DN_MATCH = OFF
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

Now, you should define a network connection to the SSL listener by configuring the tnsname.ora file:

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = <host_name>)(PORT = <port>))
)
(CONNECT_DATA =
(SID = <SID_name>)
)
)

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== Audit ==

To properly protect database access you should implement auditing of user database activities in order to identify any suspicious activity or to check if an user has more privileges than expected.

=== Start Audit Service ===

To start the audit service you should execute “cataudit.sql” as SYS account. Then, you should choose if you want store the audit record to DataBase or Operating System file by setting the parameter “AUDIT_TRAIL” to DB or OS.
The database audit trail is a single table named SYS.AUD$, but there are predefined views that help you use the information in this table, while as regard operating system audit trail the audit records are written into the directory that you choose by setting the “AUDIT_FILE_DEST” parameter.

=== Enable Audit ===

Once you start the audit service, you can choose to audit the sys operation by setting the AUDIT_SYS_OPERATION to TRUE. So that, Oracle Database audit connections to the database with administrator privileges, database startup and shutdown.
Then, you can enable other options, by using AUDIT SQL statement:

* Statement Auditing.
* Privilege Auditing.
* Schema Object Auditing.

An example to audit some activities on table “test” owned by OWASP (Schema Object Auditing):

SQL> AUDIT INSERT, UPDATE, DELETE ON owasp.test BY ACCESS;

Oracle Database allow to write a single audit record for all SQL statements in the same session, using the “by session” option in the audit SQL command or to write one record for each access, using the “by access” option.
Then, Oracle Database allows, also, to write the successful executions of statements, using the “whenever successful” option in the audit SQL command or unsuccessful attempts to execute statements, using the “whenever not successful”.

=== Disable Audit ===

To turning off an audit options you should use the statement “NOAUDIT”, such as:

SQL> NOAUDIT ALL PRIVILEGES;

=== CHECK AUDIT ===

If you are using the database audit trail you should use the “SELECT” statement from the follow view to show the enabled audit:

Type of Audit View Name
Default Auditing ALL_DEF_AUDIT_OPTS
Statment Auditing DBA_STMT_AUDIT_OPTS
Privilege Auditing DBA_PRIV_AUDIT_OPT
Object Auditing DBA_OBJ_AUDIT_OPTS

An example:

SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;

USER_NAME AUDIT_OPTION SUCCESS FAILURE
-------------------- ------------------- ---------- ---------
OWASP SESSION BY SESSION BY SESSION

= 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

OWASP Backend Security Project Oracle Hardening

2008-08-12T10:42:15Z

Pderinaldis: /* Audit */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===

Consider configuring the Oracle Advanced Security component to use Secure Socket Layer (SSL) encrypting network traffic between clients and databases to avoid network eavesdropping.
Below, you can see an example of a basic configuration:

==== Server side ====

To enable SSL database connection you should create an Oracle wallet (with the autologin feature) and generate a certificate request by using Wallet Manager component. Then you should send it to the Certificate Authority; when you receive CA trusted and the user certificate, you should import these certificate into your wallet.
Then you should configure the Oracle Advanced Security component by using the Net Manager utility (recommended) or modify the sqlnet.ora and listener.ora file.
At the end, the sqlnet.ora and listener.ora files should contain the following entries:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

==== Client side ====

After the wallet is configured, you should configure the client to use SSL connection to connect to databases by configuring sqlnet.ora file.
Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_SERVER_DN_MATCH = OFF
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

Now, you should define a network connection to the SSL listener by configuring the tnsname.ora file:

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = <host_name>)(PORT = <port>))
)
(CONNECT_DATA =
(SID = <SID_name>)
)
)

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== Audit ==

To properly protect database access you should implement auditing of user database activities in order to identify any suspicious activity or to check if an user has more privileges than expected.

=== Start Audit Service ===

To start the audit service you should execute “cataudit.sql” as SYS account. Then, you should choose if you want store the audit record to DataBase or Operating System file by setting the parameter “AUDIT_TRAIL” to DB or OS.
The database audit trail is a single table named SYS.AUD$, but there are predefined views that help you use the information in this table, while as regard operating system audit trail the audit records are written into the directory that you choose by setting the “AUDIT_FILE_DEST” parameter.

=== Enable Audit ===

Once you start the audit service, you can choose to audit the sys operation by setting the AUDIT_SYS_OPERATION to TRUE. So that, Oracle Database audit connections to the database with administrator privileges, database startup and shutdown.
Then, you can enable other options, by using AUDIT SQL statement:

1. Statement Auditing
2. Privilege Auditing
3. Schema Object Auditing

An example to audit some activities on table “test” owned by OWASP (Schema Object Auditing):

SQL> AUDIT INSERT, UPDATE, DELETE ON owasp.test BY ACCESS;

Oracle Database allow to write a single audit record for all SQL statements in the same session, using the “by session” option in the audit SQL command or to write one record for each access, using the “by access” option.
Then, Oracle Database allows, also, to write the successful executions of statements, using the “whenever successful” option in the audit SQL command or unsuccessful attempts to execute statements, using the “whenever not successful”.

=== Disable Audit ===

To turning off an audit options you should use the statement “NOAUDIT”, such as:

SQL> NOAUDIT ALL PRIVILEGES;

=== CHECK AUDIT ===

If you are using the database audit trail you should use the “SELECT” statement from the follow view to show the enabled audit:

Type of Audit View Name
Default Auditing ALL_DEF_AUDIT_OPTS
Statment Auditing DBA_STMT_AUDIT_OPTS
Privilege Auditing DBA_PRIV_AUDIT_OPT
Object Auditing DBA_OBJ_AUDIT_OPTS

An example:

SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;

USER_NAME AUDIT_OPTION SUCCESS FAILURE
-------------------- ------------------- ---------- ---------
OWASP SESSION BY SESSION BY SESSION

= 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

OWASP Backend Security Project Oracle Hardening

2008-08-07T08:47:53Z

Pderinaldis: /* Protect network communications */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===

Consider configuring the Oracle Advanced Security component to use Secure Socket Layer (SSL) encrypting network traffic between clients and databases to avoid network eavesdropping.
Below, you can see an example of a basic configuration:

==== Server side ====

To enable SSL database connection you should create an Oracle wallet (with the autologin feature) and generate a certificate request by using Wallet Manager component. Then you should send it to the Certificate Authority; when you receive CA trusted and the user certificate, you should import these certificate into your wallet.
Then you should configure the Oracle Advanced Security component by using the Net Manager utility (recommended) or modify the sqlnet.ora and listener.ora file.
At the end, the sqlnet.ora and listener.ora files should contain the following entries:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

==== Client side ====

After the wallet is configured, you should configure the client to use SSL connection to connect to databases by configuring sqlnet.ora file.
Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location> )
)
)

SSL_SERVER_DN_MATCH = OFF
SSL_CLIENT_AUTHENTICATION = FALSE
SQLNET.AUTHENTICATION_SERVICES= (TCPS)

Now, you should define a network connection to the SSL listener by configuring the tnsname.ora file:

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = <host_name>)(PORT = <port>))
)
(CONNECT_DATA =
(SID = <SID_name>)
)
)

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== 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

OWASP Backend Security Project Oracle Hardening

2008-08-06T18:13:50Z

Pderinaldis: /* Initialization parameters */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server stores debugging trace file of a user process || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server writes debugging trace file of background process || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to a protect directory considering that is the directory where the server dumps core files.|| <Protected Directory>
|-
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== 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

OWASP Backend Security Project Oracle Hardening

2008-08-06T18:00:51Z

Pderinaldis: /* Network address restriction */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== Network address restriction ===

The network address restrictions should be enforced by the Oracle listener to further protect your database from unauthorized remote access, especially when the PLSQL EXTPROC is in use.
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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== 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

OWASP Backend Security Project Oracle Hardening

2008-08-06T17:58:04Z

Pderinaldis: /* Privileges and Roles */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:

Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== 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

OWASP Backend Security Project Oracle Hardening

2008-08-06T17:56:25Z

Pderinaldis: /* Inbound connection timeout */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:
Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

=== Logging ===

To enable logging on the listener, you should use Net Manager utility or modify the listener.ora file on server machine.
At the end, the listener.ora file should contain the follow entries:

LOGGING_<listener name> = ON
LOG_DIRECTORY_<listener name> = <log directory location>
LOG_FILE_<listener name> = <log file name>

== 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

OWASP Backend Security Project Oracle Hardening

2008-07-25T21:14:12Z

Pderinaldis: /* Initialization parameters */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:
Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-07-02T14:36:46Z

Pderinaldis: /* Roles */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| AUDIT_SYS_OPERATIONS || This parameter should be set to TRUE to ...
|| TRUE
|-
| AUDIT_TRAIL || This parameter should be set to OS to...
|| OS
|-
| AUDIT_FILE_DEST (UNIX only) || This parameter should be set to...
|| <Protected Directory>
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

Example SQL for assigning profile profile to a user:

SQL> CREATE USER <user_name> IDENTIFIED BY <password> PROFILE <profile_name>;

=== Privileges and Roles ===

Due to the great number and variety of applications that make use of the database, it’s difficult to define in advance witch kind of privilege have to be grant to a user. In order to make this choice, you should practice the “principle of least privilege”, that is not providing database users, especially PUBLIC, more privileges than necessary.

The user privileges are split in System Privileges and Object Privileges, you can grant privileges to users explicitly:

SQL> GRANT <object_privilege> ON <object_name> TO <user_name>;
SQL> GRANT <system_privilege> TO <user_name> [WITH ADMIN OPTION];

Where “WITH ADMIN OPTION” means that the new user can grant the same system privilege to another user.

Also, you can grant privileges to a role (recommended), a group of privileges:

SQL> GRANT <object_privilege> ON <object_name> TO <role_name>;
SQL> GRANT <system_privilege> TO <role_name>;

and then you should grant the role to users:

SQL> GRANT <role_name> TO <user_name>;

Periodically, you should review the privileges (system and object) of the all database user. As an example, you can use the follow SQL script by executing as a user with the right privileges in order to review the system privilege (only) of specific user:

set pagesize 0
set head off
set feed off
set linesize 240
set trimspool on
col ord noprint
set echo off
accept username prompt' Insert a value for username:'
SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS"
FROM (
SELECT NULL grantee, username granted_role
FROM dba_users
WHERE username LIKE UPPER('&&username')
UNION
SELECT grantee, granted_role
FROM dba_role_privs
UNION
SELECT grantee, privilege
FROM dba_sys_privs)
START WITH grantee IS NULL
CONNECT BY grantee = prior granted_role;

An example of output:
Insert a value for username: owasp
OWASP
CONNECT
CREATE SESSION
RESOURCE
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
UNLIMITED TABLESPACE

Afterward revoke the privileges that is not necessary from user:

SQL> REVOKE <system_privilege> FROM <user_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <user_name>;

or from role:

SQL> REVOKE <system_privilege> FROM <role_name>;
SQL> REVOKE <object_privilege> ON <object_name> FROM <role_name>;

=== Automated processing database accounts ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-06-19T08:52:40Z

Pderinaldis: /* Enforce password policy */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| AUDIT_SYS_OPERATIONS || This parameter should be set to TRUE to ...
|| TRUE
|-
| AUDIT_TRAIL || This parameter should be set to OS to...
|| OS
|-
| AUDIT_FILE_DEST (UNIX only) || This parameter should be set to...
|| <Protected Directory>
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 <function_name>

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 ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-06-16T10:31:05Z

Pderinaldis: /* Files and directories */

= 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 ===

You should use a advanced installation to custom the installation process so that you be able to install only the component required by application will connect to database.

=== Sample schemas ===

You should review installed schema, especially the sample schemas provided by Oracle base installation, and remove any schema you do not need.

Example SQL to remove a schema:

SQL> DROP USER <user_name> CASCADE;

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| AUDIT_SYS_OPERATIONS || This parameter should be set to TRUE to ...
|| TRUE
|-
| AUDIT_TRAIL || This parameter should be set to OS to...
|| OS
|-
| AUDIT_FILE_DEST (UNIX only) || This parameter should be set to...
|| <Protected Directory>
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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 should be restricted to the Oracle software owner and the DBA user group, especially the file list below:

{| class="wikitable"
! 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 although you sholud configure the permission of all files stored in the “bin” directory in order to be owned by the Oracle software installation account.

=== Patching ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

== 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 ===

The major weakness using batch jobs is to manage user names and passwords in fact, typically, it connects to databases by using directly the command sqlplus:

sqlplus -s <user_name>/<password>@<TNS alias> << EOF
<SQL statement>
EOF

In this way you can just see the username and password in clear text by using the command to check the process status, such as ''“ps” ''command in unix environment.
To avoid it you can use a standard CONNECT statement within batch jobs, like this:

sqlplus /nolog << EOF
CONNECT <user_name>/<password>
<SQL statement>
EOF

In this last case it is suggested to save the crypted password in a well protected configuration file and then decrypting them just before execute the CONNECT statement.

Another (recommended) possibility is to delegate the password management to a guaranteeded third part as Secure External Password Store provided by Oracle Advanced Security component that save the credentials in a secure way.

When the clients are configured to use the secure external password store, batch jobs can connect to a database replacing the login credentials with an alias (database connection string) stored into container (named wallet).

To enable clients to use the external password store the first thing to do is to create an Oracle wallet with the autologin feature (access to wallet contents not require a password ) by using the follow command from OS command prompt:

mkstore -wrl <wallet_location> -create

Then, you should create database connection credentials in the wallet:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>

After the wallet is ready, you should force the client to use the information stored in the “secure password store” to authenticate to databases by configuring sqlnet.ora file.

Example of entries to add in sqlnet.ora file:

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = <wallet_location>)
)
)

SQLNET.WALLET_OVERRIDE = TRUE

The same configuration are possible to do by using Oracle Wallet Manager.

Doing in this way the risk is reduced because passwords are no exposed in the clear considering the applications can connect to a database with the following CONNECT statement syntax:

connect /@<db_connect_string>

where “db_connect_string” is the database connection credential, created before.

== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
You should configure the Oracle Advanced Security component to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases to avoid network eavesdropping.
Enabling the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 ===

The EXTPROC functionality used by PL/SQL component to make calls to the operating system and to load necessary library to execute external procedure, but if the Oracle Database server is not properly patched it even could allows unauthorized administrative access to the server machine through the Oracle Listener.
If the EXTPROC functionality is not required, you should disable it by editing the tnsname.ora and listener.ora files and removing the entries regarding this functionality.

Example of entries to remove in tnsname.ora file:

[…]
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
[…]

Example of entries to remove in listener.ora file:

[…]
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
[…]

[…]
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = […])
)
[…]

After that you should restart the Oracle Net listener process.

Then you should check if the configuration take effect by using the operation status in LSNRCTL command.
You should review the configuration if the last command display the follow lines:

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
[…]
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
[…]

Otherwise, the configuration is correct!

If, instead, the EXTPROC functionality is required in your environment, you should configure a Oracle Net Listener for PL/SQL EXTPROC with an IPC (recommended) or TCP protocol address.
It is a good idea enforce the network address restrictions when you use the TCP protocol address.

=== Inbound connection timeout ===

The amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-06-05T07:40:37Z

Pderinaldis: /* Files and directories */

OWASP Backend Security Project Oracle Hardening

2008-06-05T07:38:55Z

Pderinaldis: /* Sample schemas */

OWASP Backend Security Project Oracle Hardening

2008-06-05T07:38:25Z

Pderinaldis: /* Operating system security */

OWASP Backend Security Project Oracle Hardening

2008-06-05T07:37:49Z

Pderinaldis: /* Patching */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:56:20Z

Pderinaldis: /* Sample schemas */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:52:22Z

Pderinaldis: /* Protect network communications */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:51:43Z

Pderinaldis: /* Protect network communications */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:51:02Z

Pderinaldis: /* Protect network communications */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:48:34Z

Pderinaldis: /* Protect network communications */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:42:01Z

Pderinaldis: /* Sample schemas */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:34:54Z

Pderinaldis: /* Options and products */

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:05:19Z

Pderinaldis: /* Options and products */

= 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 ===

You should use a "custom installation" to install only the component required by application will connect to database.

As often as the component required to provide a standard security operation are list in the follow table:

{| class="wikitable"
! 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 ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| AUDIT_SYS_OPERATIONS || This parameter should be set to TRUE to ...
|| TRUE
|-
| AUDIT_TRAIL || This parameter should be set to OS to...
|| OS
|-
| AUDIT_FILE_DEST (UNIX only) || This parameter should be set to...
|| <Protected Directory>
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-06-04T18:00:50Z

Pderinaldis: /* Options and products */

= 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 ===

You should use a "custom installation" to install only the component required by application will connect to database.

As often as the component required to provide a standard operation are list in the follow table:

{| class="wikitable"
! 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 ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| AUDIT_SYS_OPERATIONS || This parameter should be set to TRUE to ...
|| TRUE
|-
| AUDIT_TRAIL || This parameter should be set to OS to...
|| OS
|-
| AUDIT_FILE_DEST (UNIX only) || This parameter should be set to...
|| <Protected Directory>
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-06-04T17:43:16Z

Pderinaldis: /* Patching */

= 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.

{| class="wikitable"
! 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 ===
You should keep up to date the Oracle Database therefore, periodically, you should check the Oracle Technology Network web site (http://otn.oracle.com/deploy/security/alerts.htm) to keep up on security alerts issued from Oracle Corporation in regard to all installed components.

Sometime, there are public vulnerility about Oracle software without a patch so it is a good idea subscribe to the security mailing lists so that you will be able to catch those new security issues and to find a way to mitigate the risk of the new vulnerability.

=== 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| AUDIT_SYS_OPERATIONS || This parameter should be set to TRUE to ...
|| TRUE
|-
| AUDIT_TRAIL || This parameter should be set to OS to...
|| OS
|-
| AUDIT_FILE_DEST (UNIX only) || This parameter should be set to...
|| <Protected Directory>
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T18:59:55Z

Pderinaldis: /* Initialization parameters */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || This parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any directories that Oracle should use for PL/SQL file I/O.
|| NULL
|-
| AUDIT_SYS_OPERATIONS || This parameter should be set to TRUE to ...
|| TRUE
|-
| AUDIT_TRAIL || This parameter should be set to OS to...
|| OS
|-
| AUDIT_FILE_DEST (UNIX only) || This parameter should be set to...
|| <Protected Directory>
|-
| USER_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| BACKGROUND_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| CORE_DUMP_DEST || This parameter should be set to ... || <Protected Directory>
|-
| 07_DICTIONARY_ACCESSIBILITY || This parameter should be set to FALSE to... || FALSE
|}

Example SQL for setting the REMOTE_OS_AUTHENTICATION parameter:

SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENTICATION = FALSE SCOPE=BOTH

Scope:
* MEMORY: This value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T16:35:39Z

Pderinaldis: /* Initialization parameters */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || FALSE
|-
| REMOTE_LOGIN_PASSWORDFILE || This parameter should be set to NONE, but if this functionality is required set the parameter EXCLUSIVE to make it more secure considering that that the password file can be used by only one database. || NONE
|-
| RESOURCE_LIMIT || This parameter should be set to TRUE to enforce other parameter about resource limitsuch as idle time limits. The default is FALSE.
|| TRUE
|-
| REMOTE_OS_ROLES || This parameter should be set to FALSE to deny the operating system groups to control Oracle roles. || FALSE
|-
| OS_ROLES || Thi parameter should be set to FALSE to configure Oracle to identifies and manages the roles.
Default value false.
|| FALSE
|-
| UTL_FILE_DIR || This parameter should be set to NULL to specify any 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T16:07:24Z

Pderinaldis: /* Initialization parameters */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! Parameter name !! Description !! Security value
|-
| REMOTE_OS_AUTHENTICATION || This parameter should be set to FALSE to deny the authentication of remote clients by operating system. || 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:32:55Z

Pderinaldis: /* Admin restrictions */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:30:28Z

Pderinaldis: /* Inbound connection timeout */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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 amount of time the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:28:59Z

Pderinaldis: /* Inbound connection timeout */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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 the listener waits for a network client to complete the connection request should be manage to prevent a denial of service attack.
The name of parameter to set to configure inbound connection timeout and the name of the file of configuration, depends on Oracle version.

== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:25:32Z

Pderinaldis: /* Password */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized start, stop, and configure. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:23:54Z

Pderinaldis: /* Protect network communications */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by following the next step:

...

=== 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 at the end of listener configuration process to avoid from unauthorized starting, stopping, and configuring. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:21:52Z

Pderinaldis: /* Password */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by using the follow command:

...

=== 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 at the end of listener configuration process to avoid from unauthorized starting, stopping, and configuring. The password will be stored in encrypted format within the listener.ora file by using the LSNRCTL utility:

LSNRCTL> set current_listener <listener_name>
LNSRCTL> set password
Password: (type "enter" if it is the first time)
The command completed successfully
LSNRCTL> change_password
Old password: (type "enter")
New password: <new_password>
Reenter new password: <new_password>
[…]
The command completed successfully
LSNRCTL> save_config (important to save the configuration)
[…]
Saved LISTENER configuration parameters.
Listener Parameter File […]
Old Parameter File […]
The command completed successfully
LSNRCTL> exit

=== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:12:13Z

Pderinaldis: /* Protect network communications */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
Enable the protection about network communication by using the follow command:

...

=== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:11:13Z

Pderinaldis: /* Protect network communications */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== Protect network communications ===
It is a good idea use the Oracle Advanced Security to use Secure Socket Layer (SSL) as to encrypt network traffic between clients and databases.
To enable the protection about network communication use the follow command:

...

=== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T15:02:57Z

Pderinaldis: /* Encrypt network logins */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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.
Note that on Oracle version 9.02 and later these parameter are not available, in fact it is encrypt automatically the password information when transmitting over a network, although the setting or changing of passwords is NOT encrypted when across the network.

=== 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

OWASP Backend Security Project Oracle Hardening

2008-05-29T14:57:59Z

Pderinaldis: /* Change default password */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 major weakness concerning the password is that some user default account, after the installation, still has a default password associated with it, so you should be review the passwords of all default accounts (SYS, SYSTEM, DBSNMP, OUTLN and so on) and change it if necessary.

=== 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 be 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

OWASP Backend Security Project Oracle Hardening

2008-05-28T08:24:48Z

Pderinaldis: /* Initialization parameters */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 (extended and not).
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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 be 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

OWASP Backend Security Project Oracle Hardening

2008-05-28T08:15:31Z

Pderinaldis: /* Initialization parameters */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 value change the instance immediately, but the configuration is lost after a restart.
* SPFILE: This value NOT change the instance immediately, but a restart is necessaty to take effect.
* BOTH: This value change the instance immediately 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:

{| class="wikitable"
! 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 be 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

OWASP Backend Security Project Oracle Hardening

2008-05-28T08:08:37Z

Pderinaldis: /* Initialization parameters */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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 change the instance immediately, 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: This change the instance immediately 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:

{| class="wikitable"
! 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 be 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

OWASP Backend Security Project Oracle Hardening

2008-05-28T08:06:03Z

Pderinaldis: /* Encrypt network logins */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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:

{| class="wikitable"
! 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 be 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

OWASP Backend Security Project Oracle Hardening

2008-05-28T07:49:37Z

Pderinaldis: /* XML database (XDB) protocol server */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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:

{| class="wikitable"
! 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

OWASP Backend Security Project Oracle Hardening

2008-05-28T07:43:54Z

Pderinaldis: /* Inbound connection timeout */

= 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.

{| class="wikitable"
! 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.

{| class="wikitable"
! 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:

{| class="wikitable"
! 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 the follow line:

*.dispatchers='(PROTOCOL=TCP) (SERVICE=<SID>XDB)'

If access via the Internet protocols is required, logging will be enabled by setting the “ftp-log-level” and “http-log-level” parameters to a value of 1 instead of 0 in xdbconfig.xml file.
It is also a good idea to configure the ports to a non-default port.

== 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