The Oracle Database Listener is the database server software component that manages the network traffic between the Oracle Database and the client. The Oracle Database Listener listens on a specific network port (default 1521) and forwards network connections to the Database. One of the most misunderstood security issues with the Oracle Database is the security of the Listener.

The listener is one of the most critical components to database operations;

It is responsible for the ability to have a client/server communication
In dedicated mode it is responsible for creating a new process (or thread on Windows) on behalf of the client and setting up the communications
On Windows each such server process actually speaks on a new tcpip port and the listener redirects the client to this port
On Unix streaming continues on the original port

The listener forks a new process
The listener then closes its own fd-s; the new process continues to speak on the fd-s

In MTS the listener is responsible to assign and set up the connection with the least loaded dispatcher. The dispatchers get requests from the client and place them on the request queues for the shared server processes, and read responses from the response queues to send to the client

Security attacks

A denial-of-service attack (DoS attack) - bring the listener down. Activating a malicious OS command through the listener. Getting sensitive data through the listener.

Oracle Security Alert for CVE-2012-1675

This security alert addresses the security issue CVE-2012-1675, a vulnerability in the TNS listener which has been recently disclosed as "TNS Listener Poison Attack" affecting the Oracle Database Server. This vulnerability may be remotely exploitable without authentication, i.e. it may be exploited over a network without the need for a username and password. A remote user can exploit this vulnerability to impact the confidentiality, integrity and availability of systems that do not have recommended solution applied.

Affected Products and Versions

Oracle Database 11g Release 2, versions 11.2.0.2, 11.2.0.3
Oracle Database 11g Release 1, version 11.1.0.7
Oracle Database 10g Release 2, versions 10.2.0.3, 10.2.0.4, 10.2.0.5

Solution for Oracle Security Alert for CVE-2012-1675

My Oracle Support Note 1340831.1 for Oracle Database deployments that use Oracle Real Application Clusters (RAC).
My Oracle Support Note 1453883.1 for Oracle Database deployments that do not use RAC.

Note RAC environments: Please note that Oracle has added Oracle Advanced Security SSL/TLS to the Oracle Database Standard Edition license when used with the Real Application Clusters and Oracle has added Oracle Advanced Security SSL/TLS to the Enterprise Edition Real Application Clusters (Oracle RAC) and RAC One Node options so that the directions provided in the Support Notes referenced above can be applied by all Oracle customers without additional cost.

Note: Please refer to the Oracle licensing documentation available on Oracle.com regarding licensing changes that allow Oracle Advanced Security SSL/TLS to be used with Oracle SE Oracle Real Application Clusters and Oracle Enterprise Edition Real Application Customers (Oracle RAC) and Oracle RAC OneNode Options

Secure the Oracle Listener in 14 steps.

DISABLING THE DEFAULT LISTENER
SET THE LISTENER PASSWORD
TURN ON LISTENER LOGGING
SET ADMIN_RESTRICTIONS IN THE LISTENER.ORA
SET LOCAL_OS_AUTHENTICATION IN THE LISTENER.ORA
SET PROTECTION AGAINS CRAFTED NETWORK PACKETS ON DATABASE LEVEL IN 11G.
APPLY LISTENER SECURITY PATCHES
BLOCK SQL*NET ON FIREWALLS
SECURE THE $TNS_ADMIN DIRECTORY
SECURE TNSLSNR AND LSNRCTL EXECUTABLES
REMOVE UNUSED SERVICES
CHANGE THE TNS PORT NUMBER DEFAULT
SETUP VALID NODE CHECKING
MONITOR THE LOGFILE

Step 1 - Disabling the Default Listener

Al listeners have a name instead the name LISTENER and has a startup protection.

LISTENER=(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST=)(PORT = 0)))

This configuration prevents the default listener from starting. The error serves as a reminder to set TNS_ADMIN, if necessary, and to supply the correct listener name to the lsnrctl command.

$ lsnrctl start
  …
  Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=0)))
  TNS-01103: Protocol specific component of the address is incorrectly specified
  TNS-12533: TNS:illegal ADDRESS parameters
  TNS-12560: TNS:protocol adapter error
  TNS-00503: Illegal ADDRESS parameters

Step 2 - Set the Listener Password

Set the Listener password to stop most attacks and security issues. 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

Remark
Before 10g you could authenticate to the listener either using the password or the password hash (!!)

Fixed in 10g. Password hash is stored in listener.ora – so anyone with read permission could then authenticate over the network. It is like storing the password in clear text

Step 3 - Turn on Logging

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 4 - Set ADMIN_RESTRICTIONS in the listener.ora

With ADMIN_RESTRICTIONS_listener=on, the listener rejects SET commands that might have been sent
from an intruder on a remote system. It only allows changes through lsnrctl reload on the local system LISTENER.ORA.

ADMIN_RESTRICTIONS_ = ON

Step 5 - Set LOCAL_OS_AUTHENTICATION in the listener.ora

By default, the Listener cannot be remotely managed and can only be managed locally by the owner of the tnslsnr process (usually oracle) since Oracle 10G.

LOCAL_OS_AUTHENTICATION_ = ON

Step 6 - Set Protection agains crafted network packets on database level in 11g.

SEC_PROTOCOL_ERROR_TRACE_ACTION:

SEC_PROTOCOL_ERROR_TRACE_ACTION specifies the action that the database should take when bad packets are received from a possibly malicious client.

SEC_PROTOCOL_ERROR_TRACE_ACTION = { NONE | TRACE | LOG | ALERT }

NONE : The database server ignores the bad packets and does not generate any trace files or log messages.
TRACE : A detailed trace file is generated when bad packets are received, which can be used to debug any problems in client/server communication.
LOG : A minimal log message is printed in the alert logfile and in the server trace file. A minimal amount of disk space is used.
ALERT : An alert message is sent to a DBA or monitoring console.

SEC_PROTOCOL_ERROR_FURTHER_ACTION

SEC_PROTOCOL_ERROR_FURTHER_ACTION specifies the further execution of a server process when receiving bad packets from a possibly malicious client.

SEC_PROTOCOL_ERROR_FURTHER_ACTION = { CONTINUE | (DELAY,integer) | (DROP,integer) }

CONTINUE : The server process continues execution. The database server may be subject to a Denial of Service (DoS) if bad packets continue to be sent by a malicious client.
(DELAY,integer) :The client experiences a delay of integer seconds before the server process accepts the next request from the same client connection. Malicious clients are prevented from excessive consumption of server resources while legitimate clients experience a degradation in performance but can continue to function.
(DROP,integer) : The server forcefully terminates the client connection after integer bad packets. The server protects itself at the expense of the client (for example, a client transaction may be lost). The client may reconnect and attempt the same operation.

SEC_MAX_FAILED_LOGIN_ATTEMPTS

SEC_MAX_FAILED_LOGIN_ATTEMPTS specifies the number of authentication attempts that can be made by a client on a connection to the server process. After the specified number of failure attempts, the connection will be automatically dropped by the server process.

SEC_MAX_FAILED_LOGIN_ATTEMPTS = n (10 is the default)

Values ranges 1 to unlimited

Step 7 - Apply Listener Security Patches

Critical Patch Updates are cumulative, therefore, the latest patch will contain all previous security patches for the Listener.

Step 8 - Block SQL*Net on Firewalls

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.

Step 9 - Secure the $TNS_ADMIN Directory

Place the listener.ora, sqlnet.ora, and protocol.ora files in the $TNS_ADMIN directory.
It 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.

Step 10 - Secure TNSLSNR and LSNRCTL executables

The executables tnslsnr and lsnrctl in the $ORACLE_HOME/bin should be protected. set the file permissions 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.

Step 11 - Remove Unused Services

Default installations have a listener entry for PL/SQL External Procedures (ExtProc or PLSExtProc) and databases with default services. Remove the Unused services from database or listsner.

Step 12 - Change the TNS Port Number Default (1521)

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

Step 13 - Setup Valid Node Checking

Valid node checking is an interesting security feature that protects DBMS instances from malevolent or errant Oracle Net connections over TCP/IP, without the need for a firewall or IP address filtering at the operating system level.The feature is controlled by the three parameters tcp.validnode_checking, tcp.invited_nodes, and tcp.excluded_nodes. Valid node checking could be enabled dynamically in Oracle10g and Oracle11g. This works only if the configuration file sqlnet.ora was present when the TNS Listener was started. There’s no sense in setting both tcp.invited_nodes and tcp.excluded_nodes at the same time, since even nodes not mentioned explicitly as excluded nodes will still be excluded when tcp.invited_nodes is set.

tcp.validnode_checking
Turns valid node checking on or off
tcp.invited_nodes
List of nodes that may connect to the TNS Listener. A comma separated list of host names and/or IP addresses on a single line
tcp.excluded_nodes
List of nodes that are denied a connection to the TNS Listener. A comma separated list of host names and/or IP addresses on a single line.

Note

For Oracle 8/8i, the lines are added to the $TNS_ADMIN/protocol.ora file.
For Oracle 9i - 11g the lines are added to the $TNS_ADMIN/sqlnet.ora file.

Step 14 - Monitor the logfile
The logfile may contain TNS-01169, TNS-01189, TNS-01190, or TNS-12508 errors, which may signify attacks or inappropriate activity monitor the logfile and generate an alert whenever these errors reaches are encountered.

For more information see:

Oracle 9iR2 Net Services Administrator’s Guide
Oracle 9iR2 Net Services Reference Guide
Oracle Support Note ID 92602.1 "How to Password Protect the Listener"
Oracle Support Note ID 124742.1 "Vulnerability in the Oracle Listener Program"
Oracle Support Note ID 260986.1 "Setting Listener Passwords With an Oracle 10g Listener"
Oracle Support Note ID 359277.1 "Changing Default Listener Port Number"
Oracle Support Note ID 332785.1 "How To Disable Local Os Authentication For Lsnrctl Utility"
http://www.jammed.com/~jwa/hacks/security/tnscmd/tns-advisory.txt
http://www.jammed.com/~jwa/hacks/security/tnscmd/tnscmd-doc.html
Oracle Security Alerts ; http://technet.oracle.com/deploy/security/alerts.htm
Oracle TNS Listener Exploits ; http://www.red-database-security.com/exploits/oracle_exploit_listener.html

Joords Oracle DBA blog

Pages

Monday, May 7, 2012

Secure the Oracle Listener