Skip Headers

Oracle® Database Security Guide
10g Release 1 (10.1)

Part Number B10773-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page

Go to previous page
Go to next page
View PDF

Security Checklists and Recommendations

This chapter gives you a broad overview of the many types of tasks you must confront in order to build good security. Understanding the diverse categories of such tasks improves your likelihood of preventing security gaps. Such gaps, whether exploited accidentally or intentionally, can undermine or overwhelm otherwise tight security that you have created in other areas.

Chapter 1 introduced the requirements for good security, the threats against it, and concepts that have proven useful in creating practical methods for developing and sustaining it.

The overview presented here, in this chapter, identifies categories of tasks useful in meeting those requirements and threats. This chapter presents brief descriptions of these categories and tasks, with cross-references to Parts 2 and 3, where the important details necessary to their implementation are described.

Good security requires physical access control, reliable personnel, trustworthy installation and configuration procedures, secure communications, and control of database operations such as selection, viewing, updating, or deleting database records. Since some of these requirements involve applications or stored procedures as well as human action, security procedures must also account for how these programs are developed and dealt with.

Practical concerns must also be met: minimizing the costs of equipment, personnel, and training; minimizing delays and errors; and maximizing rapid and thorough accountability. Scalability, too, is an important and independent practical criterion that should be assessed for each proposed solution.

These, then, are the categories with which this overview is concerned. They are discussed in the following sections:

Physical Access Control Checklist

It shouldn't be easy to walk into your facility without a key or badge, or without being required to show identity or authorization. Controlling physical access is your first line of defense, protecting your data (and your staff) against the simplest of inadvertent or malicious intrusions and interferences.

Lack of such control can make it easier to observe, copy, or steal your other security controls, including internal keys, key codes, badge numbers or badges, and so on. Of course, the security of these measures, too, depends on how alert and security conscious each of your staff is, but physical access control stops a variety of potential problems before they even get started.

Each organization must evaluate its own risks and budget. Elaborate measures may well not be needed, depending on many factors: company size, risk of loss, internal access controls, quantity and frequency of outside visitors, and so on. Preparing for accountability and recovery are additional considerations, possibly prompting alarms or video surveillance of entryways. The visibility of these preparations can also act as deterrence.

Improving your facility's physical access control can add to your security. Make it hard to get in, hard to remain or leave unobserved or unidentified, hard to get at sensitive or secure areas inside, and hard not to leave a trace.

Personnel Checklist

Your staff makes your organization work, well or poorly depending on who they are and how they are managed. Your security is critically dependent on them: first, on how honest and trustworthy they are, and second, on how aware and alert they are to security concerns and considerations. The first issue is a matter of selection, interviewing, observation, and reference checking. Done well, these skills can prevent your hiring people who are (or are likely to become) inappropriate for tasks or environments that depend on establishing and maintaining security. To a very large degree, security depends on individuals: when they get careless, resentful, or larcenous, tight security loosens or disappears. Your other measures won't matter if they are carelessly or deliberately undermined or sabotaged.

The second issue is how aware and alert your staff is to security concerns and considerations. Such consciousness is only partly a matter of background: the environment and training you provide are the most significant influences, given basic honesty and intent to cooperate. When an organization both shows and says that security is important, by establishing and enforcing security procedures and by providing training and bulletins about it, people learn and adapt. The result is better security and safety for them as well as for the organization's data and products.

Secure Installation and Configuration Checklist

Information security, privacy, and protection of corporate assets and data are of critical importance to every business. For databases, establishing a secure configuration is a very strong first line of defense, using industry-standard "best security practices" for operational database deployments. The following list of such practices is deliberately general to remain brief. Additional details for each recommendation as it applies to Oracle Database appear in Chapter 7, "Security Policies". Further specific descriptions of database-related tasks and actions can be found throughout the Oracle documentation set.

Implementing the following ten recommendations provides the basis for a secure configuration:

  1. Install Only What Is Required.

    Do a custom installation. Avoid installing options and products you don't need. Choose to install only those additional products and options, in addition to the database server, that you do clearly need. Or, if you choose to do a "typical" installation instead, improve your security after the installation processes finish, by deinstalling the options and products you don't need.

  2. Lock And Expire Default User Accounts.

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


    If you use Oracle Universal Installer or Database Configuration Assistant, they will prompt for new SYS and SYSTEM passwords, and will not accept the defaults "change_on_install" or "manager", respectively.

    Once the database is installed, lock SYS and SYSTEM as well, and use AS SYSDBA for administrator access. Specify administrative passwords individually.

    This account (AS SYSDBA) tracks the operating system username, maintaining accountability. If you only need access for database startup and shutdown, use AS SYSOPER instead. SYSOPER has fewer administrative privileges than SYS, but enough to perform basic operations such as startup/shutdown, mount, backup, archive, and recover.

    Database Configuration Assistant is not used during a manual installation, so all default database users remain unlocked and able to gain unauthorized access to data or to disrupt database operations. Therefore, after a manual installation, use SQL to lock and expire all default database user accounts except SYS, SYSTEM, SCOTT, and DBSNMP. (Do it to SCOTT, too, unless it is being actively used. Also lock SYS and SYSTEM as described earlier.) If a locked account is later needed, a database administrator can simply unlock and activate that account with a new, meaningful password.

  3. Change Default User Passwords.

    Security is most easily broken when a default database server user account still has a default password even after installation. Three steps fix this:

    1. Change the default passwords of administrative users immediately after installing the database server.

      In any Oracle environment (production or test), assign strong, meaningful passwords to the SYS and SYSTEM user accounts immediately upon successful installation of the database server. Under no circumstances should the passwords for SYS and SYSTEM remain in their default states. Similarly, for production environments, do not use default passwords for any administrative accounts, including SYSMAN and DBSNMP.

    2. Change the default passwords of all users immediately after installation.

      Lock and expire all default accounts after installation. If any such account is later activated, change its default password to a new meaningful password.

    3. Enforce password management.

      Apply basic password management rules, such as password length, history, and complexity, to all user passwords.

      Require all users to change their passwords regularly, such as every eight weeks.

      If possible, use 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 provide strong user authentication and enable better protection against unauthorized access.

  4. Enable Data Dictionary Protection.

    Implement data dictionary protection to prevent users who have the ANY system privilege from using it on the data dictionary. Oracle Database sets the O7_DICTIONARY_ACCESSIBILITY to FALSE. This setting prevents using the ANY system privilege on the data dictionary, except for authorized users making DBA-privileged connections (for example CONNECT/AS SYSDBA).

  5. Practice The Principle Of Least Privilege.

    Three practices implement this principle:

    1. Grant necessary privileges only.

      Do not provide database users more privileges than necessary. Enable only those privileges actually required to perform necessary jobs efficiently:

      1) Restrict the number of system and object privileges granted to database users, and

      2) Restrict 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 and roles from the database server user group PUBLIC.

      This default role, granted to every user in an Oracle database, enables unrestricted use of its privileges, such as EXECUTE on various PL/SQL packages. If unnecessary privileges and roles are not revoked from PUBLIC, a minimally privileged user could access and execute packages otherwise inaccessible to him. The more powerful packages that may potentially be misused are listed in Chapter 7, "Security Policies".

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

      Instead, grant specific permissions to the explicit document root file paths for such facilities that may execute files and packages outside the database server. Examples are listed in Chapter 7, "Security Policies".

  6. Enforce Access Controls Effectively.

    Authenticate clients properly.

    Although remote authentication can be turned on (TRUE), your installation is more secure with it off (FALSE, which is the default). With remote authentication turned on, the database implicitly trusts every client, because it assumes every client was authenticated by the remote authenticating system. However, clients in general (such as remote PCs) cannot be trusted to perform proper operating system authentication, so turning on this feature is a very poor security practice. To enforce proper server-based authentication of clients connecting to an Oracle database, leave or turn this feature off (remote_os_authentication=FALSE, which is the default).

  7. Restrict Operating System Access.

    Four practices implement appropriate restrictions on operating system access:

    1. Limit the number of operating system users.
    2. Limit the privileges of the operating system accounts (administrative, root-privileged or DBA) on the Oracle Database host (physical machine) to the fewest and least powerful privileges required for each user.
    3. Disallow modifying the default permissions for the Oracle Database home (installation) directory or its contents, even by privileged operating system users or the Oracle owner.
    4. Restrict symbolic links. Ensure that when any path or file to the database is provided, neither that file nor any part of that 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.

    (See Networking Security Checklists later in this chapter for appropriate practices.)

  9. Apply All Security Patches And Workarounds.

    Plug every security hole or flaw as soon as corrective action is identified. Always apply all relevant and current security patches for both the host operating system 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:

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

    If you believe that you have found a security vulnerability in Oracle Database, 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: 

Networking Security Checklists

Security for network communications is improved by using client, listener, and network checklists to create thoroughgoing protection. Using SSL (Secure Sockets Layer) is an essential element in these lists, enabling top security for authentication and communications.

SSL (Secure Sockets Layer) Checklist

SSL is the Internet standard protocol for secure communication, providing mechanisms for data integrity and data encryption. These mechanisms can protect the messages sent and received by you or by applications and servers, supporting secure authentication, authorization, and messaging by means of certificates and, if necessary, encryption. Good security practices maximize all these protections and minimize gaps or disclosures that threaten them. While the primary documentation for Oracle's SSL configuration and practices is Oracle Advanced Security Administrator's Guide, the following basic list illustrates the cautious attention to detail necessary for successful, secure use of SSL:

  1. Ensure that configuration files (such as for clients and listeners) use the correct port for SSL, which is the port configured upon installation. You can run HTTPS on any port, but the standards specify port 443, where any HTTPS-compliant browser looks by default. Or the port can be specified in the URL, for example, (for port 4445): https://secure.server.dom:4445/
    If a firewall is in use, it too must use the same port(s) for secure (SSL) communication.
  2. Ensure that tcps is specified as the PROTOCOL in the ADDRESS parameter in the tnsnames.ora file (typically on the client or in the LDAP directory). The identical specification must appear in the listener.ora file (typically in the $ORACLE_HOME/network/admin directory).
  3. Ensure that the SSL mode is consistent for both ends of every communication. For example, between the database on one side and the user or application on the other. The mode can specify that there be client or server authentication only (one-way), both client and server authentication (two-way), or no authentication.
  4. Ensure that the server supports the client cipher suites and the certificate key algorithm that will be in use.
  5. Do not remove the encryption from your RSA private key inside your server.key file, which requires that you enter your pass-phrase to read and parse this file. (A non-SSL-aware server does not require such a phrase.) However, if you were to decide your server is secure enough, you could remove the encryption from the RSA private key while preserving the original file. This would enable system boot scripts to start the server, because no pass-phrase would be needed. However, be very sure that permissions on the server.key file allow only root or the web server user to read it. Ideally, restrict permissions to root alone, and have the web server start as root but run as another server. Otherwise, anyone who gets this key can impersonate you on the net.

    See Also:

Client Checklist

Since authenticating client computers is problematic over the Internet, user authentication is typically done instead. This approach avoids client system issues that include falsified IP addresses, hacked operating systems or applications, and falsified or stolen client system identities. Nevertheless, the following steps improve the security of client connections:

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

  2. Set up certificate authentication for clients and servers.

Listener Checklist

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

  1. 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 sepasrate listener process should not be the owner that installed Oracle or executes the Oracle instance (such as ORACLE, the default owner).

  2. Secure administration by the following four steps:

    See Also:

    See the section A Security Checklist in Chapter 7, "Security Policies", for more specific details.

    1. Password protect the listener.
    2. Prevent on-line administration.
    3. Use SSL when administering the listener.
    4. Remove the external procedure configuration from the listener.ora file if you do not intend to use such procedures.
  3. Monitor listener activity.

Network Checklist

Protecting the network and its traffic from inappropriate access or modification is the essence of network security. The following practices improve network security:

  1. Restrict physical access to the network. Make it hard to attach devices for listening to, interfering with, or creating communications.
  2. Protect the network access points from unauthorized access. This goal includes protecting the network-related software on the computers, bridges, and routers used in communication.
  3. Since you cannot protect physical addresses when transferring data over the Internet, use encryption when this data needs to be secure.
  4. Use firewalls.

    Appropriately placed and configured firewalls can prevent outsider access to your organization's intranet when you allow internal users to have Internet access.

    • Keep the database server behind a firewall. Oracle Database's network infrastructure supports a variety of firewalls from various vendors; examples are listed in Chapter 7, "Security Policies".
    • Ensure that the firewall is placed outside the network to be protected.
    • Configure the firewall to accept only those protocols, applications, or client/server sources that you know are safe.
    • Use a product like Oracle Connection Manager to multiplex multiple client network sessions through a single network connection to the database. It can filter on source, destination, and host name. This functionality enables you to ensure that connections are accepted only from physically secure terminals or from application Web servers with known IP addresses. (Filtering on IP address alone is not enough for authentication, because it can be faked.)
  5. Never poke a hole through a firewall.

    For example, do not leave open Oracle Listener's 1521 port, allowing the database to connect to the Internet or the Internet to connect with the database. Such a hole introduces significant security vulnerabilities that hackers are likely to exploit. They can enable even more port openings through the firewall, create multi-threaded operating system server problems, and gain access to crucial information on databases behind the firewall. If the Listener is running without an established password, they can probe for critical details about the databases on which it is listening. These details include trace and logging information, banner information, and database descriptors and service names, enabling malicious and damaging attacks on the target databases.

  6. 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. Further, prevent unauthorized administration of the Oracle Listener, as described in Chapter 7, "Security Policies".

  7. 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. Set parameters in the protocol.ora file (Oracle Net configuration file) to specify client IP addresses respectively denied or allowed connections to the Oracle Listener. This action prevents potential Denial of Service attacks.

  8. 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).

  9. Harden the host operating system (the system on which Oracle Database resides).

    Disable all unnecessary operating system services. Many UNIX and Windows services are not necessary for most deployments. Such services include FTP, TFTP, TELNET, and so forth.

    For each disabled service, be sure to close both the UDP and TCP ports. Leaving either type of port enabled leaves the operating system vulnerable.

In summary, consider all paths the data travels and assess the threats that impinge on each path and node. Then take steps to lessen or eliminate those threats and the consequences of a successful breach of security. Also monitor and audit to detect either increased threat levels or successful penetration.