Skip Headers

Oracle9i Database Administrator's Guide
Release 2 (9.2)

Part Number A96521-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

Establishing Security Policies

This chapter provides guidelines for developing security policies for database operation, and contains the following topics:

System Security Policy

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

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, the database administrator may have the responsibilities of the security administrator. However, if the database system is large, 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's security policy should include several sub-policies, as explained in the following sections.

Database User Management

Database users are the access paths to the information in an Oracle database. Therefore, tight security should be maintained for the management of database users. Depending on the size of a database system and the amount of work required to manage database users, the security administrator may be the only user with the privileges required to create, alter, or drop database users. On the other hand, there may be a number of administrators with privileges to manage database users. Regardless, only trusted individuals should have the powerful privileges to administer database users.

User Authentication

Database users can be authenticated (verified as the correct person) by Oracle using database passwords, the host operating system, network services, or by Secure Sockets Layer (SSL).


To be authenticated using network authentication services or SSL, requires that you have installed Oracle Advanced Security. Refer to the Oracle Advanced Security Administrator's Guide for information about these types of authentication.

User authentication and how it is specified is discussed in "User Authentication Methods".

Operating System Security

If applicable, the following security issues must also be considered for the operating system environment executing Oracle and any database applications:

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

Your data security policy is determined primarily by the level of security you want to establish for the data in your database. 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 make a database or security administrator the only person with the privileges 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, 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. Privileges and roles are discussed in Chapter 25, "Managing User Privileges and Roles".

Views can also implement data security because their definition can restrict access to table data. They can exclude columns containing sensitive data. Views are discussed in Chapter 20, "Managing Views, Sequences, and Synonyms".

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 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 a SQL statement, thereby restricting the users 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.

See Also:

The above manuals contain information about implementing fine-grained access control and an application context.

User Security Policy

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

General User Security

For all types of database users, consider the following general user security issues:

Password Security

If user authentication is managed by the database, security administrators should develop a password security policy to maintain database access security. For example, database users should be required to change their passwords at regular intervals, and of course, when their passwords are revealed to others. By forcing a user to modify passwords in such situations, unauthorized database access can be reduced.

To better protect the confidentiality of your password, Oracle can be configured to use encrypted passwords for client/server and server/server connections.


It is strongly recommended that you configure Oracle to encrypt passwords in client/server and server/server connections. Otherwise, a malicious user "snooping" on the network can grab an unencrypted password, and use it to connect to the database as another user, thereby "impersonating" that user.

By setting the following values, you can require that the password used to verify a connection always be encrypted:

If enabled at both the client and server, passwords will not be sent across the network "in the clear", but will be encrypted using a modified DES (Data Encryption Standard) algorithm.

The DBLINK_ENCRYPT_LOGIN initialization parameter is used for connections between two Oracle servers (for example, when performing distributed queries). If you are connecting from a client, Oracle checks the ORA_ENCRYPT_LOGIN environment variable.

Whenever you attempt to connect to a server using a password, Oracle encrypts the password before sending it to the server. If the connection fails and auditing is enabled, the failure is noted in the audit log. Oracle then checks the appropriate DBLINK_ENCRYPT_LOGIN or ORA_ENCRYPT_LOGIN value. If it set to FALSE, Oracle attempts the connection again using an unencrypted version of the password. If the connection is successful, the connection replaces the previous failure in the audit log, and the connection proceeds. To prevent malicious users from forcing Oracle to re-attempt a connection with an unencrypted version of the password, you must set the appropriate values to TRUE.

Privilege Management

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 (which are named 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.

End-User Security

Security administrators must define a policy for end-user security. If a database has many users, 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 accts_receivable and accts_payable database applications. 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_receivable and accts_payable database applications to the accountant role.
  3. Grant each user of the accounting department the accountant role.

This security model is illustrated in Figure 23-1.

Figure 23-1 User Role

Text description of admin003.gif follows
Text description of the illustration admin003.gif

This plan addresses the following potential situations:

Utilize 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 Advanced Security Administrator's Guide for information about this functionality.

Administrator Security

Security administrators should have a policy addressing database administrator security. For example, when the database is large and there are several types of database administrators, the security administrator may decide to group related administrative privileges into several administrative roles. The administrative roles can then be granted to appropriate administrator users. Alternatively, when the database is small and has only a few administrators, it may be more convenient to create one administrative role and grant it to all administrators.

See Also:

Chapter 1, "The Oracle Database Administrator" contains a more thorough discussion of administrator security

Protection for Connections as SYS and SYSTEM

After database creation, and if you used the default passwords for SYS and SYSTEM, immediately change the passwords for the SYS and SYSTEM administrative usernames. Connecting as SYS or SYSTEM gives a user powerful privileges to modify a database. For example, connecting as SYS allows a user to alter data dictionary tables. The privileges associated with these usernames are extremely sensitive, and should only be available to select database administrators.

If you have installed options that have caused other administrative usernames to be created, such username accounts are initially created locked. To unlock these accounts, use the ALTER USER statement. The ALTER USER statement should also be used to change the associated passwords for these accounts.

The passwords for these accounts can be modified using the procedures described in "Altering Users".

Protection for Administrator Connections

Only database administrators should have the capability to connect to a database with administrative privileges. For example:


Connecting as SYSOPER gives a user the ability to perform basic operational tasks (such as STARTUP, SHUTDOWN, and recovery operations). Connecting as SYSDBA gives the user these abilities plus unrestricted privileges to do anything to a database or the objects within a database (including, CREATE, DROP, and DELETE). Connecting as SYSDBA places a user in the SYS schema, where they can alter data dictionary tables.

Using Roles for Administrator Privilege Management

Roles are the easiest way to restrict the powerful system privileges and roles required by personnel administrating the database.

Consider a scenario where the database administrator responsibilities at a large installation are shared among several database administrators, each responsible for the following specific database management jobs:

There are also new, inexperienced database administrators needing limited capabilities to experiment with database management

In this scenario, the security administrator should structure the security for administrative personnel as follows:

  1. Define six roles to contain the distinct privileges required to accomplish each type of job (for example, dba_objects, dba_tune, dba_security, dba_maintain, dba_recov, dba_new).
  2. Grant each role the appropriate privileges.
  3. Grant each type of database administrator the corresponding role.

This plan diminishes the likelihood of future problems in the following ways:

Application Developer Security

Security administrators must define a special security policy for the application developers using a database. A security administrator could grant the privileges to create necessary objects to application developers. Or, alternatively, the privileges to create objects could be granted only to a database administrator, who then receives requests for object creation from developers.

Application Developers and Their Privileges

Database application developers are unique database users who require special groups of privileges to accomplish their jobs. Unlike end users, developers need system privileges, such as CREATE TABLE, CREATE PROCEDURE, and so on. However, only specific system privileges should be granted to developers to restrict their overall capabilities in the database.

The Application Developer's Environment: Test and Production Databases

In many cases, application development is restricted to test databases and is not allowed on production databases. This restriction ensures that application developers do not compete with end users for database resources, and that they cannot detrimentally affect a production database.

After an application has been thoroughly developed and tested, it is permitted access to the production database and made available to the appropriate end users of the production database.

Free Versus Controlled Application Development

The database administrator can define the following options when determining which privileges should be granted to application developers:

Although some database systems use only one of these options, other systems could mix them. For example, application developers can be allowed to create new stored procedures and packages, but not allowed to create tables or indexes. A security administrator's decision regarding this issue should be based on the following:

Roles and Privileges for Application Developers

Security administrators can create roles to manage the privileges required by the typical application developer. For example, a typical role named APPLICATION_DEVELOPER might include the CREATE TABLE, CREATE VIEW, and CREATE PROCEDURE system privileges. Consider the following when defining roles for application developers:

Space Restrictions Imposed on Application Developers

While application developers are typically given the privileges to create objects as part of the development process, security administrators must maintain limits on what and how much database space can be used by each application developer. For example, as the security administrator, you should specifically set or restrict the following limits for each application developer:

Both limitations can be set by altering a developer's security domain. This is discussed in "Altering Users".

Application Administrator Security

In large database systems with many database applications, you might consider assigning application administrators. An application administrator is responsible for the following types of tasks:

Often, an application administrator is also the application developer who designed an application. However, an application administrator could be any individual familiar with the database application.

Password Management Policy

Database security systems that are dependent on passwords require that passwords be kept secret at all times. But, passwords are vulnerable to theft, forgery, and misuse. To allow for greater control over database security, Oracle's password management policy is controlled by DBAs and security officers through user profiles.

You 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 password management:

This section describes the following aspects of Oracle password management:

Account Locking

When a particular user exceeds a designated number of failed login attempts, the server automatically locks that user's account. You specify the permissible number of failed login attempts using the CREATE PROFILE statement. You can also specify the amount of time accounts remain locked.

In the following example, the maximum number of failed login attempts for the user ashwini is four, and the amount of time the account will remain locked is 30 days. The account will unlock automatically after the passage of 30 days.

ALTER USER ashwini PROFILE prof;

If you do not specify a time interval for unlocking the account, PASSWORD_LOCK_TIME assumes the value specified in a default profile. If you specify PASSWORD_LOCK_TIME as UNLIMITED, the account must be explicitly unlocked using an ALTER USER statement. For example, assuming that PASSWORD_LOCK_TIME UNLIMITED is specified for ashwini, then the following statement must be used to unlock the account:


After a user successfully logs into an account, that user's unsuccessful login attempt count, if there is one, is reset to 0.

The security officer can also explicitly lock user accounts. When this occurs, the account cannot be unlocked automatically, and only the security officer should unlock the account. The CREATE USER or ALTER USER statements are used to explicitly lock or unlock user accounts. For example, the following statement locks user account susan:


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 ashwini, and the PASSWORD_LIFE_TIME clause specifies that ashwini can use the same password for 90 days before it expires.

ALTER USER ashwini 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, thereafter 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 23-2 shows the chronology of the password lifetime and grace period.

Figure 23-2 Chronology of Password Lifetime and Grace Period

Text description of admin024.gif follows
Text description of the illustration admin024.gif

In the following example, the profile assigned to ashwini includes the specification of a grace period: PASSWORD_GRACE_TIME = 3. The first time ashwini 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), she receives a warning message that her password will expire in three days. If three days pass, and she does not change her password, the password expires. Thereafter, she receives a prompt to change her password on any attempt to log in, and cannot log in until she does so.

ALTER USER ashwini 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.


Password History

Use the CREATE PROFILE statement to specify a time interval during which users cannot reuse a password. In the following statement, a profile is defined where the PASSWORD_REUSE_TIME clause specifies that the user cannot reuse the password for 60 days.


In the next statement, the PASSWORD_REUSE_MAX clause specifies that the number of password changes the user must make before the current password can be used again is three.



If you specify PASSWORD_REUSE_TIME or PASSWORD_REUSE_MAX, you must set the other to UNLIMITED or not specify it at all.

Password Complexity Verification

Oracle's password complexity verification routine can be specified using a PL/SQL script (UTLPWDMG.SQL), which sets the default profile parameters.

The password complexity verification routine performs the following checks:

Password Verification Routine Formatting Guidelines

You can enhance the existing password verification complexity routine or create other password verification routines using PL/SQL or third-party tools.

The PL/SQL call must adhere to the following format:

userid_parameter IN VARCHAR(30),
password_parameter IN VARCHAR (30),
old_password_parameter IN VARCHAR (30)



The password verify routine must be owned by SYS.

Sample Password Verification Routine

You can use this sample password verification routine as a model when developing your own complexity checks for a new password.

The default password complexity function performs the following minimum complexity checks:

This function must be created in SYS schema, and you must connect SYS/password AS SYSDBA before running the script.

(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); 

   digitarray:= '0123456789'; 
   chararray:= 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; 

--Check if the password is same as the username 
IF password = username THEN 

--Check for the minimum length of the password 
IF length(password) < 4 THEN 

--that are too simple for the password.
   'password', 'oracle', 'computer', 'abcd') 

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

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

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

IF old_password = '' THEN 
--Everything is fine; return TRUE ;    
IF abs(differ) < 3 THEN 
  IF length(password) < length(old_password) THEN 
    m := length(password); 
    m:= length(old_password); 
  END IF; 
  differ := abs(differ); 
  FOR i IN 1..m LOOP 
             differ := differ + 1; 
    END IF; 
  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 ;    

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. Auditing is discussed in Chapter 26, "Auditing Database Use".

A Security Checklist

Information security and privacy and protection of corporate assets and data are of pivotal importance in any business. Oracle9i 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 Oracle9i database server leads the industry in security. However, in order to fully maximize the security features offered by Oracle9i in any business environment, it is imperative that Oracle9i itself is well-protected. Furthermore, proper use of its security features and adherence to basic security practices will help protect against database-related threats and attacks and provide a much more secure operating environment for the Oracle9i database.

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

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


    The Oracle9i CD pack contains a host of options and products in addition to the database server. Install additional products and options only as necessary. Or, following a typical installation (if avoiding a custom installation), deinstall options and products that are not necessary. There is no need to maintain the additional products and options if they are not being used. They can always be properly and easily reinstalled as required.


    Oracle9i installs with a number of default (preset) database server user accounts. The Database Client Administration tool (DBCA) automatically locks and expires all default database user accounts except the following upon successful installation of the database server:

    • SYS
    • SYSTEM
    • SCOTT
    • DBSNMP
    • OUTLN
    • The three JSERV users

    If a manual (not utilizing DBCA) installation of Oracle9i is performed, none of the default database users are locked upon successful installation of the database server. If left open in their default states, these user accounts can be exploited to gain unauthorized access to data or disrupt database operations. Lock and expire all default database user accounts except SYS, SYSTEM, SCOTT, DBSNMP, OUTLN and the three JSERV database users after performing any kind of initial installation that does not utilize DBCA. Oracle9i provides SQL to perform such operations.

    Provided below is the table of database users after a typical Oracle9i installation utilizing DBCA.


































































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


    The most trivial method by which Oracle9i can be compromised is a default database server user account which still has a default password associated with it even after installation.

    1. Change default passwords of administrative users

      In Oracle9i, SYS installs with a default password of CHANGE_ON_INSTALL and SYSTEM installs with a default password of MANAGER. Change the default passwords associated with users SYS and SYSTEM immediately upon installation of the database server.

    2. Change default passwords of all users

      In Oracle9i, SCOTT installs with default password TIGER and the three JSERV accounts (AURORA$JIS$UTILITY$, AURORA$ORB$UNAUTHENTICATED and OSE$HTTP$ADMIN) each install with randomly-generated passwords. 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 password MDSYS).

      Change the passwords for SCOTT, DBSNMP, OUTLN and the three JSERV user accounts immediately upon installation as well. If any of the other default user accounts that were locked and expired upon installation need to be activated, assign a new meaningful password to that user account.

      Even though Oracle does not explicitly mandate changing the default password for user SCOTT, Oracle nevertheless recommends that this user account also be locked unless it is being actively used.

    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, utilizing Oracle Advanced Security (an option to the Enterprise Edition of Oracle9i ) 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 Oracle9i.


    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 O7_DICTIONARY_ACCESSIBILITY initialization parameter, in the following manner:


    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 this parameter is not set to the value recommended above, 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 requires view access to the data dictionary, it is permissible to grant that user the SELECT ANY DICTIONARY system privilege.

    Note that in Oracle9i, O7_DICTIONARY_ACCESSIBILITY = FALSE by default; in Oracle8i, the parameter is set to TRUE by default and must specifically be changed to FALSE to enable this security feature.

    1. Grant necessary privileges only

      Do not provide database users more privileges than are necessary. In other words, principle of least privilege is that a user be given only those privileges that are actually required to efficiently and succinctly perform his or her job.

      To implement least privilege, restrict: 1) the number of SYSTEM and OBJECT privileges granted to database users, and 2) the number of SYS-privileged connections to the database as much as possible. For example, there is generally no need to grant CREATE ANY TABLE to any non DBA-privileged user.

    2. Revoke unnecessary privileges from PUBLIC

      Revoke all unnecessary privileges and roles from the database server user group 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 that may permit a minimally privileged user to access and execute packages that he may not directly be permitted to access. The more powerful packages that may potentially be misused are listed in the following table:

      Package Description


      This package permits arbitrary mail messages to be sent from one arbitrary user to another arbitrary user. Granting this package to PUBLIC may permit unauthorized exchange of mail messages.


      This package permits outgoing network connections to be established by the database server to any receiving (or waiting) network service. Thus, arbitrary data may be sent between the database server and any waiting network service.


      This package allows the database server to request and retrieve data using HTTP. Granting this package to PUBLIC may permit data to be sent using HTML forms to a malicious Web site.


      If configured improperly, this package allows text level access to any file on the host operating system. Even when properly configured, this package does not distinguish between its calling applications with the result that one application with access to UTL_FILE may write arbitrary data into the same location that is written to by another application.


      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.

      These packages are extremely useful to some applications that need them and require proper configuration and usage. These packages may not be suitable for other applications. Thus, unless absolutely necessary, revoke them from PUBLIC.

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

      An example of a vulnerable run-time call:

      call dbms_java.grant_permission('SCOTT', 
      '','<<ALL FILES>>','read');

      An example of a better (more secure) run-time call:

      call dbms_java.grant_permission('SCOTT', 
      '','<<actual directory path>>','read');

    Authenticate clients properly.

    Remote authentication is a security feature provided by Oracle9i such that if turned on (TRUE), it defers authentication of users to the remote client connecting to an Oracle database. Thus, the database implicitly trusts any client to have authenticated itself properly. Note that clients, in general, such as PCs, are not trusted to perform operating system authentication properly and therefore, it is very poor security practice to turn on this feature.

    In a more secure configuration where this feature is turned off (FALSE), it enforces proper, server-based authentication of clients connecting to an Oracle database.

    To restrict remote authentication and thereby defer client trust to the database, set the REMOTE_OS_AUTHENT initialization parameter in the following manner:


    Limit the number of operating system users.

    Limit the privileges of the operating system accounts (administrative, root-privileged or DBA) on the Oracle9i host (physical machine) to the least required for the user.

    Oracle also recommends:

    • Restricting the ability to modify the default file and directory permissions for the Oracle9i 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 Corporation.
    • Ensuring 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, etc.
    1. Utilize a firewall

      Keep the database server behind a firewall. Oracle9i's 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 Network Associates' Gauntlet and Axent's Raptor. Supported packet-filtered firewalls include Cisco's PIX Firewall and supported stateful inspection firewalls (more sophisticated packet-filtered firewalls) include CheckPoint's Firewall-1.

    2. Never poke a hole through a firewall

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

      Doing so 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 database(s) behind the firewall. Furthermore, an Oracle Listener running without an established password may be probed for critical details about the database(s) on which it is listening such as trace and logging information, banner information and database descriptors and service names.

      Such a plethora of information and the availability of an ill-configured firewall will provide an attacker ample opportunity to launch malicious attacks on the target database(s).

    3. Prevent unauthorized administration of the Oracle Listener

      Always establish a meaningful, well-formed password for the Oracle Listener to prevent remote configuration of the Oracle Listener. Additionally, set the listener.ora (Oracle Listener control file) security configuration parameter in the following manner:

      ADMIN_RESTRICTIONS_listener_name = ON

      Doing so will also prevent unauthorized administration of the Oracle Listener.

    4. Check network IP addresses

      Utilize 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 two parameters respectively deny or allow specific client IP addresses from making connections to the Oracle Listener (and thereby preventing potential Denial of Service attacks).

    5. Encrypt network traffic

      If possible, utilize Oracle Advanced Security to encrypt network traffic between clients, databases and application servers. (Note that Oracle Advanced Security is available only with the Enterprise Edition of the Oracle database).

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


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

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

    Also check Oracle Worldwide Support Service's site, Metalink, for details on available and upcoming security-related patches.

    If you believe that you have found a security vulnerability in Oracle9i, submit an iTAR to Oracle Worldwide Support Services using Metalink, 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: 

Go to previous page Go to next page
Copyright © 2001, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index