Securing the Network

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:

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

• 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:

• It is a critical program and needs to be run much of the time.

• 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 you’re 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.