7 Security Policies

System Security Policy

This section describes the different aspects of system security policy, and contains the following topics:

• Database User Management

• User Authentication

• Operating System Security

Each database has one or more administrators who are responsible for maintaining all aspects of the security policy: the security administrators. If the database system is small, then the database administrator may have the responsibilities of the security administrator. However, if the database system is large, then a special person or group of people may have responsibilities limited to those of a security administrator.

After deciding who will manage the security of the system, a security policy must be developed for every database. A database security policy should include several sub-policies, as explained in the following sections.

Data Security Policy

Data security includes the mechanisms that control the access to and use of the database at the object level. Your data security policy determines which users have access to a specific schema object, and the specific types of actions allowed for each user on the object. For example, the policy could establish that user scott can issue SELECT and INSERT statements but not DELETE statements using the emp table. Your data security policy should also define the actions, if any, that are audited for each schema object.

Primarily, the level of security you want to establish for the data in your database determines your data security policy. For example, it may be acceptable to have little data security in a database when you want to allow any user to create any schema object, or grant access privileges for their objects to any other user of the system. Alternatively, it might be necessary for data security to be very controlled when you want to allow only a database or security administrator to create objects and grant access privileges for objects to roles and users.

Overall data security should be based on the sensitivity of data. If information is not sensitive, then the data security policy can be more lax. However, if data is sensitive, then a security policy should be developed to maintain tight control over access to objects.

Some means of implementing data security include system and object privileges, and through roles. A role is a set of privileges grouped together that can be granted to users.

Views can also implement data security because their definition can restrict access to table data. They can exclude columns containing sensitive data.

Another means of implementing data security is through fine-grained access control and use of an associated application context. Fine-grained access control is a feature of Oracle Database that enables you to implement security policies with functions, and to associate those security policies with tables or views. In effect, the security policy function generates a WHERE condition that is appended to relevant SQL statements, thereby restricting user access to rows of data in the table or view. An application context is a secure data cache for storing information used to make access control decisions.

User Security Policy

This section describes aspects of user security policy, and contains the following topics:

• General User Security

• End-User Security

• Administrator Security

• Application Developer Security

• Application Administrator Security

End-User Security

Security administrators must define a policy for end-user security. If a database has many users, then the security administrator can decide which groups of users can be categorized into user groups, and then create user roles for these groups. The security administrator can grant the necessary privileges or application roles to each user role, and assign the user roles to the users. To account for exceptions, the security administrator must also decide what privileges must be explicitly granted to individual users.

Using Roles for End-User Privilege Management

Roles are the easiest way to grant and manage the common privileges needed by different groups of database users.

Consider a situation where every user in the accounting department of a company needs the privileges to run the accounts receivable and accounts payable database applications (ACCTS_REC and ACCTS_PAY). Roles are associated with both applications, and they contain the object privileges necessary to execute those applications.

The following actions, performed by the database or security administrator, address this simple security situation:

1. Create a role named accountant.

2. Grant the roles for the ACCTS_REC and ACCTS_PAY database applications to the accountant role.

3. Grant each user of the accounting department the accountant role.

This security model is illustrated in Figure 7-1.

Figure 7-1 User Roles

Description of "Figure 7-1 User Roles"

This plan addresses the following potential situations:

• If accountants subsequently need a role for a new database application, then the role for that application can be granted to the accountant role, and all users in the accounting department will automatically receive the privileges associated with the new database application. The role for the new application does not need to be granted to individual users requiring use of the application.

• Similarly, if the accounting department no longer requires the need for a specific application, then the role associated with that application can be dropped from the accountant role.

• If the privileges required by the ACCTS_REC and ACCTS_PAY applications change, then the new privileges can be granted to, or revoked from, the role associated with the application. The security domain of the accountant role, and all users granted the accountant role, automatically reflect the privilege modification.

Use roles in all possible situations to make end-user privilege management efficient and simple.

Using a Directory Service for End-User Privilege Management

You can also manage users and their authorizations centrally in a directory service through the enterprise user and enterprise role features of Oracle Advanced Security. See the Oracle Database Advanced Security Administrator's Guide for information about this functionality.

CONNECT username/password AS SYSDBA/SYSOPER

Password Management Policy

Database security systems that are dependent on passwords require that passwords be kept secret at all times. Because passwords are vulnerable to theft, forgery, and misuse, Oracle Database uses a password management policy. DBAs and security officers control this policy through user profiles, enabling greater control over database security.

Use the CREATE PROFILE statement to create a user profile. The profile is assigned to a user with the CREATE USER or ALTER USER statement. Details of creating and altering database users are not discussed in this section. This section is concerned with the password parameters that can be specified using the CREATE PROFILE (or ALTER PROFILE) statement.

This section contains the following topics relating to Oracle password management:

• Account Locking

• Password Aging and Expiration

• Password History

• Password Complexity Verification

  See Also:

  • "Managing Resources with Profiles"

  • "Managing Oracle Users"

  • Oracle Database SQL Reference for syntax and specific information about SQL statements discussed in this section

CREATE PROFILE prof LIMIT
    FAILED_LOGIN_ATTEMPTS 4
    PASSWORD_LOCK_TIME 30;
ALTER USER johndoe PROFILE prof;

ALTER USER johndoe ACCOUNT UNLOCK;

ALTER USER susan ACCOUNT LOCK;

Password Aging and Expiration

Use the CREATE PROFILE statement to specify a maximum lifetime for passwords. When the specified amount of time passes and the password expires, the user or DBA must change the password. The following statements create and assign a profile to user johndoe, and the PASSWORD_LIFE_TIME clause specifies that johndoe can use the same password for 90 days before it expires.

CREATE PROFILE prof LIMIT
   FAILED_LOGIN_ATTEMPTS 4
   PASSWORD_LOCK_TIME 30
   PASSWORD_LIFE_TIME 90;
ALTER USER johndoe PROFILE prof;

You can also specify a grace period for password expiration. Users enter the grace period upon the first attempt to log in to a database account after their password has expired. During the grace period, a warning message appears each time users try to log in to their accounts, and continues to appear until the grace period expires. Users must change the password within the grace period. If the password is not changed within the grace period, then users are prompted for a new password each time an attempt is made to access their accounts. Access to an account is denied until a new password is supplied.

Figure 7-2 shows the chronology of the password lifetime and grace period.

Figure 7-2 Chronology of Password Lifetime and Grace Period

Description of "Figure 7-2 Chronology of Password Lifetime and Grace Period"

In the following example, the profile assigned to johndoe includes the specification of a grace period: PASSWORD_GRACE_TIME = 3. The first time johndoe tries to log in to the database after 90 days (this can be any day after the 90th day, that is, the 70th day, 100th day, or another day), he receives a warning message that his password will expire in three days. If three days pass, and he does not change her password, then the password expires. After this, he receives a prompt to change his password on any attempt to log in, and cannot log in until he does so.

CREATE PROFILE prof LIMIT
   FAILED_LOGIN_ATTEMPTS 4
   PASSWORD_LOCK_TIME 30
   PASSWORD_LIFE_TIME 90
   PASSWORD_GRACE_TIME 3;
ALTER USER johndoe PROFILE prof;

Oracle provides a means of explicitly expiring a password. The CREATE USER and ALTER USER statements provide this functionality. The following statement creates a user with an expired password. This setting forces the user to change the password before the user can log in to the database.

CREATE USER jbrown 
     IDENTIFIED BY zX83yT
     ...
     PASSWORD EXPIRE;

routine_name 
(
userid_parameter IN VARCHAR(30),
password_parameter IN VARCHAR (30),
old_password_parameter IN VARCHAR (30)
)
RETURN BOOLEAN

CREATE/ALTER PROFILE profile_name LIMIT
PASSWORD_VERIFY_FUNCTION routine_name

CREATE OR REPLACE FUNCTION verify_function 
(username varchar2, 
   password varchar2, 
   old_password varchar2) 
   RETURN boolean IS  
   n boolean; 
   m integer; 
   differ integer; 
   isdigit boolean; 
   ischar  boolean; 
   ispunct boolean; 
   digitarray varchar2(20); 
   punctarray varchar2(25); 
   chararray varchar2(52); 

BEGIN  
   digitarray:= '0123456789'; 
   chararray:= 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; 
   punctarray:='!"#$%&()''*+,-/:;<=>?_'; 

--Check if the password is same as the username 
IF password = username THEN 
   raise_application_error(-20001, 'Password same as user'); 
END IF; 

--Check for the minimum length of the password 
IF length(password) < 4 THEN 
   raise_application_error(-20002, 'Password length less than 4'); 
END IF; 

--Check if the password is too simple. A dictionary of words may be 
--maintained and a check may be made so as not to allow the words 
--that are too simple for the password.
IF NLS_LOWER(password) IN ('welcome', 'database', 'account', 'user', 
   'password', 'oracle', 'computer', 'abcd') 
   THEN raise_application_error(-20002, 'Password too simple');
END IF; 

--Check if the password contains at least one letter,
--one digit and one punctuation mark. 
--1. Check for the digit 
--You may delete 1. and replace with 2. or 3.
isdigit:=FALSE; 
m := length(password); 
FOR i IN 1..10 LOOP  
  FOR j IN 1..m LOOP  
    IF substr(password,j,1) = substr(digitarray,i,1) THEN 
      isdigit:=TRUE; 
        GOTO findchar; 
    END IF; 
   END LOOP; 
END LOOP; 
IF isdigit = FALSE THEN 
  raise_application_error(-20003, 'Password should contain at least one \
  digit, one character and one punctuation'); 
END IF; 
--2. Check for the character 

<<findchar>> 
ischar:=FALSE; 
FOR i IN 1..length(chararray) LOOP  
  FOR j IN 1..m LOOP  
    IF substr(password,j,1) = substr(chararray,i,1) THEN 
       ischar:=TRUE; 
         GOTO findpunct; 
       END IF; 
    END LOOP; 
END LOOP; 
IF ischar = FALSE THEN 
  raise_application_error(-20003, 'Password should contain at least one digit,\
    one character and one punctuation'); 
END IF; 
--3. Check for the punctuation 

<<findpunct>> 
ispunct:=FALSE; 
FOR i IN 1..length(punctarray) LOOP  
  FOR j IN 1..m LOOP  
    IF substr(password,j,1) = substr(punctarray,i,1) THEN 
       ispunct:=TRUE; 
         GOTO endsearch; 
       END IF; 
   END LOOP; 
END LOOP; 
IF ispunct = FALSE THEN raise_application_error(-20003, 'Password should \
 contain at least one digit, one character and one punctuation'); 
END IF; 

<<endsearch>> 
--Check if the password differs from the previous password by at least 3 letters 
IF old_password = '' THEN 
  raise_application_error(-20004, 'Old password is null');
END IF; 
--Everything is fine; return TRUE ;    
differ := length(old_password) - length(password); 
IF abs(differ) < 3 THEN 
  IF length(password) < length(old_password) THEN 
    m := length(password); 
  ELSE 
    m:= length(old_password); 
  END IF; 
  differ := abs(differ); 
  FOR i IN 1..m LOOP 
    IF substr(password,i,1) != substr(old_password,i,1) THEN 
             differ := differ + 1; 
    END IF; 
  END LOOP; 
  IF differ < 3 THEN 
    raise_application_error(-20004, 'Password should differ by at \ 
      least 3 characters'); 
    END IF; 
  END IF; 
--Everything is fine; return TRUE ;    
  RETURN(TRUE); 
END; 

Auditing Policy

Security administrators should define a policy for the auditing procedures of each database. You may, for example, decide to have database auditing disabled unless questionable activities are suspected. When auditing is required, the security administrator must decide what level of detail to audit the database; usually, general system auditing is followed by more specific types of auditing after the origins of suspicious activity are determined. In addition to standard database auditing, Oracle Database supports fine-grained auditing using policies that can monitor multiple specific objects, columns, and statements, including INDEX.

A Security Checklist

Information security and privacy and protection of corporate assets and data are of pivotal importance in any business. Oracle Database comprehensively addresses the need for information security by offering cutting-edge security features such as deep data protection, auditing, scalable security, secure hosting and data exchange.

The Oracle Database server leads the industry in security. However, in order to fully maximize the security features offered by Oracle Database in any business environment, it is imperative that the database itself be well-protected. Furthermore, proper use of its security features and adherence to basic security practices will help protect against database-related threats and attacks. Such an approach provides a much more secure operating environment for Oracle Database.

This security checklist provides guidance on configuring Oracle Database in a secure manner by adhering to and recommending industry-standard and advisable "security practices" for operational database deployments.

Before looking at the more detailed checklist: consider all paths the data travels and assess the threats that impinge on each path and node. Then, take steps to lessen or eliminate both the threats and the consequences of a successful breach of security. Monitoring and auditing to detect either increased threat levels or successful penetration increases the likelihood of preventing and minimizing security losses.

Details on specific database-related tasks and actions can be found throughout the Oracle documentation set.

The following security checklist includes guidelines that help secure your database:

1. Install only what is required.

   Options and Products

   The Oracle Database CD pack contains a host of options and products in addition to the database server. Install additional products and options only as necessary. Use Custom Installation to avoid installing unnecessary products or, perform a typical installation, and then deinstall unrequired options and products. There is no need to maintain additional products and options if they are not being used. They can always be properly and easily reinstalled as required.

   Sample Schemas

   Oracle Corporation provides Sample Schemas to provide a common platform for examples. If your database will be used in a production environment, then do not install the Sample Schema. If you have installed the Sample Schema on a test database, then before going production, remove or relock the Sample Schema accounts.

2. Lock and expire default user accounts.

   Oracle Database installs with a number of default (preset) database server user accounts. Upon successful installation of the database server, the Database Configuration Assistant automatically locks and expires most default database user accounts.

   If a manual (without using Database Configuration Assistant) installation of Oracle Database is performed, then no default database users are locked upon successful installation of the database server. Left open in their default states, these user accounts can be exploited to gain unauthorized access to data or disrupt database operations.

   Therefore, after performing any kind of initial installation that does not use the Database Configuration Assistant, you should lock and expire all default database user accounts. Oracle Database provides SQL statements to perform such operations.

   Installing additional products and components later also results in creating more default database server accounts. Database Configuration Assistant automatically locks and expires all additionally created database server user accounts. Unlock only those accounts that need to be accessed on a regular basis and assign a strong, meaningful password to each of these unlocked accounts. Oracle provides SQL and password management to perform such operations.

   Table 7-2 shows the database users after a typical Oracle Database installation using Database Configuration Assistant.

   Table 7-2 Default Accounts and Their Status (Standard Installation)

   Username	Account Status
   ANONYMOUS	EXPIRED & LOCKED
   CTXSYS	EXPIRED & LOCKED
   DBSNMP	EXPIRED & LOCKED
   DIP	EXPIRED & LOCKED
   DMSYS	EXPIRED & LOCKED
   EXFSYS	EXPIRED & LOCKED
   HR	EXPIRED & LOCKED
   MDDATA	EXPIRED & LOCKED
   MDSYS	EXPIRED & LOCKED
   MGMT_VIEW	EXPIRED & LOCKED
   ODM	EXPIRED & LOCKED
   ODM_MTR	EXPIRED & LOCKED
   OE	EXPIRED & LOCKED
   OLAPSYS	EXPIRED & LOCKED
   ORDPLUGINS	EXPIRED & LOCKED
   ORDSYS	EXPIRED & LOCKED
   OUTLN	EXPIRED & LOCKED
   PM	EXPIRED & LOCKED
   QS	EXPIRED & LOCKED
   QS_ADM	EXPIRED & LOCKED
   QS_CB	EXPIRED & LOCKED
   QS_CBADM	EXPIRED & LOCKED
   QS_CS	EXPIRED & LOCKED
   QS_ES	EXPIRED & LOCKED
   QS_OS	EXPIRED & LOCKED
   QS_WS	EXPIRED & LOCKED
   RMAN	EXPIRED & LOCKED
   SCOTT	EXPIRED & LOCKED
   SH	EXPIRED & LOCKED
   SI_INFORMTN_SCHEMA	EXPIRED & LOCKED
   SYS	OPEN
   SYSMAN	EXPIRED & LOCKED
   SYSTEM	OPEN
   TSMSYS	EXPIRED & LOCKED
   WK_TEST	EXPIRED & LOCKED
   WKPROXY	EXPIRED & LOCKED
   WKSYS	EXPIRED & LOCKED
   WMSYS	EXPIRED & LOCKED
   XDB	EXPIRED & LOCKED

   
   

   If any default database server user account other than the ones left open is required for any reason, then a database administrator (DBA) need simply unlock and activate that account with a new, secure password.

   Enterprise Manager Accounts

   The preceding list of accounts depends on whether you choose to install Enterprise Manager. If so, SYSMAN and DBSNMP are open as well, unless you configure Enterprise Manager for Central Administration. In this case, the SYSMAN account (if present) will be locked as well.

   If you do not install Enterprise Manager, then only SYS and SYSTEM are open. Database Configuration Assistant locks and expires all other accounts (including SYSMAN and DBSNMP).

3. Change default user passwords.

   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. The following guidelines are recommended:

   1. Change default passwords of administrative users.

      Oracle Database 10g enables you to use the same or different passwords for the SYS, SYSTEM, SYSMAN and DBSNMP administrative accounts. Use different passwords for each: in any Oracle environment (production or test), assign strong, secure, and distinct passwords to these administrative accounts. If Database Configuration Assistant is used, then it requires you to enter passwords for the SYS and SYSTEM accounts, disallowing the use of the defaults CHANGE_ON_INSTALL and MANAGER.

      Similarly, for production environments, do not use default passwords for any administrative accounts, including SYSMAN and DBSNMP.

      At the end of database creation, Database Configuration Assistant displays a page requiring you to enter and confirm new passwords for the SYS and SYSTEM user accounts.

   2. Change default passwords of all users.

      In Oracle Database, SCOTT no longer installs with default password TIGER, but instead is locked and expired, as is DBSNMP. Each of the other accounts install with a default password that is exactly the same as that user account (For example, user MDSYS installs with the password MDSYS).

      If any of the default user accounts that were locked and expired upon installation need to be activated, then assign a new secure password to each such user account.

      Even though Oracle does not explicitly mandate changing the default password for the user SCOTT, Oracle recommends that this user account also be locked in a production environment.

   3. Enforce password management.

      Oracle recommends that basic password management rules (such as password length, history, complexity, and so forth) as provided by the database be applied to all user passwords and that all users be required to change their passwords periodically.

      Oracle also recommends, if possible, using Oracle Advanced Security (an option to the Enterprise Edition of Oracle Database) with network authentication services (such as Kerberos), token cards, smart cards or X.509 certificates. These services enable strong authentication of users to provide better protection against unauthorized access to Oracle Database.

4. Enable data dictionary protection.

   Oracle recommends that customers implement data dictionary protection to prevent users having the ANY system privileges from using such privileges on the data dictionary.

   To enable dictionary protection, set the following configuration parameter to FALSE, in the init<sid>.ora control file:

   O7_DICTIONARY_ACCESSIBILITY = FALSE
   

   By doing so, only those authorized users making DBA-privileged (for example CONNECT / AS SYSDBA) connections can use the ANY system privilege on the data dictionary. If O7_DICTIONARY_ACCESSIBILITY is not set to FALSE, then any user with a DROP ANY TABLE (for example) system privilege will be able to maliciously drop parts of the data dictionary.

   However, if a user needs view access to the data dictionary, then it is permissible to grant that user the SELECT ANY DICTIONARY system privilege.

   Notes:

   • Regarding O7_DICTIONARY_ACCESSIBILITY, note that in Oracle Database, the default is FALSE. However, in Oracle8i, this parameter is set to TRUE by default and must specifically be changed to FALSE to enable this security feature.

   • Regarding the SELECT ANY DICTIONARY privilege: this privilege is not included in the GRANT ALL PRIVILEGES statement, but it can be granted through a role.

5. Practice the principle of least privilege.

   The following guidelines are recommended:

   1. Grant necessary privileges only.

      Do not provide database users more privileges than are necessary. In other words, the principle of least privilege is that users be given only those privileges that are actually required to efficiently perform their jobs.

      To implement this principle, restrict the following as much as possible:

      1) The number of SYSTEM and OBJECT privileges granted to database users, and

      2) The number of people who are allowed to make SYS-privileged connections to the database.

      For example, there is generally no need to grant CREATE ANY TABLE to any non-DBA-privileged user.

   2. Revoke unnecessary privileges from the PUBLIC role.

      Revoke all unnecessary privileges and roles from the role PUBLIC. PUBLIC acts as a default role granted to every user in an Oracle database. Any database user can exercise privileges that are granted to PUBLIC. Such privileges include EXECUTE on various PL/SQL packages, potentially enabling a minimally-privileged user to access and execute functions that he would not otherwise be permitted to access directly. The more powerful packages that may potentially be misused are listed in the following table:

      Package or Subtype	Description
      DBMS_RANDOM	This package can be used to encrypt stored data. Generally, most users should not have the privilege to encrypt data since encrypted data may be non-recoverable if the keys are not securely generated, stored, and managed.
      HTTPURITYPE1	This subprogram is a subtype of the UriType that provides support for the HTTP protocol. It uses the UTL_HTTP package underneath to access the HTTP URLs. Proxy and secure wallets are not supported in this release. Downgrade grants on HTTPURITYPE to the minimum needed in your environment, or revoke all grants if none of your applications need it.
      UTL_HTTP1	This package allows the database server to request andretrieve data using HTTP.
      UTL_INADDR1	This package allows arbitrary domain name resolution to be performed from the database server. Granting this package to the PUBLIC role may permit unauthorized domain name resolution.
      UTL_SMTPFoot 1	This package permits arbitrary mail messages to be sent from one arbitrary user to another arbitrary user. Granting this package to the PUBLIC role may permit unauthorized exchange of mail messages.
      UTL_TCP1	This package permits outgoing network connections to be established by the database server to any receiving (or waiting) network service. Granting this package to PUBLIC may permit arbitrary data may to be sent between the database server and any waiting network service.

      
      

      ^Footnote 1 These packages and subtype should be revoked from PUBLIC and made executable for an application only when absolutely necessary.

      These packages are extremely useful to the applications that need them. They require proper configuration and usage for safe and secure operation, and may not be suitable for most applications.

      For applications that need these packages, create roles with EXECUTE privilege on the particular packages needed and assign those roles only to applications that specifically need to use them. Oracle intends to revoke such privileges from PUBLIC in subsequent releases.

   3. Grant a role to users only if they need all privileges of the role.

      Roles (groups of privileges) are useful for quickly and easily granting permissions to users. Although you can use Oracle-defined roles, you have more control and continuity if you create your own roles containing only the privileges pertaining to your requirements. Oracle may change or remove the privileges in an Oracle-defined role, as it has with CONNECT, which now has only the CREATE SESSION privilege. Formerly this role had eight other privileges. Both CONNECT and RESOURCE roles will be deprecated in future Oracle versions.

      Ensure that the roles you define contain only the privileges that reflect job responsibility. If your application users do not need all the privileges encompassed by an existing role, then apply a different set of roles that supply just the right privileges. Alternatively, create and assign a more restricted role.

      For example, it is imperative to strictly limit the privileges of SCOTT. Drop the CREATE DBLINK privilege for SCOTT. Then drop the entire role for the user, because privileges acquired by means of a role cannot be dropped individually. Recreate your own role with only the privileges needed, and grant that new role to that user. Similarly, for even better security, drop the CREATE DBLINK privilege from all users who do not require it.

   4. Restrict permissions on run-time facilities.

      Do not assign all permissions to any database server run-time facility such as the Oracle Java Virtual Machine (OJVM). Grant specific permissions to the explicit document root file paths for such facilities that may execute files and packages outside the database server.

      Here is an example of a vulnerable run-time call:

      call dbms_java.grant_permission('SCOTT', 'SYS:java.io.FilePermission','<<ALL FILES>>','read');
      

      Here is an example of a better (more secure) run-time call:

      call dbms_java.grant_permission('SCOTT', 'SYS:java.io.FilePermission','<<actual directory path>>','read');
      

6. Enforce access controls effectively and authenticate clients stringently.

   Authenticate clients properly.

   By default, Oracle allows operating-system-authenticated logins only over secure connections, which precludes using Oracle Net and a shared server configuration. This default restriction prevents a remote user from impersonating another operating system user over a network connection.

   Setting the initialization parameter REMOTE_OS_AUTHENT to TRUE forces the RDBMS to accept the client operating system user name received over a nonsecure connection and use it for account access. Since clients, such as PCs, are not trusted to perform operating system authentication properly, it is very poor security practice to turn on this feature.

   The default setting, REMOTE_OS_AUTHENT = FALSE, creates a more secure configuration that enforces proper, server-based authentication of clients connecting to an Oracle database.

   You should not alter the default setting of the REMOTE_OS_AUTHENT initialization parameter, which is FALSE.

   Setting this parameter to FALSE does not mean that users cannot connect remotely. It simply means that the database will not trust that the client has already authenticated, and will therefore apply its standard authentication processes.

7. Restrict operating system access.

   Limit the number of operating system users. Limit the privileges of the operating system accounts (administrative, root-privileged or DBA) on the Oracle Database host (physical machine) to the least privileges needed for the user's tasks.

   Oracle also recommends:

   • Restricting the ability to modify the default file and directory permissions for the Oracle Database home (installation) directory or its contents. Even privileged operating system users and the Oracle owner should not modify these permissions, unless instructed otherwise by Oracle.

   • Restricting symbolic links. Ensure that when providing a path or file to the database, neither the file nor any part of the path is modifiable by an untrusted user. The file and all components of the path should be owned by the DBA or some trusted account, such as root.

     This recommendation applies to all types of files: data files, log files, trace files, external tables, bfiles, and so on.

8. Restrict network access.

   The following guidelines are recommended:

   1. Use a firewall.

      Keep the database server behind a firewall. Oracle Database network infrastructure, Oracle Net (formerly known as Net8 and SQL*Net), offers support for a variety of firewalls from various vendors. Supported proxy-enabled firewalls include' Gauntlet from Network Associates and Raptor from Axent . Supported packet-filtering firewalls include PIX Firewall from Cisco, and supported stateful inspection firewalls (more sophisticated packet-filtered firewalls) include Firewall-1 from CheckPoint .

   2. Never poke a hole through a firewall.

      If Oracle Database is behind a firewall, then do not, under any circumstances, poke a hole through the firewall. For example, do not leave open port 1521 for Oracle Listener to make a connection to the Internet or vice versa.

      Doing this will introduce a number of significant security vulnerabilities including more port openings through the firewall, multi-threaded operating system server issues, and revelation of crucial information on databases behind the firewall. Furthermore, an Oracle Listener running without an established password may be probed for critical details about the databases on which it is listening such as trace and logging information, banner information and database descriptors and service names.

      All this information and the availability of an ill-configured firewall will provide an attacker ample opportunity to launch malicious attacks on the target databases.

   3. Protect the Oracle listener.

      Because the listener acts as the database gateway to the network, it is important to limit the consequences of malicious interference:

      • Restrict the privileges of the listener, so that it cannot read or write files in the database or the Oracle server address space.

        This restriction prevents external procedure agents spawned by the listener (or procedures executed by such an agent) from inheriting the ability to do such reads or writes. The owner of this separate listener process should not be the owner that installed Oracle or executes the Oracle instance (such as ORACLE, the default owner).

        Sample configuration:

        EXTPROC_LISTENER=
          (DESCRIPTION=
            (ADDRESS=
              (PROTOCOL=ipc)(KEY=extproc)))
        SID_LIST_EXTPROC_LISTENER=
          (SID_LIST=
            (SID_DESC=
              (SID_NAME=plsextproc)
              (ORACLE_HOME=/u1/app/oracle/9.0)
              (PROGRAM=extproc)))
        

      • Secure administration of the database by doing the following:

        i. Prevent online administration by requiring the administrator to have write privileges on the LISTENER.ORA file and the listener password:

        Add or alter this line in the LISTENER.ORA file

        ADMIN_RESTRICTIONS_LISTENER=ON
        

        Then RELOAD the configuration.

        ii. Use SSL when administering the listener, by making the TCPS protocol the first entry in the address list as follows:

        LISTENER=
          (DESCRIPTION=
            (ADDRESS_LIST=
              (ADDRESS=
                (PROTOCOL=tcps)
                (HOST = ed-pdsun1.us.oracle.com)
                (PORT = 8281)))
        

        To administer the listener remotely, you need to define the listener in the listener.ora file on the client computer. For example, to access listener USER281 remotely, use the following configuration:

        user281 =
          (DESCRIPTION =
            (ADDRESS =
              (PROTOCOL = tcps)
              (HOST = ed-pdsun1.us.oracle.com)
              (PORT = 8281))
            )
          )
        

        iii. Always establish a secure, well-formed password for the Oracle listener to prevent remote configuration of the Oracle listener. Password protect the listener as follows:

        LSNRCTL> CHANGE_PASSWORD
        Old password: lsnrc80
        New password: lsnrc90
        Reenter new password: lsnrc90
        LSNRCTL> SET PASSWORD
        Password:
        The command completed successfully
        LSNRCTL> SAVE_CONFIG
        The command completed successfully
        

      • Remove the external procedure configuration from the listener.ora file if you do not intend to use such procedures.

      • Monitor listener activity.

   4. Monitor who accesses your systems.

      Authenticating client computers over the Internet is problematic. Do user authentication instead, which avoids client system issues that include falsified IP addresses, hacked operating systems or applications, and falsified or stolen client system identities. The following steps improve client computer security:

      • Configure the connection to use SSL. Using SSL (Secure Sockets Layer) communication makes eavesdropping unfruitful and enables the use of certificates for user and server authentication.

      • Set up certificate authentication for clients and servers such that:

        i. The organization is identified by unit and certificate issuer and the user is identified by distinguished name and certificate issuer.

        ii. Applications test for expired certificates.

        iii. Certificate revocation lists are audited.

   5. Check network IP addresses.

      Use the Oracle Net valid node checking security feature to allow or deny access to Oracle server processes from network clients with specified IP addresses. To use this feature, set the following protocol.ora (Oracle Net configuration file) parameters:

      tcp.validnode_checking = YES
      
      tcp.excluded_nodes = {list of IP addresses}
      
      tcp.invited_nodes = {list of IP addresses}
      

      The first parameter turns on the feature whereas the latter parameters respectively deny and allow specific client IP addresses from making connections to the Oracle listener (This helps in preventing potential Denial of Service attacks).

   6. Encrypt network traffic.

      If possible, use Oracle Advanced Security to encrypt network traffic between clients, databases, and application servers.

      Note:

      Oracle Advanced Security is available only with the Enterprise Edition of the Oracle database. It installs in Typical Installation mode and can be configured, after licensing, with the Oracle Net Manager tool or by manually setting six sqlnet.ora parameters to enable network encryption.

   7. Harden the operating system.

      Harden the host operating system by disabling all unnecessary operating system services. Both UNIX and Windows platforms provide a variety of operating system services, most of which are not necessary for most deployments. Such services include FTP, TFTP, TELNET, and so forth. Be sure to close both the UDP and TCP ports for each service that is being disabled. Disabling one type of port and not the other does not make the operating system more secure.

9. Apply all security patches and workarounds.

   Always apply all relevant and current security patches for both the operating system on which Oracle Database resides and Oracle Database itself, and for all installed Oracle Database options and components.

   Periodically check the security site on Oracle Technology Network for details on security alerts released by Oracle Corporation at

   http://www.oracle.com/technetwork/topics/security/alerts-086861.html
   

   Also check Oracle Worldwide Support Service site, My Oracle Support, for details on available and upcoming security-related patches at

   https://support.oracle.com
   

10. Contact Oracle Security Products if you come across a vulnerability in Oracle Database.

    If you believe that you have found a security vulnerability in Oracle Database, then submit an iTAR to Oracle Worldwide Support Services using My Oracle Support, or e-mail a complete description of the problem, including product version and platform, together with any exploit scripts and examples to the following address:

    secalert_us@oracle.com