Oracle Database Listener Security Guide

STEP 1 – SET THE LISTENER PASSWORD
Set the Listener password to stop most attacks and security issues. This is usually a simple process. You should set the password using lsnrctl, which will encrypt the password stored in listener.ora. Setting the password manually in listener.ora using the PASSWORDS_ parameter will result in the password being stored in cleartext.
LSNRCTL> set current_listener
LSNRCTL> change_password
Old password:
New password:
Reenter new password:
LSNRCTL> set password
Password:
LSNRCTL> save_config
Check the listener.ora file to see if there is now a parameter PASSWORDS_. It is important to remember that the actual encrypted password can be used in place of the actual password prior to Oracle 10g.

STEP 2 – TURN ON LOGGING [MANDATORY]
Turn on logging for all listeners in order to capture Listener commands and brute force password attacks.
LSNRCTL> set current_listener
LSNRCTL> set password
Password:
LSNRCTL> set log_directory /network/admin
LSNRCTL> set log_file .log
LSNRCTL> set log_status on
LSNRCTL> save_config

STEP 3 – SET ADMIN_RESTRICTIONS IN LISTENER.ORA [MANDATORY]

All runtime modifications to the Listener can be disabled by setting the parameter ADMIN_RESTRICTIONS_ to ON in the listener.ora file. This parameter stops all set commands from being executed either locally or remotely. All changes must be made manually to the listener.ora file.

LISTENER.ORA
ADMIN_RESTRICTIONS_ = ON

Restart the listener using the reload command in lsnrctl for this change to take effect. Any future changes must be made in the listener.ora file, not using set commands in lsnrctl. After making any changes to the listener.ora file, use the reload command (or stop and start) in lsnrctl.

if Local OS Authentication is disabled also It must be set for 10g listener otherwise there is no need .

STEP 4 – APPLY LISTENER SECURITY PATCHES [MANDATORY]
Apply at least the January 2006 Critical Patch Update for the latest Listener security patches (as of March 2007). Critical Patch Updates are cumulative, therefore, the latest patch will contain all previous security patches for the Listener.

STEP 5 – BLOCK SQL*NET ON FIREWALLS
SQL*Net traffic should not be allowed to pass through firewalls unless absolutely necessary. Firewall filters should be designed to only allow SQL*Net traffic from known application and web servers. SQL*Net traffic from application servers in the DMZ should be permitted only to access specific database servers.

Few applications require direct SQL*Net connections to a database from the Internet. SQL*Net performs poorly over high latency networks, thus is seldom used in Internet applications. If applications do require direct SQL*Net access, configure firewall filters based on a specific host and port number.

STEP 6 – SECURE THE $TNS_ADMIN DIRECTORY [MANDATORY]

The Listener password is stored in the listener.ora file. Manually editing the file, the password can easily be removed or changed. If the password was manually added to the file, it is stored in clear text. When added through lsnrctl, it will be stored as an encrypted string.

The permissions on the listener.ora, sqlnet.ora, and protocol.ora files in the $TNS_ADMIN directory (usually $ORACLE_HOME/network/admin) should be read/write/execute for only the primary oracle account and no permissions for any other account (for UNIX and Linux 0600). The tnsnames.ora file permissions should be set to 0644 on UNIX and Linux.

chmod 644 $ORACLE_HOME/network/admin/tnsnames.ora
chmod 600 $ORACLE_HOME/network/admin


STEP 7 – SECURE TNSLSNR AND LSNRCTL [OPTIONAL]
The tnslsnr and lsnrctl executables in the $ORACLE_HOME/bin directory should be protected and file permissions should be set to 0751 on UNIX and Linux as recommended by Oracle. It is possible to change the file permissions to 0700 which would be more secure, although this should be thoroughly tested in your environment.

chmod 700 $ORACLE_HOME/bin/tnslsnr
chmod 700 $ORACLE_HOME/bin/lsnrctl


STEP 8 – REMOVE UNUSED SERVICES [MANDATORY]
Many default installations have a listener entry for PL/SQL External Procedures (ExtProc). The entry name is usually ExtProc or PLSExtProc. Often ExtProc is installed by default, but is not used. Check with your application development team or application documentation to determine if ExtProc is used.
If ExtProc is not used, remove it from the listener.ora file. There are several exploits directed at ExtProc.
Since listener.ora files are sometimes copied between instances, they may contain old and unused entries. Check all the other services to determine if they are used. Delete any services not actively used.

STEP 9 – CHANGE THE TNS PORT NUMBER FROM 1521 [OPTIONAL]
In order to help stop automated attacks and detection of the Listener in networks, the default NTS port number should be changed from 1521 to a port outside of the 1521-1550 and 1600-1699 ranges. This will provide only minimal additional security through obscurity, but may thwart an automated attack or simply scanning for Oracle Databases on port 1521.

The port number can be changed using Oracle Net Manager (netmgr) or editing the listener.ora file directly. All tnsnames.ora files on the database server and any clients must be updated to reflect the change in the port number. The database initialization parameter LOCAL_LISTENER must be set so that the database is able to dynamically register with the Listener. See Metalink Note ID 359277.1 "Changing Default Listener Port Number" for more information.

STEP 10 – SETUP VALID NODE CHECKING [OPTIONAL]

Depending on the type of application and network configuration, valid node checking can be a powerful tool to restrict most traffic from the Listener. Most web applications only require access to the Listener from the application servers and a limited number of clients for administration.

The simplest method to determine valid IP addresses for node checking is through database auditing. We recommended you always have session level auditing enabled.
For Oracle 9i/10g, the valid node checking lines are added to the $ORACLE_HOME/network/admin/sqlnet.ora file. For Oracle 8/8i, the lines are added to the $ORACLE_HOME/network/admin/protocol.ora file.

tcp.validnode_checking = yes
tcp.invited_nodes = (x.x.x.x name, x.x.x.x name)
tcp.excluded_nodes=( x.x.x.x name, x.x.x.x name)

Include either the invited_nodes or excluded_nodes, but do not use both. Wildcards, subnets, etc. are not valid, only individual IP addresses or host names are allowed. For more sophisticated checking, use Oracle Connection Manager.

The Listener must be stopped and started for valid node checking to become active. There is no hard limit on the number of nodes that can be included, but for a large number of entries using Oracle Connection Manager may be a better solution. If many clients require direct SQL*Net access to the database, it is often difficult to use valid node checking due to constantly changing network configurations.


STEP 11 – MONITOR THE LOGFILE [OPTIONAL]

The logfile in Step 2 may contain TNS-01169, TNS-01189, TNS-01190, or TNS-12508 errors, which may signify attacks or inappropriate activity. Using a simple shell script or management tools, monitor the logfile and generate an alert whenever these errors reaches are encountered.