Oracle Listener Security

You are working on a critical issue on your database. You login to your database and you get the error "ORA-12541: TNS:no listener". Now you start wondering how the listener has been stopped. You have not stopped it. It means "SOMEONE ELSE HAS STOPPED THE LISTENER".

It shows, you need to secure your listener from unauthorized users.

You can protect your listener with a password so that only the authorized users can start and stop it and change the configuration.

To protect a listener with password, perform following as an Oracle user:

$ lsnrctl
LSNRCTL> change_password
Old password: {press enter here}
New password: {enter new password}
Reenter new password: {reenter password}

You will get following message once done

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
Password changed for LISTENER
The command completed successfully

Once you get the message, just save the cconfiguration in the listener.ora file.

LSNRCTL> save_config
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
Saved LISTENER configuration parameters.
Listener Parameter File D:\oracle\product\10.2.0\db_1\network\admin\listener.ora
Old Parameter File D:\oracle\product\10.2.0\db_1\network\admin\listener.bak
The command completed successfully

That's it, and you have a password protected listener.

P.S. In Oracle 9i you need to give following command before saving the configuration in listener.ora file.

LSNRCTL> set password
Password:{the password you chose}
The command completed successfully

In Oracle 10g it is not required. Reason: In Oracle 10g, operating system authentication for the listener has been implemented. The listener checks to make sure you are part of the privileged dba group, and if so it will grant you access to change the password, save configuration, stop the listener, etc.

Now you are safe from all the unauthorized shutdowns of listener and other kind of security breaches.

Auditing ALTER SYSTEM commands

Wonder, who is changing the system date? Who is changing the parameter? Who is giving all those ALTER SYSTEM commands which are causing havoc for others?

The simplest solution of the problem is, "DO NOT PROVIDE PASSWORD OF DBA USER TO A PERSON WHO IS NOT A DBA". Looks simple, right? Wrong. In developement environments it is not possible to restrict the access of DBA user to 1 or 2 persons. And it is very difficult to track someone who is giving ALTER SYSTEM commands. Triggers will not work.

These commands can not be stopped, but at least can be monitored. To monitor this, you need to start the AUDITing. Again, this can hit the performance, so use it when it is really really important.

First step is to start auditing for the database. To start auditing, follow these steps:

1. Set parameter audit_trail=db,extended in the spfile.
2. Connect to SYS user and execute the following script
        $ORACLE_HOME/rdbms/admin/cataudit.sql
3. Auditing can be started for a user
        a.) for a particular command he fires (whenever the command is successful or not successful)
            AUDIT ALTER SYSTEM BY abc WHENEVER SUCCESSFUL;
            AUDIT ALTER SYSTEM BY abc WHENEVER NOT SUCCESSFUL;
        b.) for ALL the commands fired by him
            AUDIT ALL BY abc BY ACCESS;
4. shutdown the database
5. startup the database

That's it. Now you can monitor any command fired by the user. Details can be checked in DBA_AUDIT_STATEMENT view. This view will give you the user name, operating system user name, host name, terminal, timestamp and SQL text with all the other information.

So folks, try it and let me know how many users you have caught red handed when they were doing any harm to your database.