Protect the listner

Background

Creating a buffer overflow—crashing the listener by sending a large string to be executed—is a common intruder tactic. Another popular one is to see the various components using SET DISPLAYMODE VERBOSE from the lsnrctl utility. In this case the hacker may manipulate the settings by running lsnrctl on a vulnerable machine to administer the listener on the target server. Here's an example:

LSNRCTL> set trc_level support Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521))) LISTENER parameter "trc_level" set to support The command completed successfully LSNRCTL> set trc_directory /tmp Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521))) LISTENER parameter "trc_directory" set to /tmp The command completed successfully

As the trace level is SUPPORT , the listener generates a lot of information that you may not want the hacker to know. Also, because the trace files are written to the directory /tmp, he can easily see them as well. All this can be learned without even being on the server.

Strategy

To protect the listener, the best option is to set a password. In addition, you can employ another approach: restricting the ability to set various parameters of the listeners using the lsnrctl utility. In that case, the only way to change parameters is to set them in the listener configuration file and then reload it. To set these restrictions, you can place the following line in the listener.ora file:

ADMIN_RESTRICTIONS_LISTENER = ON and then restart the listener. Now, you can no longer use the SET command in the lsnrctl prompt to change a value. For example:

LSNRCTL> set trc_directory /hacker_dir Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=PROPRD1)) TNS-12508: TNS:listener could not resolve the COMMAND given

Note the TNS-12508. From now on, to change a value, you must do so in listener.ora and then use the reload command.

LSNRCTL> reload This is true for all Oracle versions discussed in this series.

Even if you use a password to protect the listener, you should still use this technique to further restrict the hacker's ability to administer the listener. This is particularly true in Oracle Database 10g, where a listener password is not required for the Oracle software owner.

Implications

The implications are negligible. Few users edit parameters online anyway; rather, they edit listener.ora and then reload the listener. Thus, this change will not affect them at all.

Note however that it will no longer be possible to use remote listener control to administer a listener on a different server. Instead, you have to log onto the server to make the change in listener.ora and then reload the listener, which is best practice anyway.

Action Plan

Place the parameter ADMIN_RESTRICTIONS_LISTENER = ON in the file listener.ora. Reload the listener by issuing lsnrctl reload.