Oracle Database Asset Protection Standards:

Oracle Database Asset Protection Standards:

Oracle's security by default is not extremely good. For example, Oracle will allow users to choose single character passwords or select passwords that match their name or userid. Also, passwords do not expire. This means that one can compromise and have access to an Oracle account for years without an account expiration ever locking the user account.

On Unix platforms, the SYSDBA and SYSOPER groups are designated when the server is installed and both are set to the DBA group by default. Accounts in this group are able to connect to the database locally with full administrative rights, without using a password. With this being the case, only the "oracle" user is permitted in the DBA group. All other accounts MUST be removed from the DBA group.

Guest default accounts, which allow anonymous users to sign on the system, MUST be disabled, changed, or otherwise properly configured to prevent access to information classified as Proprietary or Confidential.

All this being said, the following items can be done to make an Oracle installation more secure.

Self assessments should be performed on a regular basis. I would recommend quarterly analysis be performed on your production database systems. This Oracle Script Media:Oracle_Audit_UNIX_Script.txt provides an excellent comprehensive audit examination that has stood up to many professional Oracle compliance audits on UNIX and Linux platforms.

Oracle can manage passwords through profiles. Database authentication MUST use a password security policy to maintain database access security. You MUST implement password constraints for all users that have the ability to change their passwords through the Oracle facilities, i.e., DBA's, SQL*Plus users. DBA's should use caution when setting these constraints on application ID's since some applications may be unable to allow the user to interact with the authentication facility; therefore, setting these constraints may disable access. All of the following parameters and values must be set in the profile used for all users whom have direct interactive access to the database. Use the following CREATE PROFILE statement to specify a maximum lifetime, grace period, and time interval for passwords.

Some of the things that one can restrict:

FAILED_LOGIN_ATTEMPTS - failed login attempts before the account is locked.

PASSWORD_LIFE_TIME - limits the number of days the same password can be used for authentication.

PASSWORD_REUSE_TIME - number of days before a password can be reused.

PASSWORD_REUSE_MAX - number of password changes required before the current password can be reused.

PASSWORD_LOCK_TIME - number of days an account will be locked after maximum failed login attempts.

Examples are: 1.0 = 24 hours, .5 = 12 hours, .25 = 6 hours, .125 = 3 hours, and .0625 = 1.5 hours.

PASSWORD_GRACE_TIME - number of days after the grace period begins during which a warning is issued and login is allowed.

PASSWORD_VERIFY_FUNCTION - password complexity verification script.

You should specify a profile when you create a user. A profile is a set of limits on database resources and password access to the database. If no profile is specified, the user is assigned a default profile.

Security administrators SHOULD consider issues related to privilege management for all types of users. For example, in a database with many usernames, it may be beneficial to use roles (named after groups of related privileges that you grant to users or other roles) to manage the privileges available to users. Alternatively, in a database with a handful of usernames, it may be easier to grant privileges explicitly to users and avoid the use of roles.

Security administrators managing a database with many users, applications, or objects SHOULD take advantage of the benefits offered by roles. Roles greatly simplify the task of privilege management in complicated environments.

Oracle allows operating system users to connect to the database as INTERNAL (Oracle 8i), or with SYSDBA and SYSOPER privileges, based on membership in special operating system-defined groups. To effectively control and audit privileged access to the database, only the "Oracle" account ID is allowed to be in the DBA group. Check for users that belong to operating system groups that give them access to the database with SYSDBA and/or SYSOPER privileges. On UNIX platforms, the SYSDBA and SYSOPER groups are designated when the server is installed and both are set to the DBA group by default. Accounts in this group are able to connect to the database locally with full administrative rights, without using a password. With this being the case, only the "oracle" user is permitted in the DBA group. All other accounts MUST be removed from the DBA group. On UNIX platforms, the SYSDBA and SYSOPER groups are designated when the server is installed and both are set to the DBA group by default. Accounts in this group are able to connect to the database locally with full administrative rights, without using a password. With this being the case, only the "oracle" user is permitted in the DBA group. All other accounts MUST be removed from the DBA group.

It is recommended that the accepted standards developed by the company be applied to the default profile to eliminate any possibility that a newly created account without a profile assignment be automatically assigned the default profile. Oracle's password complexity verification routine can be specified using a PL/SQL script (utlpwdmg.sql), which sets the default profile parameters. Check that the default password verification function, VERIFY_FUNCTION, has not been modified. The password complexity verification routine performs the following checks:

• The password has a minimum length of eight (8) characters.
  
• The password is not the same as the user ID.
  
• The password has at least one alpha and one numeric character.
  
• The password differs from the previous password by at least three (3) letters.
  
• The utlpwdmg.sql script creates a function (default name is "verify_function"), which enforces password strength. In order to create the verify_function, the utlpwdmg.sql MUST be run. The verify_function name MUST be listed in the PASSWORD_VERIFY_FUNCTION parameter of the profile created.
  

The password verification SQL script should have perms 600:

-rw------- 1 oracle dba 443578 Mar 10 23:03 utlpwdmg.sql

Complex password enforcement script example. Media:PASSWORD_FUNCTION.doc

The password verification SQL script should have perms 600:

-rw------- 1 oracle dba 443578 Mar 10 23:03 PASSWORD_FUNCTION

The Oracle executables must be protected from unauthorized use by:

Keeping all programs in the $ORACLE_HOME/bin directory and give ownership to the oracle software owner.

Giving all user utilities (sqlplus, exp, imp) a protection of 755 so all users on the machine can access the Oracle Server.

Giving the following DBA utilities a protection of 750 to restrict the use to the Oracle software owner.

-rwxr-x--- 1 oracle dba 443578 Mar 10 23:03 svrmgrl

-rwxr-x--- 1 oracle dba 443578 Mar 10 23:03 namesctl

-rwxr-x--- 1 oracle dba 443578 Mar 10 23:03 lsnrctl

-rwxr-x--- 1 oracle dba 443578 Mar 10 23:03 netasst

To access the protected database files, the Oracle program must have its set user ID (setuid) bit turned on. The Oracle software owner MUST own the directories containing the database files. For added security, revoke read permission from "other." The permissions should be:

-rwsr-s--x 1 oracle dba 443578 Mar 10 23:03 oracle

If you do not use Connection Manager, remove Oracle SUID. There are published exploits using the SUID bit on the following files:

$ORACLE_HOME\bin\cmctl

$ORACLE_HOME\bin\cmgw

$ORACLE_HOME\bin\cmadmin

Remove Oracle SUID bits by executing the following command as the Oracle user:

chmod -s $ORACLE_HOME/bin/cmctl

chmod -s $ORACLE_HOME/bin/cmgw

chmod -s $ORACLE_HOME/bin/cmadmin

List of Active and Inactive user accounts with dates.
SQL:
select username,account_status,lock_date,expiry_date from dba_users order by username

List the Oracle default profile (Select * from dba_profiles where resource_type = 'PASSWORD').
SQL:
Select * from dba_profiles where resource_type = 'PASSWORD'

Listing of current parameter block using SHOW PARAMETERS BLOCK.
SQL> SHOW PARAMETERS BLOCK

List privileges that have been granted to PUBLIC.
SQL:
select * from dba_tab_privs where grantee='PUBLIC'

Permissions on objects may be granted to users and roles and to the user group PUBLIC. Because every database user is a member of the PUBLIC group, granting object permissions to PUBLIC gives all users in the database access to that object. In a secure environment, you SHOULD restrict granting object permissions to PUBLIC for those objects that all users may access. System Privileges and Roles MUST not be granted to PUBLIC. Granting permissions, privileges and roles to PUBLIC gives every user those resources.

Object Permissions: Allow object permissions to PUBLIC only for objects that all users may access. Ensure that no privileges having the WITH ADMIN OPTION have been granted. This prevents the user from granting the privilege to other accounts. Revoking system privileges having the WITH ADMIN OPTION, however, does not revoke those privileges from other accounts that were given the privilege by the account being revoked. This makes revoking system privileges that were granted WITH ADMIN OPTION difficult as the privilege can be given to an account and then granted back after it is revoked.

List users who have been assigned these privileges (DBA_SYS_PRIVS):

ALTER_DATABASE

GRANT ANY PRIVILEGE

GRANT ANY ROLE

CREATE PROFILE

CREATE ROLE

RESTRICTED SESSION

STARTUP

CREATE SNAPSHOT

ATER SYSTEM

CREATE USER

ALTER USER

WITH ADMIN OPTION

List the records in the following tables:
DBA_ROLES
SQL:
select * from DBA_ROLES;

DBA_ROLE_PRIVS
SQL:
select * from DBA_ROLE_PRIVS;

DBA_SYS_PRIVS
SQL:
select * from DBA_SYS_PRIVS;

Accounts established for operating system, transmission and process user IDs are exempt from the user ID standards if controls are implemented that ensure there is no significant risk if the password SHOULD be compromised. Accounts MUST comply with the following:

• Each account MUST have the ability to be audited.
  
• Vendor-supplied default accounts and passwords MUST be disabled or changed immediately following each use.
  

Manually check the "SYS" account for the default password by manually attempting to logon to the account. Immediately change the default password if it is defined.

ROLE_ROLE_PRIVS
SQL:
select * from ROLE_ROLE_PRIVS;

ROLE_SYS_PRIVS
SQL:
select * from ROLE_SYS_PRIVS;

ROLE_TAB_PRIVS
SQL:
select * from ROLE_SYS_PRIVS;

List of users including PUBLIC who have table access with privileges of INSERT, UPDATE, ALTER, DELETE (from DBA_TAB_PRIVS).

List users with access to high-level administrative privileges:
SELECT * FROM SYS.DBA_SYS_PRIVS WHERE PRIVILEGE in ('ALTER DATABASE','GRANT ANY PRIVILEGE','GRANT ANY ROLE','CREATE PROFILE','CREATE ROLE','RESTRICTED SESSION','STARTUP','CREATE SNAPSHOT','ALTER SYSTEM','CREATE USER','ALTER USER' SQL:
SELECT * FROM SYS.DBA_SYS_PRIVS WHERE PRIVILEGE in ('ALTER DATABASE','GRANT ANY PRIVILEGE','GRANT ANY ROLE','CREATE PROFILE','CREATE ROLE','RESTRICTED SESSION','STARTUP','CREATE SNAPSHOT','ALTER SYSTEM','CREATE USER','ALTER USER')

Oracle auditing SHOULD be set to log audit data to the operating system file system. Logging events to the operating system files prevents database users from accessing the audit data. To set the audit trail destination, set the AUDIT_TRAIL value in the init.ora configuration file as follows:

AUDIT_TRAIL = OS

Oracle Event Auditing: Obtain output from the SELECT * FROM audit_actions

To protect the audit logs, the ORACLE user and the DBA group MUST own all files within the directory, as specified in the AUDIT_FILE_DEST parameter. Also, set the permission bits to 700.

Databases containing data of a highly sensitive nature SHOULD enable auditing of administrative accounts. Starting with Oracle's 9i Release2 the audit facility offers the functionality to audit database activity by SYS and SYSTEM via the AUDIT_SYS_OPERATIONS parameter in the INIT.ORA file. The default value for this parameter is FALSE and SHOULD be set to TRUE. All audit records for SYS are written to the operating system destination defined in the AUDIT_FILE_DEST parameter in the INIT.ORA file, and not to SYS.AUD$. All SYS issued SQL statements are audited indiscriminately and regardless of the setting of the AUDIT_TRAIL initialization parameter.

A password attack is indicated by a series of failed logons within a short period of time. Failed login attempts MUST be audited. To detect these attempts, you must turn on auditing of failed connections.

Examine the following files:

listener.ora

Check the permissions of the operating system file listener.ora. This file contains the listener password. You MUST restrict permissions to this file. Access to file could allow someone to determine the listener service password and to manipulate the listener service. Set the permissions for the listener.ora file to 640:

-rw-r----- 1 oracle dba 443578 Mar 10 23:03 listener.ora

In order to defend against external exploits, the listener is a major area of concern. The listener is a stepping-stone to gain privileged access to data. The PASSWORDS_ parameter MUST be set in the listener.ora file. This will cause the LSNRCTL control utility to require a SET PASSWORD command for any sensitive operations, such as starting or stopping the listener. The password MUST be set using change_password command in the lsnrctl utility. This causes the password value in the listener.ora file to be encrypted. The listener password MUST not be set using an editor. The SAVE_CONFIG command MUST be executed in the lsnrctl utility to commit the change, otherwise the password will revert to the previous one when the listener is restarted. Once this is completed, check the listener.ora file to verify that you have changed the default listener password.

snmp.ora

Check the SNMP.ORA (UNIX) or SNMP_RW.ORA (NT) files for weak permissions. The SNMP password (contained in the SNMP file) is used to prevent unauthorized users from issuing commands to the database via SNMP. Weak permissions may allow users to view or manipulate the password. Set the permissions for the snmp.ora file to 640:

-rw-r----- 1 oracle dba 443578 Mar 10 23:03 snmp.ora

oratclsh

The oratclsh file is a special purpose TCL shell used for debugging TCL scripts. Application and script development MUST be done in a development environment, and the SUID bit on the oratclsh file MUST be disabled in production servers. There are published exploits using the SUID bit on the oratclsh file:

$ORACLE_HOME\bin\oratclsh

Oracle Intelligent Agent: The dbsnmp and oemevent files are used to support the Intelligent Agent feature of the Oracle Enterprise Manager. The Intelligent agent feature is used to do remote database administration. Remote DB administration is not allowed and thus the SUID bit MUST be disabled on the following files:

$ORACLE_HOME\bin\oemevent

$ORACLE_HOME\bin\dbsnmp

The REMOTE_OS_AUTHENT parameter is set to FALSE by default and must remain set to FALSE. Setting this value to TRUE allows OS authentication over a non-secure connection. If REMOTE_OS_AUTHENT is set to true, the only information a remote user need to connect to the DB is the name of any user whose account is set up for the OS to authenticate. Oracle Net8 does not control automatic and remote DBA logins. They are controlled by the Oracle Server and configured using parameters in the init.ora file. Although automatic logins are supported, they are disabled by default.

The REMOTE_OS_AUTHENT initialization parameter MUST remain set to FALSE. Because Oracle controls these logins, it is not necessary to run the Oracle Net8 listener as setuid to root. Automatic logins are not allowed for the root user ID. Also, automatic logins by PC, Apple Macintosh, and OS/2 users are not secure. Anyone can edit the Oracle configuration file and change their user ID. For security reasons, if users of these systems are logging in over the network, Oracle Corporation strongly recommends you disable the ops$ logins in the listener.ora file. The following init.ora parameters control the behavior of remote connections through non-secure protocols and must be set to FALSE:

REMOTE_OS_AUTHENT = FALSE

The host operating system SHOULD authenticate all database users. Authentication via the host operating system is preferred for the following reasons:

• There is centralized control over user authorization in the operating system: Oracle needs not store or manage user passwords and usernames if the operating system and database correspond.
  
• User entries in the database and operating system audit trails correspond.
  

The REMOTE_LOGIN_PASSWORDFILE parameter in the init.ora file specifies whether Oracle checks for a password file and how many database users can use the password file. The REMOTE_LOGIN_PASSWORDFILE parameter SHOULD be set to NONE. This signifies that Oracle should ignore any password file and only OS accounts in the DBA group can CONNECT AS.

The PLSExtProc service is the mechanism Oracle uses to make external procedure calls via a database library reference created using the CREATE LIBRARY command. Since the process is simply another service as far as the listener is concerned, it is possible to interact with it directly without first having to connect to the database. Attackers can execute any function in any library remotely on a system running Oracle's database server without a user ID or password.

The PLSExtProc service MUST be disabled if external procedure calls are not required for the application used. Removing its entries from LISTENER.ORA and TNSNAMES.ORA can safely disable it. This action will prevent Oracle from being able to connect to the external procedure agent. To prevent reconfiguration of these files from re-enabling communications, remove the "execute" privilege from the executable. The PLS External Procedure service can have many different names depending upon the system and Oracle version installed. This could be icache_extproc, PLSExtproc, extproc or extproc.exe on Microsoft NT.

onrsd

Oracle Names Server The onrsd file is used to manage the Oracle Names Client Cache service. Disable the setuid bit on the file $ORACLE_HOME\bin\onrsd if Oracle Names server is not being used.
Database files:

Oracle uses a number of files that users do not require direct access to. The user ID employed to install Oracle8 MUST own the database files. The default ID is ORACLE. Set the permission bits on these files to 0640: read/write (R/W) by owner only, with no write and execute permissions for group and no permissions for "other."

Data dictionary:

Protect the data dictionary and prevent users having the "ANY" system privileges from using such privileges on the data dictionary. The init.ora configuration parameter MUST be set to the following value: O7_DICTIONARY_ACCESSIBILITY = FALSE By doing so, only authorized users making DBA-privileged (e.g., CONNECT / AS SYSBA) connections can use the "ANY" system privilege on the data dictionary.

UTL_FILE_DIR

The UTL_FILE_DIR parameter MUST not contain ' * ' or '. ' in the INIT.ORA file. Setting the parameter to * allows the UTL_FILE package permissions on all directories. The UTL_FILE package allows file I/O from PL/SQL on the client and server side. The client implementation is subject to normal operating system file permission checking and does not need any additional security constraints. Nevertheless, the server implementation might be running in a privileged mode and thus will need additional security restrictions that limit the power of this feature. The parameter specification UTL_FILE_DIR = * in effect turns off directory access checking and makes any directory accessible to the UTL_FILE functions.

To ensure security on file systems that allow symbolic links, users MUST not be allowed WRITE permission to directories accessible by PL/SQL file I/O functions. The symbolic links and PL/SQL file I/O could be used to circumvent normal operating system permission checking and allow users read/write access to directories to which they would not otherwise have access.

init.ora

Check the permissions of the init.ora file. This file contains the database parameter settings. Access permissions MUST be restricted to this file. READ access by "other" to this file could allow a user to determine security settings in the database.

Patches and Maintenance:

Apply all relevant and current security patches for the respective Oracle database version, and for all installed Oracle options and components.

Here is the Oracle MetaLink login and registration link:

metalink.oracle.com

Also, regularly check the security alerts posted on Oracle Technology Network for details on current alerts released by Oracle.

Here are useful links:

otn.oracle.com

technet.oracle.com

--Mdpeters 10:36, 16 November 2007 (EST)