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.
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:
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 =
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:
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.
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.
To configure the listener, either edit the LISTENER.ORA file with a text editor or use the Oracle Net Manager.
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.
blog comments powered by Disqus