Home arrow Oracle arrow Page 9 - Securing the Database

Securing the Network - Oracle

If you work with Oracle databases, you will want to know how to secure them. This article focuses on a number of steps you can take, representing the best practices used in organizations today, to secure an Oracle database. It is excerpted from chapter 2 of the book Effective Oracle Database 10g Security by Design, written by David C. Knox (McGraw-Hill/Osborne, 2004; ISBN: 0072231300).

TABLE OF CONTENTS:
  1. Securing the Database
  2. Securing Access to Application Schemas
  3. Throw Out Anything Stale
  4. Checking for Weak or Default Passwords
  5. Impossible Passwords
  6. Password Profiles
  7. Default Roles
  8. Oracle Supplied Objects
  9. Securing the Network
By: McGraw-Hill/Osborne
Rating: starstarstarstarstar / 12
September 22, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

For most databases, security begins even before the users gain access to the database. The network that links together the users, applications, and databases is critical in the security chain. There are a few actions you should take to strengthen this link.

Encryption

Today, some believe that network encryption isn't necessary. After all, antivirus software and firewalls are already in place.

This is wrong. While there is some level of security afforded by these technologies, the assumption that network traffic is totally secure is false. Anyone can place a network packet sniffer (readily available on the Internet) on the application server that connects to the database. Both are behind the firewall. With the sniffer they can easily capture all the traffic to and from the application server. Packets can be spooled to a file. Later, after the important data has been collected, the spool file can be sent via e-mail to an "anonymous" Internet account. This is not fiction; it really happens. Why bother breaking into the database with all its security when you can easily capture all the important data as it enters and leaves the database? This scenario illustrates the need for network encryption.


NOTE

When deploying applications that communicate with an Oracle Database, the Oracle network encryption capabilities provide seamless and transparent encryption of all your database data as it moves through the network. While it may not be needed in all situations, it should always be considered and is strongly recommended.


 

There are three benefits to implementing Oracle's network encryption capabilities:

  1. The algorithm negotiation feature supports the concurrent use of different encryption algorithms with different key sizes for various clients. This flexibility means that security and performance can be accomplished simultaneously.
  2. The encryption remains transparent to the applications that utilize it.
  • Independent lab tests show little overhead costs, which makes it an acceptable trade-off in most cases.

Configuring the network for encryption is simple. Either edit the SQLNET.ORA file with a text editor or use the Oracle Net Manager. A view into the file shows how easy it is to instruct the Oracle network software to secure the channel:

SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA1) SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA1) SQLNET.CRYPTO_SEED =
 
thisistheencryptionseed(S)DLKDk0(*)(*#IUI%$,k9r80dsa0__llk098 09cxf-08 SQLNET.ENCRYPTION_SERVER = requested SQLNET.ENCRYPTION_CLIENT = requested SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256) SQLNET.ENCRYPTION_TYPES_SERVER= (AES256)

Using these settings, the network software will employ the SHA-1 algorithm to ensure data integrity and also will encrypt all data using the AES algorithm with 256-bit key sizes.

Database Listener

The database listener is the process that handles connections over the network destined for the database. Two important points about the listener:

  1. It is a critical program and needs to be run much of the time.
  2. It is the forward application, which means that it stands the biggest risk of attack. User programs can interact with the listener directly even if they don't have database accounts.

As with most network processes, there are numerous attacks that can occur against the database listener. Securing the database listener is a top priority. The first task is to password protect the listener process. Limiting status information is critical to securing the listener since the listener will happily explain everything it knows when prompted. This information is useful to both DBAs and to hackers.

The database listener also comes defaulted to a well-known network port or two. While it's by no stretch of the imagination a "robust" security maneuver, changing the default port is nevertheless a good idea. If the listener is on a different port, someone who is scanning the network for open ports will detect a process listening on that port but may not know what it is. Some hackers only probe for well-known ports because the full port scans are obvious and can set off the intrusion detection alarms.


TIP

Changing the listening ports (and not only from 1521 to 1522) is a best practice.


To configure the listener, either edit the LISTENER.ORA file with a text editor or use the Oracle Net Manager.

External Calls

The database supports a useful capability whereby PL/SQL programs running inside the database can make external calls to a program running on the operating system. The benefit is that the OS programs will either execute faster (because they are C programs optimized to perform a specific task) or pass information about the operating system back into the database (such as uptime, currently executing processes, and logged in users).

However, the external procedure call capability is a high security risk; the process runs with the privileges of the database listener. If the external procedure is successfully compromised, the hacker may find themselves sitting in a privileged shell.

If youre using, or need to use, this capability be sure to keep it in check; otherwise, disable it. To do this, modify the Oracle network configuration files (the PLSExtProc service). Removing the binary that allows this, extproc.exe, is also a good idea.

If you need to support external procedures, it's best to configure the extproc listener to run as an unprivileged user; for example, the "nobody" user on UNIX. By default, the process runs with the privileges of the database listener. By following this configuration suggestion, the risks associated with a compromised external procedure are significantly diminished.

IP Validation

IP addresses are the network method for naming entities. While the actual network protocols function at a lower layer (based on the MAC address), IP addresses remain a valuable identification asset. The main drawback with IP-based security is that it's not too difficult, relative to other tricks such as trying to break encryption, to impersonate another computer's IP Address (spoofing). The ability to successfully spoof depends on the network topology and the abilities of the network administrators to enforce strict IP addresses. Many network intrusion detection systems will alert administrators to duplicate IP addresses on their networks.

Assuming the IP address can be used to accurately identify the client, the IP address can then be incorporated into the database security implementations.

The Oracle database listener can be configured to allow or disallow access based on the client's IP address. This is an easy way to begin shielding your database from unwanted users.

The configuration can again be completed using the Oracle Net Manager. The settings are placed in the SQLNET.ORA file (prior to Oracle9i Database, this was the PROTOCOL.ORA file). For example, the following configuration will only allow a network connection from a single computer with the IP address of 192.168.1.21:

TCP.VALIDNODE_CHECKING = YES TCP.INVITED_NODES= (192.168.1.21)

If your security policy dictates that the database only should be accessed from the application server, which has the previous IP address, these two lines can be added to your SQLNET.ORA file to ensure the database listener process will not accept any other connection requests. You can alternatively specify which specific nodes you want to exclude by setting the TCP.EXCLUDED_ NODES value.

Using the valid node checking capability is a good practice because it helps ensure that the only connections coming in over the network are from computers that are authorized.

Summary

Building secure database applications is done on the assumption that the database is already operating securely. To ensure this happens, you often have to perform certain tasks to create a tighter security implementation. There are many important lessons in this chapter.

Securing database schemas means ensuring not only new schemas are created and managed properly but also that the default schemas are secured. The default schemas and their passwords are well known. There are several ways to prevent unwanted and unauthorized users from connecting to these well known and highly privileged accounts. Several techniques were shown for applying the defense in depth principle.

An understanding of Oracle's use of passwords is necessary because password authentication represents the most common authentication mechanism to the database. The database supports both password complexity routines and password profiles to support the secure and proper use of passwords.

Oracle's default roles exist today for legacy reasons and should rarely be used, and revoking existing privileges and limiting grants to the user group PUBLIC is essential for securing the database.

A final necessary piece of the security puzzle is network security. The entire security of an application and database can be subverted through poor network security. The database provides several ways to prevent this from happening. Applying security at the network tier ensures all the links in the security chain are strong.



 
 
>>> More Oracle Articles          >>> More By McGraw-Hill/Osborne
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

ORACLE ARTICLES

- Oracle Java Security Woes Continue
- Oracle's New IaaS Cloud Option: There's a Ca...
- Oracle Acquires Eloqua to Boost Cloud Presen...
- Choosing Innovation: Oracle Survey Insights
- Oracle Fixes Privilege Escalation Bug
- Oracle`s Communications Service Availability...
- Oracle Releases Exalytics, Taleo Plans
- Oracle Releases Communications Network Integ...
- Oracle Releases Communications Data Model 11...
- Oracle Releases PeopleSoft PeopleTools 8.52
- Oracle Integrates Cloudera Apache Distro, My...
- Oracle Releases MySQL 5.5.18
- Oracle Announces NoSQL Database Availability
- Sorting Database Columns With the SELECT Sta...
- Retrieving Table Data with the LIKE Operator

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: