Skip Headers
Oracle® Database Security Guide
10g Release 2 (10.2)

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
Contact Us

Go to previous page
Go to next page
PDF · Mobi · ePub

2 Security Checklists and Recommendations

This chapter gives you a broad overview of the many types of tasks you must perform in order to build good security. Understanding the diverse categories of tasks improves your likelihood of preventing security vulnerabilities. Such vulnerabilities, 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 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 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 selecting, 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.

The following practical concerns must also be met:

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 should not be easy to walk into a facility without a key or badge, or without being required to show identity or authorization. Controlling physical access is your first line of defense, by 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. The security of these measures also depends on how alert and security conscious each of your staff is, but physical access control stops a variety of potential problems.

Each organization must evaluate its own risks and budget. Elaborate measures may 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 physical access control to your facility can add to your security. Make it difficult to get in, difficult to remain or leave unobserved or unidentified, difficult to get at sensitive or secure areas inside, and difficult not to leave a trace.

Personnel Checklist

Your staff makes your organization work well, 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 personnel get careless, resentful, or larcenous, tight security loosens or disappears. Your other measures will not 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, and 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 data and products of an organization.

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

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

Networking Security Checklists

Security for network communications is improved by using client, listener, and network checklists to ensure thorough protection. Using SSL is an essential element in these lists, enabling top security for authentication and communications.

SSL 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 protection and minimize gaps or disclosures that threaten security. While the primary documentation for Oracle SSL configuration and practices is Oracle Database Advanced Security Administrator's Guide, the following list illustrates the cautious attention to detail necessary for the successful 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,

    If a firewall is in use, then 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). An 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 either client or server authentication (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 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 pass 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 user. Otherwise, anyone who gets this key can impersonate you on the net.

Client Checklist

Because authenticating client computers is problematic over the Internet, typically, user authentication is performed 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:

  • Configure the connection to use SSL.

    Using SSL communication makes eavesdropping difficult and enables the use of certificates for user and server authentication.

  • Set up certificate authentication for clients and servers.

Listener Checklist

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

  • Secure administration by doing the following:

    • Protect the listener with a password.

    • Prevent online administration.

    • Use SSL when administering the listener.

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

      See Also:

      See the section A Security Checklist in Chapter 7, "Security Policies", for more specific details.
  • 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 difficult 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. Because 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 intranet when you allow internal users to have Internet access.

    • Keep the database server behind a firewall. The Oracle Database 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 the Oracle Listener port 1521 open, allowing the database to connect to the Internet or the Internet to connect with the database. This could introduce significant security vulnerabilities that hackers are likely to exploit. Hackers could enable even more port openings through the firewall, create multithreaded operating system server problems, and enable access to crucial information on databases behind the firewall. If the Listener is running without a password, then hackers 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 that are 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.


    Oracle Advanced Security is available only with the Enterprise Edition of 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 breach of security. In addition, monitor and audit to detect either increased threat levels or successful penetration.