Securing Oracle Network Traffic

Securing Oracle Network Traffic

Roger Schrag
Database Specialists, Inc.
http://www.dbspecialists.com

Introduction

Oracle offers a platform-independent networking infrastructure for accessing databases and related services in a distributed environment. Historically this product was called SQL*Net, but today it is called Net8. The two names are synonymous. Net8 allows applications running on one host to access an Oracle database running on a separate host. It also allows multiple Oracle databases to participate in distributed queries and transactions. The fact that multiple hosts are involved can be made completely transparent to the application.

Oracle’s networking infrastructure follows a client/server computing model. A Net8 listener runs on every host running an Oracle database or other related services that may need to be accessed from remote hosts. When a client application or an Oracle database acting as a client needs to access a database on a remote host, the client establishes a connection with the Net8 listener running on the remote host. The Net8 listener then refers the client directly to the service. Once negotiation is complete, the Net8 listener steps out of the path and the client application communicates directly with the database or other service provider.

Many interesting questions and challenges arise when the path between the client and the database is an insecure network, such as the internet. Consider the situation where a database administrator, or DBA, wants to run database monitoring tools from home. Or the situation where databases at separate co-location sites do not have a secure network between them.

This paper discusses Net8 and network security. It identifies some of the features of Oracle’s Advanced Security offering, and the challenges of using Oracle networking over an insecure network such as the internet. This paper also presents the following detailed, technical How-Tos:

How-To #1: Configuring the Net8 listener to accept or refuse requests from specific IP addresses
How-To #2: Using ssh (Secure Shell protocol) to make Net8 more secure and optionally tunnel through firewalls

Oracle Net8 And security

Net8 can work with many standard networking protocols, such as TCP/IP, SPX, and DECnet. Net8 also supports heterogeneous networks, and can handle protocol interchanges in a way transparent to client applications. With Net8 as the backbone of communication in a networked environment, just about every Oracle implementation uses Net8.

“Advanced Security” is the name of a package of enhancements available for Net8. In the past this product was called Advanced Networking Option. Without Advanced Security, Net8 is not very secure. Application data is transferred between nodes in clear text, and there is no mechanism for detecting if a network packet was intercepted and altered while in transit. (Oracle Corporation states that database passwords are encrypted when transmitted by Net8, but the encryption method is not disclosed in the documentation.)

Net8’s limitations can have significant implications for security and privacy. Consider an application that must retrieve sensitive financial information from a remote database. If the network between the application host and the database server were to be compromised, an outsider with a packet sniffer would be able to intercept the Net8 traffic and view the sensitive financial information. Even worse, an outsider might be able to alter the data while en route from the database server to the application.

Without Advanced Security, the Net8 listener also has very limited filtering capabilities. By default, the Net8 listener will accept any request coming in on the listener port, regardless of who is making the request. With certain networking protocols, Net8 can be configured to offer some limited filtering capabilities. For example, when Net8 is used on a TCP/IP network, the Net8 listener can be configured to accept or refuse requests coming from an enumerated list of IP addresses. However, this is a little known feature, and it can be awkward to implement.

With Advanced Security, any client requesting a connection can specify a list of encryption methods it can support (in order of preference) and whether encryption is required, requested, accepted, or refused. Each Net8 listener can do likewise. When a client initiates a new connection, it negotiates with the Net8 listener to decide whether encryption should be used and, if so, which method of encryption should be used. If either party requires encryption but the other party refuses encryption or the two parties cannot agree on an encryption method, then the connection fails.

A few examples of the encryption negotiation phase with Net8 and Advanced Security are as follows:

A client that requests encryption and supports RSA RC4 at the 56 or 40 bit level attempts to access a server that requires RSA RC4 encryption at the 128 or 56 bit level. The connection will succeed and RSA RC4 56 bit encryption will be used.
A client that requests encryption and supports RSA RC4 at the 56 or 40 bit level attempts to access a server that requests encryption and supports only DES 56 and 40 bit encryption. The connection will succeed and no encryption will be used. This is because the two parties could not agree on an encryption method and neither party required encryption.
A client that refuses encryption attempts to access a server that requires encryption and supports RSA RC4 at the 128, 56, or 40 bit level. The connection will fail because one party requires encryption and the other refuses.
A client that accepts encryption and supports DES 40 bit attempts to access a server that requires encryption and supports only DES 56 bit. The connection will fail because one party requires encryption and the two parties cannot agree on an encryption method.

Advanced Security also enables application clients and Net8 listeners to state a preference on data checksumming, in a scheme similar to encryption discussed above. This facilitates safeguarding against data interception and alteration. In addition, Advanced Security enables the database to authenticate users in ways other than the typical username and password combination. For example, Kerberos, SecurID, or biometric devices can be used for database user authentication when Advanced Security has been implemented.

It is important to note that the Advanced Security package is an extra cost option available only for the Enterprise Edition of the Oracle database. This means that if you are using Oracle 8i Standard Edition, Net8 will transmit your data in clear text, passwords will be encrypted in an undisclosed way, and you will not be able to employ data checksumming or special user authentication schemes. If you are using Oracle 8i Enterprise Edition, you can purchase Advanced Security for an additional licensing fee in order to get the features discussed here.

The Challenges Posed by an Insecure Network

The term “insecure network” is extremely subjective. A dot-com internet startup company might be comfortable sending Net8 traffic between two databases over the internet. Meanwhile, a commercial bank might not be comfortable sending unencrypted Net8 traffic between a database server and an application server in the same room, even if both sit behind a firewall.

Regardless of what level of security you are comfortable with for your system, achieving that level of security can make database connectivity a challenge. If you put your database server behind a firewall, you might make it hard to access the database in an emergency from a remote location. If you install Advanced Security on your database server and configure your Net8 listener to require encryption, then all application servers and other Net8 clients will need to have Advanced Security as well.

Security requirements can also impose a monetary challenge when it comes to Oracle licensing. If you are using Oracle 8i Standard Edition and you wish to encrypt your Net8 traffic, you are looking at about a four-fold increase in licensing fees to move up to Oracle 8i Enterprise Edition. And then the Advanced Security feature is an extra cost option on top of that. If you find yourself in this situation, you will likely ask yourself, “Isn’t there another way to encrypt Net8 traffic?”

Net8 security challenges, and the many possible scenarios, can be boiled down to a few briefly stated technical challenges:

How can you make a Net8 listener accept or refuse requests depending on the IP address of the requestor?
How can you access a remote Oracle database when its Net8 listener sits behind a firewall?
How can you encrypt Net8 traffic and safeguard against data alteration without purchasing Advanced Security?

The first question is easy to answer. All you need to do is edit one configuration file in order to invoke an obscure, little known Net8 feature. The first How-To below explains this in great detail. The remaining two questions above can both be addressed by using the port forwarding capability of the Secure Shell protocol, or ssh. It turns out that ssh and Net8 work quite well together. The second How-To below explains this.

How-To #1: Configuring the Net8 listener to accept or refuse requests from specific IP addresses

When you start a Net8 listener, it reads the listener configuration file once. If you make a change to the listener configuration file, you must restart or reload the Net8 listener in order for the change to take effect. The listener configuration file is called listener.ora and is typically located in the $ORACLE_HOME/network/admin directory.

Multiple Net8 listeners may run on one host. For each, the listener.ora file specifies a listener name, a list of which ports and protocols to listen on, and a list of databases or other services available. By default, the Net8 listener will attempt to service any request that comes in on the port that is being listened to. But if you are using the TCP/IP protocol, then you can actually give Net8 a list of IP addresses from which requests should be accepted or ignored.

To enable this feature, create a file called protocol.ora in the same directory as the listener.ora file. The contents of the file should be as follows:

tcp.validnode_checking=yes
tcp.invited_nodes=(address1, address2, ...)
tcp.excluded_nodes=(address1, address2, ...)

Lists of nodes to invite (accept requests from) or exclude (ignore requests from) may be as long as you like. The lists can span multiple lines in the protocol.ora file. The addresses themselves can be host names or numeric IP addresses. Unfortunately, you cannot specify ranges of IP addresses or network masks. Typically, you just provide a list of invited nodes (meaning all others should be excluded) or a list of excluded nodes (meaning all others should be invited).

Once you have created the protocol.ora file, simply restart or reload the Net8 listener. This will cause the changes you have made to the protocol.ora file to take effect. Any request coming from an excluded node (or not included on the list of invited nodes) will be ignored.

How-To #2: Using ssh (Secure Shell protocol) to make Net8 more secure and optionally tunnel through firewalls

The Secure Shell protocol, or ssh, allows you to remotely access a Unix host in a manner similar to the telnet protocol. The key difference is that all network traffic is encrypted and checksummed to ensure privacy and data integrity. ssh server and client software is readily available for Unix platforms such as Solaris, Linux, and HP-UX. You can purchase and download ssh software from http://www.ssh.com. A very popular ssh client for Windows is called SecureCRT. You can purchase and download SecureCRT from Van Dyke Technologies at http://www.vandyke.com.

The ssh protocol includes a provision for port forwarding. This allows you to secure network traffic for a protocol that is usually not secure. Although typically used to secure X11 or POP3 traffic, the port forwarding facility of ssh works very well for securing Net8 traffic. We’ll show exactly how to do this with three examples.

Example #1: Securing Net8 traffic between a Unix or Linux application server and a database server

Suppose you want all Net8 traffic between your Unix/Linux application server and your database server to be encrypted. You could open an ssh connection from the application server to the database server with port forwarding. If configured correctly, the ssh client running on the application server will intercept all Net8 traffic emanating from the application server, encrypt it, and transmit it to the ssh daemon running on the database server. The ssh daemon will decrypt the data and forward it to the Net8 listener.

To make this work, you need to configure the tnsnames.ora file on the application server and open the ssh connection from the application server to the database server with port forwarding enabled. Note that you don’t need to change any configurations or do anything special on the database server itself.

Suppose the applications running on the application server need to access the PROD database, and the entry in the tnsnames.ora file for the PROD database looks like this:

PROD.acme.com=
   (DESCRIPTION=
     (ADDRESS_LIST=
       (ADDRESS=(PROTOCOL=TCP)(HOST=dbserver1.acme.com)(PORT=1521))
     )
     (CONNECT_DATA=
       (SERVICE_NAME=PROD.acme.com)
     )
   )

First, edit the tnsnames.ora file on the application server to make it look like this:

PROD.acme.com=
   (DESCRIPTION=
     (ADDRESS_LIST=
       (ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=9901))
     )
     (CONNECT_DATA=
       (SERVICE_NAME=PROD.acme.com)
     )
   )

Now, whenever an application on the application server wishes to connect to the PROD database, a Net8 request will be sent to port 9901 on the application server (instead of the usual port 1521 on the database server). Before starting the application, set up port forwarding by initiating an ssh connection on the application server like this:

ssh -L 9901:dbserver1.acme.com:1521 dbserver1.acme.com

This ssh command line opens an ssh connection to dbserver1.acme.com and also securely forwards all network traffic from port 9901 on the local host to port 1521 on dbserver1.acme.com. Depending on which version of ssh software you have installed, you can configure ssh to authenticate using keys so that the ssh connection can be established without prompting for a password.

After the tnsnames.ora file on the application server has been tweaked and the ssh connection has been established from the application server to the database server, you are ready to start up the application on the application server. When the application attempts to connect to the database, a Net8 request will be sent to port 9901 on the application server. The ssh client on the application server will receive the Net8 request, encrypt it, and transmit it over the ssh connection to the database server dbserver1.acme.com. The ssh daemon running on the database server will receive the encrypted Net8 request, decrypt it, and forward it to port 1521. The Net8 listener running on the database server will now receive the Net8 request from the application and process it in the ordinary way.

In this example we have encrypted Net8 traffic between two Unix machines. The ssh involvement was completely transparent to both the application and the database server. Note that the port number I used on the application server—9901—is arbitrary. You can use any port you want, as long as it does not interfere with other services. If you try to use a privileged port, then you’ll need to establish the ssh connection as the root user.

In this example, the database server was running an ssh daemon. If this were not the case, but another server (we’ll call it shell.acme.com) were running an ssh daemon, we still could have made this work. The only difference would have been the ssh connection initiated from the application server. Instead of connecting to the database server, the ssh connection would go to the server running the ssh daemon. So the ssh command line would look like this:

ssh -L 9901:dbserver1.acme.com:1521 shell.acme.com

In this case the Net8 traffic from the application server would be encrypted by the ssh client running on the application server and forwarded to shell.acme.com. The ssh daemon on shell.acme.com would decrypt the traffic and forward it to the Net8 listener port on the database server. Note that the traffic between shell.acme.com and dbserver1.acme.com would not be encrypted.

Example #2: Securing Net8 between a Windows box and a database server

Suppose you are a database administrator and you get a page in the middle of the night that one of your production databases is sluggish. You have performance monitoring tools installed on your Windows machine at home, and you’d like to run these tools against the production database in order to figure out what is causing the database to respond so slowly.

However, suppose your database server resides on an internal network at your company with a non-routable IP address such as 192.168.1.47. Suppose, though, that there is a server called gateway.acme.com connected to both the internal network and the internet, and that gateway.acme.com accepts ssh connections from the internet.

You can open an ssh connection between your Windows machine and the gateway server at your company, and use this ssh connection to forward Net8 traffic between the performance tools on your Windows machine and the database server on your company’s internal network. The traffic between your Windows machine and the gateway server will be encrypted. Traffic between the gateway server and the database server will not be encrypted, but this traffic will be on your company’s internal network and hopefully the internal network is secure.

First, edit the tnsnames.ora file on your Windows box. Suppose it looks like this:

WEBSALES.acme.com =
   (DESCRIPTION =
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = data7.acme.com)(PORT = 1521))
     )
     (CONNECT_DATA =
       (SERVICE_NAME = WEBSALES.acme.com)
     )
   )

Change the tnsnames.ora file to look like this:

WEBSALES.acme.com =
   (DESCRIPTION =
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 9902))
     )
     (CONNECT_DATA =
       (SERVICE_NAME = WEBSALES.acme.com)
     )
   )

Next, initiate an ssh connection from your Windows machine to gateway.acme.com, with a directive to forward port 9902 from the Windows machine to port 1521 on the database server. If you are using Van Dyke’s SecureCRT, you configure port forwarding by clicking on the Advanced button in the Connection window after you select ssh1 or ssh2 as the protocol. In the Advanced SSH Options window, click on the Port Forwarding tab, and enter the local port, remote hostname, and remote port in order to configure port forwarding. Then connect to gateway.acme.com using the connection you’ve just configured.

Now you can fire up your performance monitoring tools. The tools will think they are connecting directly to the WEBSALES database, even though that database is running on a database server whose IP address is not even routable on the internet. And the portion of the Net8 traffic that is travelling over the internet will be encrypted. Again, the port number I selected—9902 this time—was arbitrary.

Example #3: Tunneling through a firewall

Suppose again that you are a database administrator and you get a page in the middle of the night that one of your databases is having a problem. Again, you have various tools installed on your computer at home, and you’d like to run these tools against the database that is having problems.

This time suppose the database server is accessible from the internet, but a firewall blocks access to the Net8 listener port from the internet. If an ssh daemon is running on the database server and if the ssh port is accessible from the internet, then you can use ssh to tunnel through the firewall.

As in the previous examples, edit the tnsnames.ora file on your local machine in order to direct Net8 traffic to a local unused port. Then initiate an ssh connection to the database server with port forwarding enabled. As in the previous two examples, this will cause the Net8 traffic to travel over an encrypted channel. The key feature to note here is that you will also be steering the Net8 traffic around the blocked Net8 listener port. Instead, the Net8 traffic will be travelling over the ssh port.

Conclusion

Net8, formerly known as SQL*Net, is Oracle’s platform-independent networking infrastructure. The standard version of Net8 is rather insecure, transmitting data in clear text and providing no means for detecting data alteration during transit. Oracle Advanced Security, formerly known as the Advanced Networking Option, is an extra cost feature that provides these security features and more. Advanced Security is only available for Oracle 8i Enterprise Edition, and not for Oracle 8i Standard Edition.

In this paper we discussed the basics of Net8 security and presented specific How-Tos that show you how to improve Net8 security when you are not in a position to purchase or deploy Oracle’s Advanced Security product offering.

About the Author

Roger Schrag has been an Oracle DBA and application architect for over eleven years, starting out at Oracle Corporation on the Oracle Financials development team. He is the founder of Database Specialists, Inc., a consulting group specializing in business solutions based on Oracle technology. You can visit Database Specialists on the web at http://www.dbspecialists.com, and you can reach Roger by calling +1.415.344.0500 or via email at rschrag@dbspecialists.com.