Pete Finnigan's Oracle Security Weblog

I saw an interesting post last week on the Oracle-L list titled "ye olde 1521" where the poster asked if the well held assumption about the way communications with Oracle are true. This is where a user connects via port 1521 (or any other port used by the listener) and when a connection is established an Oracle background process is spawned and communication is then handed off to the spawned process. This spawned process then establishes communication on a new random port with the client. The poster using RedHat AS3 sniffed the net packets and found that this is not true, all communications took place using port 1521. He used a dedicated server connection.

This is a very interesting issue for those interested in Oracle security. There are a few reasons why, firewalls for one, having random ports opened by the shadow processes makes it difficult to control access to and from the database through a firewall. The other main reason we should be interested in this is in the understanding of how Oracle works especially in the area of network connections and data flows.

Amit replied and said that this is only the case for Windows using the winsock API and for Unix all communications go through port 1521. This is because the listener forks and the socket remains intact over the fork process - Tanel will clarify this in a minute.

Wolfgang chipped in that it depends on platform and some IP configuration parameters and confirms that the reasons for the change are due to the Internet and firewalls and the need to not punch lots of holes through the firewall.

Tanel finally came in with a superb post describing the whole situation. Basically its called direct handoff and either the listener could spawn a new process and that process would continue the communication with the client. This is called hand-off. Or the listener would reply to the client with an IP address and port number of where the new server process was for the client to continue its communications. The main problem, Tanel confirms was firewalls that Oracle customers needed to use had to be SQL*Net compliant and use the Oracle proxy code to sniff the new port and open it.

An interesting point made by Tanel is that fork() is not used for the direct handoff as the listener and oracle binaries are based on different executable images.

Also a great snippet of information is the quote about the listener.ora parameter DIRECT_HANDOFF_TTC_{listener_name} which can be set to ON or OFF that can be used to turn on or off direct handoff. Also Tanel suggests that direct handoff should work with shared servers.

This is great information.