How to Protect listeners on Oracle servers

The Oracle listener is a component of the Oracle server software. It manages the communication between the Oracle database and the client. It runs on a specific Nic port (the default port is TCP15 ).

The Oracle listener is a component of the Oracle server software. It manages the communication between the Oracle database and the client. It is on a specific Nic port (default: TCP 15

Introduction to Oracle listeners

The Oracle listener is a component of the Oracle server software. It manages the communication between the Oracle database and the client. It listens for connection requests on a specific Nic port (TCP port 1521 by default, the connection is forwarded to the database and consists of two binary files: tnslsnr and lsnrctl. The tsnlsnr is the listener, which runs on the database server. lsnrctl is the listener control program used to manage listeners on the server or remotely. There are two configuration files related to the listener: sqlnet. ora and listener. ora. When tnslsnr is started, information in these two configuration files will be read, such as the port number and Database Service name.

Oracle listeners have many well-known vulnerabilities and defects when installed and configured by default. Hackers can exploit these vulnerabilities to create DoS attacks, steal database connection passwords, and further steal confidential data. The biggest risk is the Listener Configuration. Oracle provides some recommended configurations to protect the listener. This article is to carefully list some known methods to protect the Oracle listener. These methods are familiar to hackers, so it is necessary to be clear as a DBA.

Why protect listeners?

DBAs tend to be less concerned about why they want to protect listeners. They believe that hackers are unlikely to control the entire database by controlling the listener, and all versions earlier than 10 Gb of Oracle, the Oracle listener allows anyone to use lsnrctl to remotely launch listener management, but fortunately, from Oracle 10.1, it is strictly limited to remote listener management. The following lists some attack methods that may be effective when Oracle 8/9i is installed by default. Even if the latest security patches are installed without security configuration reinforcement, these attack methods are still effective:

Note: This document assumes that the listener uses TCP/IP and uses local name management (tnsnames. ora), the Oracle version described in this article has been tested on 8i/9i/10g, but I believe it will be of some reference value for other lower or higher versions.

How to Protect listeners?

Since there are so many places for hackers to use the listener, is there any way to protect it? There are still a lot of methods. To sum up, there are about 11 ways to protect Oracle listeners:

1. device listener Password

By setting the listener password, most cainiao hackers can defend against attacks. There are two methods to set the password: one is to use the lsnrctl command, and the other is to directly modify the listener. ora file. The password set in the first method is encrypted and stored in listener. ora, while the second method is in the form of plaintext in listener. in ora, so the first method is recommended. The command is as follows:

LSNRCTL> set current_listener <监听器名>

LSNRCTL> change_password

Old password: <如果之前没有设置密码就直接按回车>

New password: <输入新密码>

Reenter new password: <再次输入新密码>

LSNRCTL> set password Password: <输入刚刚设置的新密码>

LSNRCTL> save_config

After setting the password, open listener. ora to see if there is a PASSWORDS _ <监听器名> Is similar to PASSWORDS_LISTENER = F4BAA4A006C26134. After a password is set for the listener, you must reconfigure the connection to the client.

2. Enable listener logs

The listener logging function is enabled to capture listener commands and prevent brute force password cracking. To enable the listener log function, run the following command:

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

By running the above command, the listener will Create . Log file. You can open this file to view some common ORA-error messages.

3. Set ADMIN_RESTRICTIONS in listener. ora.

In listener. after the ADMIN_RESTRICTIONS parameter is set in the ora file, when the listener is running, it is not allowed to execute any management operations. At that time, the set command will be unavailable, it does not work either locally or remotely on the server. If you want to modify the listener settings, you only need to manually modify the listener. ora file. You can manually modify listener. ora. To make the modification take effect, you can only use the lsnrctl reload command or the lsnrctl stop/start command to re-load the listener configuration information. Manually Add the following line to the listener. ora file:

ADMIN_RESTRICTIONS _ <监听器名> = ON

4. Install the latest listener patch

This is similar to the operating system. The database also has bugs and vulnerabilities. Hackers will immediately scan servers without Patches when detecting vulnerabilities, therefore, a competent DBA should pay attention to the Oracle CPU at any time (haha, not a processor, but the meaning of key patch upgrade). Here we must note that Oracle patches are automatically accumulated, just as windows xp sp2 contains all sp1 content, you only need to follow the latest patch set, note that before applying any patch to the production system, you must test the patch in the testing environment to ensure that the upgrade does not affect normal services. Finally, you must note that you can log on to and download the patch only after purchasing the official Oracle license. Otherwise, you can only download the patch from a third-party address, and its integrity cannot be guaranteed.

5. Use the firewall to block SQL * NET

Unless necessary, SQL * NET should not be allowed to communicate through the firewall. When designing firewall rules, it should be designed to allow only authenticated Web servers and applications to communicate with SQL * NET through the firewall. In addition, when the application server in the DMZ area of the firewall uses SQL * NET for communication, it should only allow it to communicate with specific database servers.

Usually few applications access the database directly from the Internet, because the delay in this method is very obvious. A common practice is to configure the application server to communicate with the database, and the Internet client can access the application server through a browser, when configuring the firewall, you only need to set the communication rules between the application server and the database server.

6. Protect the $ TNS_ADMIN directory

$ TNS_ADMIN directory is the ORACLE_HOME/network/admin directory we usually see. It contains listener. ora, tnsnames. ora, sqlnet. ora, protocol. as mentioned above, the listener password is stored in listener. in ora, if it is not well protected, the password may be leaked, or the entire file may be modified, the listener in this directory. ora, sqlnet. ora, protocol. the ora file should only be open to the Oracle primary account (usually oracle or Administrator), while other accounts cannot have any permissions, tnsnames. the ora File Permission can be set to 0644 on Linux or Unix systems, and other users can be set to browse and read permissions on windows.

7. Protection of TNSLSNR and LSNRCTL

On Linux or Unix servers, set the permissions of these two files to 0751. To be stricter, set the permissions to 0700, in this way, only the host users specified during oracle installation can execute them. These two files are located in the ORACLE_HOME/bin directory. The purpose of protecting these two files is to prevent hackers from directly damaging them. If tnslsnr is damaged, the listener cannot be started. If lsnrctl is damaged, malicious code may be implanted, other hacker behaviors will be executed when lsnrctl is run.

8. Remove unused services

By default, a PL/SQL external program (ExtProc) entry is installed in listener. in ora, its name is usually ExtProc or PLSExtProc, but it is generally not used, it can be directly from listener. ora removes this because ExtProc has multiple attack methods. Sometimes the listener may be copied between multiple instances. ora: Check whether the copied file contains unnecessary services. Make sure that only the required service items are left to reduce the area where the listener is attacked.

9. Change the default TNS port number.

Changing the port number of the listener is similar to modifying the default port 21 of the ftp server and port 80 of the web server, because the default listening port of Oracle is 1521 (Oracle also officially registered two new ports 2483 and 2484, maybe the new version may be the default port number after it is released, among them, 2484 is used for SSL connections. Almost all scanners can directly scan whether the port is opened. If it is set to an uncommon port number, it may give an illusion, even if the port is opened, You need to guess what service the port is running, which makes the attack more difficult. Do not set the port to the 1521-1550 or 1600-1699 range when you modify the port. Although modifying the default port is not an advanced protection technology, it can at least prevent automatic attacks, and a simple scan on port 1521.

You can directly edit the port number in listener. ora or use the netca program to modify the port number. Of course, you must modify the port number on the client. At the same time, you must set the initialization parameter LOCAL_LISTENER so that the database will automatically register the listener after the listening port changes.

10. Set node Verification

Based on application and network configurations, node verification is a powerful method to protect listeners. Most Web applications only need to access listeners from the application server and one management client, for Oracle 8/8i, in $ ORACLE_HOME/network/admin/protocol. add the node check statement to the ora file. For Oracle 9i/10g, run the command in $ ORACLE_HOME/network/admin/sqlnet. add the node check statement to the ora file. The statement format is the same, for example:

Tcp. validnode_checking = yes

Tcp. invited_nodes = (x. x | name, x. x | name)

Tcp. excluded_nodes = (x. x | name, x. x | name)

Note: either the invited_nodes statement or the excluded_nodes statement can be used here. You cannot use both of them, or use wildcards or subnets. You can only use clear IP addresses or host names. Here, x. x indicates an IP address such as 192.168.1.100, and name indicates the host name. If there are multiple IP addresses or host names, use commas to separate them.

After node verification is set, the listener must be restarted to take effect. Using this method for node verification will consume a certain amount of system resources and network bandwidth. If too many addresses need to be verified, manual addition is also troublesome. In this case, you can use Oracle Connection Manager, if many clients access the database through SQL * NET, this method of node verification is not feasible, it will be quite slow.

11. monitoring logs

The listener log function is enabled in the previous method, after the log information is generated, You need to analyze it, common in the log file to find whether there is a TNS-01169, TNS-01189, TNS-01190 or TNS-12508 errors, if there are these errors, at least it can be said that either someone is attacking or there is abnormal activity, in addition, you can use shell basic or some simple management tools to periodically send these useful log information to DBA for real-time monitoring.

The following describes several common errors mentioned above:

Summary

After using the above 11 methods to protect the Oracle listener, it is basically difficult to use the listener for destructive activities. 100% of the interception attacks cannot be guaranteed, and at least 99% of the results can be achieved, in addition, some low-level errors may be made by DBAs. For example, you may accidentally disclose the listener password to others or expose the configuration information to the Internet.