Howto force password for sysdba user access

This post is also available in: Português

In many situations, the DBA is faced with the scenario where many company teams end up having access to the root password of the machine where Oracle is installed. These teams are usually the Infrastructure, the Backup, the Deployment, etc..

In this case, it is very easy to root user run a "su - oracle" and then log in the database as "conn / as sysdba" and do any alteration or damage without the consent of the DBA.

To avoid it, it is important to disable "conn / as sysdba" without typing the password. Forcing this security is not always simple, and we will accomplish it in 3 (or 4) steps in order to guarantee the inviolability of the database.

1. To start, edit your file "$ORACLE_HOME/network/admin/sqlnet.ora" and add the following line in it:

   [oracle@oraserver ~]$ echo "SQLNET.AUTHENTICATION_SERVICES=NONE" >> ORACLE_HOME/network/admin/sqlnet.ora

   With this, we will disable login via the operating system DBA group (to which Oracle belongs). Therefore, it will no longer allow access without password.

   However, is is easy for the user to remove this line from the file to momentarily log in. Monitoring the change in the sqlnet.ora also help alert if someone tried this, but is not a guarantee since monitoring can be disabled by root.

   A more advanced user can also change the location of the variable TNS_ADMIN "export TNS_ADMIN=$ORACLE_HOME/network/admin" and connect the same way.

   This technique works very well against 90% of users.

2. A second action will be to remove the oracle user group "dba" and "oper".

   [root@oraserver ~]# gpasswd -d oracle dba
   [root@oraserver ~]# gpasswd -d oracle oper

   Thus, even if the sqlnet.ora file is not restricted by item 1, the oracle user will not be able the login without a password. This can help solve your problem, but if the user is root, he could give himself this group momentarily and log in as oracle, do whatever he wanted and then remove the group again. Monitoring the change of the oracle user groups also help to alert if someone tried this technique, but it's still not a guarantee since monitoring may be removed by the root. The technique 1 and 2 together solve your problem in 99% of cases.

3. A third option would go deeper and change the name of "dba" and "oper" groups in order to mask and confuse anyone trying to access. For this, we should have ALL Oracle processes stopped, without exception. It is recommended to back up the ORACLE_HOME before starting this technique.First save a backup file of config.c (or config.s depends on the target OS).

   [oracle@oraserver ~]$ cp -p $ORACLE_HOME/rdbms/lib/config.c $ORACLE_HOME/rdbms/lib/config.c.bkp

   Then edit the file "$ORACLE_HOME/rdbms/lib/config.c" and change the name of the group, defined by the variables that have value as "dba" and "oper":

   1. If Linux x86_64 (config.c):From: #define SS_DBA_GRP "dba"
      (Option 1) To: #define SS_DBA_GRP "xpto"
      (Option 2) To: #define SS_DBA_GRP ""

      From: #define SS_OPER_GRP "oper"
      (Option 1) To: #define SS_OPER_GRP "xptu"
      (Option 2) To: #define SS_OPER_GRP ""

   2. If Solaris SPARC (config.s):From: .ascii "dba\0"
      (Option 1) To: .ascii "xpto\0"
      (Option 2) To: .ascii "\0"

      From: .ascii "oper\0"
      (Option 1) To: .ascii "xptu\0"
      (Option 2) To: .ascii "\0"

   Save and close the file. Then relink all oracle binaries:

   [oracle@oraserver ~]$ $ORACLE_HOME/bin/relink all

   Finally, make sure the "config.o" was updated by checking the date of the file:

   [oracle@oraserver ~]$ ls -la $ORACLE_HOME/rdbms/lib/config*
   -rw-r--r-- 1 oracle oinstall  472 May 23 14:28 config.c
   -rw-r--r-- 1 oracle oinstall  479 May 17 10:49 config.c.bkp
   -rw-r--r-- 1 oracle oinstall 1360 May 23 14:29 config.o

   Restart the database. This solution is the most effective. However, if the person is determined to access and is an experienced DBA, it can search the config file for the group name you defined (Option 1), create this group and granting himself. But if you leave the group name blank (Option 2), it will not succeed, because the group does not exist. He would need to undo the changes you made by editing the config file, but that would be complicated because it would be necessary to stop the database and it is no longer a case of protection against access sysdba but threatening.

4. Assuming someone still wants to go inside your database, and he undid everything you did in steps 1, 2 and 3, this topic would not fit because it is not a case to force password for sysdba user, but a case of internal threat and information security. The procedure in this situation is to enable "Transparent Data Encryption" (TDE) in your database tablespaces. Thus, if someone restart your database in step 3, he would need to know the password for your Wallet to be able to mount your tablespace again, which would be impossible.

Remembering again that the goal here is to prevent access without the sysdba password for a user from another team, not to guarantee the security of your data and datafiles. Data security threat will be covered in another topic.

+15