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.

Virtual Indexes

Recently I have been to one of our clients for performance tuning of few processes. The process of tuning SQL queries requires testing of different alternatives of indexes. It becomes difficult in production environment where lots of people are connected to the database and tables are large.

Virtual indexes helps in such situations. Since virtual indexes does not use any segment, time required to create index and disk space required is irrelevant.

Command to create virtual index:

CREATE INDEX IDX_TAB ON TAB1(COL1,COL2) NOSEGMENT;

To make virtual index available, parameter _use_nosegment_indexes needs to be set to true.

ALTER SESSION SET "_use_nosegment_indexes" = TRUE;

The USER_INDEXES view does not keep information about virtual indexes. Only USER_OBJECTS view keeps the record.

Auditing SYS users

The SYS user is the most usefull and important user for any Oracle database. Lets take a look how a DBA can take hold of it if it is being misused.

Oracle provides the auditing facility of SYS account since the version 7 but after 9iR2, it has become more powerful in many ways.

How to Audit SYS account

Mainly there are only two parameters which need to be set to audit any SYS account, audit_file_dest and audit_sys_operations. The prior one sets the location for audit files and later one is ON/OFF for SYS auditing.

The audit files are created under the path provided in the parameter audit_file_dest with ora_.aud name. The file usually have following informations:

Audit file /u01/app/oracle/admin/tcolap1/adump/ora_14725.aud
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: hostname.domainname
Release: 2.6.9-34.ELsmp
Version: #1 SMP Fri Feb 24 16:54:53 EST 2006
Machine: i686
Instance name: tcolap1
Redo thread mounted by this instance: 1
Oracle process number: 25
Unix process pid: 14725, image: oracle@hostname.domainname (TNS V1-V3)

Tue Feb 6 14:11:14 2007
ACTION : 'CONNECT'
DATABASE USER: '/'
PRIVILEGE : SYSDBA
CLIENT USER: oracle
CLIENT TERMINAL: pts/1
STATUS: 0

With all the information related to the session like 'connect' and all the valid commands, it provides server related information as well, such as OS, version, Machine, etc. It does not store the invalid commands.

Invalid connection as SYSDBA

The audit files also store invalid login information. To check invalid logins to the system, following command can be given:

grep -i "status:" *.aud | grep -i -v "status: 0"

Parameters to set

alter system set audit_file_dest='/u04/app/oracle/oradata/saigon/audit' scope=spfile;
alter system set audit_sys_operations=true scope=spfile;

Bounce the database and you are done.

View the Audit Information

Audit information can be viewed in a text format or XML format depending on the parameter audit_trail setting.