01. a. Installing what is required

01. b. Permissions on the file systems

a. change the permission of file $ORACLE_HOME/bin/oracle to 0700
b. change the permission of file $ORACLE_HOME/bin/tnslsnr and lsnrctl to 0700
c. change umask to 0177 for background_dump_dest
d. change umask to 0177 for user_dump_dest
e. change umask to 0177 for $ORACLE_HOME/rdbms/log
f. change umask to 0177 for $ORACLE_HOME/rdbms/audit
g. change umask to 0177 for AUDIT_FILE_DEST value incase this parameter is set

02. Lock and Expire Default Users

ALTER USER <USER_NAME> ACCOUNT LOCK;
ALTER USER <USER_NAME> ACCOUNT LOCK EXPIRE PASSWORD;

03. Change the default passwords of all default users created

http://www.petefinnigan.com/default/default_password_checker.htm

download this “Oracle default password hashes.xls”.

The readme.txt says that:

This is a spreadsheet of known Oracle default users and their passwords. This list was derived by Marcle-Jan from a list compiled by Justin Williams. The original sources are indicated by Marcel-Jan in the spreadsheet. The spreadsheet also includes a username, password, security level (based on the privileges of the user), hash and also a description of the user. The final column also includes an SQL statement that can be used to install the list into an Oracle database as part of this tool.

04. Enable Data Dictionary Protection

O7_DICTIONARY_ACCESSIBILITY=FALSE

Reason:

This o7_dictionary_accessibility=true enables the DROP ANY TABLE privilege holder top drop any data dictionary objects.

SELECT ANY DICTIONARY

This privilege is not included in GRANT ALL PRIVILEGES; statement, but can be granted thru a role.

05. Practice the principle of least privilege

Restrict the following as much as possible.

01. the number of SYSTEM and OBJECT privileges granted to database users.
02. the number of users who are granted/allowed to make sys-privileged connections to the database.

Do Not Grant

01. CREATE ANY TABLE system privilege to any non-DBA-privileged user.

02. RESOURCE to any non-DBA-privileged user as that also grants UNLIMITED TABLESPACE to the grantee.

03. Default roles like CONNECT to the grantee. In Oracle 10 and upward versions CONNECT role does not include lot of DDL privileges but grants only CREATE SESSION system privilege. In the future oracle versions Oracle is going to deprecate CONNECT and RESOURCE roles.

04. DROP ANY TABLE privilege to any non-DBA-privileged user.

Do REVOKE grants from PUBLIC on these Packages

UTL_SMTP

This package permits arbitrary mail messages to be sent from one arbitrary user to another arbitrary user. Granting this package to PUBLIC may permit unauthorized exchange of mail messages.

UTL_TCP

This package permits outgoing
network connections to be established by the database server to any receiving (or waiting) network service. Thus, arbitrary data may be sent between the database server and any waiting network service.

UTL_HTTP

This package allows the database server to request and retrieve data using HTTP.
Granting this package to PUBLIC may permit using HTML forms to send data to a malicious Web site.

UTL_FILE

This package allows operating system level access. Even when properly configured,
this package may allow unauthorized access to sensitive operating system files, such as trace files, because it does not distinguish between its calling applications. The result can be that one application accessing

UTL_FILE may write arbitrary data into the same location that is written to by another application.

Restrict permissions on run-time facilities
(Quote from Oracle security checklist)

Here is an example of a vulnerable run-time call:

call dbms_java.grant_permission ('SCOTT', 'SYS:java.io.FilePermission','<<ALL FILES>>','read');

Here is an example of a better (more secure) run-time call:

call dbms_java.grant_permission ('SCOTT', 'SYS:java.io.FilePermission','<<actual directory path>>','read');

Use sqlnet.ora file at server level to stop accessing the database using
“/ as sysdba”

In the sqlnet.ora file on the server set this parameter to stop “/ as sysdba” login

SQLNET.AUTHENTICATION_SERVICES=(NONE)

Do not use ‘*’ to set value to the initialization parameter UTL_FILE_DIR

The value for this init<SID>.ora is NOT be set a wild character ‘*’ . This amounts to high security breach.

Remove CREATE ANY DIRECORY from PUBLIC and from any user that do not require it.

REVOKE create any directory from PUBLIC;
REVOKE create any directory from <USER_NAME>;

06. User Password Hardening

Oracle encrypts the concatenated the username and password. Oracle internally stores and saves the user names and passwords in the following places

(1) Database - SYS.USER$ - Password
(2) Oracle Password File
(3) Data File of the system tablespace
(4) (full) Export-Files
(5) archive logs

The synonyms and views dba_users shall also shows the hashed passwords.

LINK$ table in the SYS schema stores the password in text form for all those database links which have been created with the passwords.
There are various tables, views, synonyms where the stored passwords are found.

select username,password from SYS.DBA_USERS;
select owner,user$,passwd from SYS.EXU7LNK;
select * from SYS.EXU7LNKU;
select * from SYS.EXU7ROL;
select * from SYS.EXU7USR;
select * from SYS.EXU7USRU;
select * from SYS.EXU8LNK;
select * from SYS.EXU8LNKU;
select * from SYS.EXU8PHS;
select * from SYS.EXU8PHS;
select * from SYS.EXU8ROL;
select * from SYS.EXU8USR;
select * from SYS.EXU8USRU;
select * from SYS.EXU9LNK;
select * from SYS.EXU9LNK;
select * from SYS.EXU9LNKU;
select * from SYS.EXU9LNKU;
select * from SYS.KU$_ROLE_VIEW;
select * from SYS.KU$_USER_VIEW;
select * from SYS.LINK$;
select * from SYS.USER$;
select * from SYS.USER_DB_LINKS;
select * from SYS.USER_HISTORY$;

Hence revoke grants on those objects to PUBLIC or to any NON-DBA users.

To change the password a user is allowed

alter user <username> identified by <new_password>;

SQL*Plus command:

password or password username

To temporarily change the password and to restore the old password the age old practice is as under:

Identify the user password:

SQL> select username,password from dba_users where username='SCOTT';

USERNAME PASSWORD
-------- ----------------
SCOTT F894844C34402B67

Save the hashed and encrypted password and then

SQL> alter user scott identified by <ur_password>;

Now login with the following credentials: scott/<ur_password> do your job and then restore the old password using an undocumented feature called "by values"

SQL> alter user scott identified by values 'F894844C34402B67';

To avoid any such capability to the user
REVOKE ‘alter user’ system privilege explicitly from non-DBA users.

OS AUTHENTICATED USERS

If the database has OS authenticated users set their password to EXTERNAL

Set REMOTE_OS_AUTHENT to FALSE
Set REMOTE_LOGIN_PASSWORDFILE to NONE If this is set to EXCLUSIVE a single database only uses the password. But any user who has been granted ‘sysdba’ is eligible to remotely connect to the database and perform all SYS DBA activities including shutting down the database.

NONE

Oracle ignores any password file. Therefore, privileged users must be authenticated by the operating system.

SHARED

More than one database can use a password file. However, the only user recognized by the password file is SYS.

EXCLUSIVE

The password file can be used by only one database and the password file can contain names other than SYS who ever is granted SYSDBA privileges.

Oracle Password Policy

Oracle enables to setup a password policy. A sample file how to do this can be found at $ORACLE_HOME/rdbms/admin/utlpwdmg.sql.

Set Password Resource limits thru PROFILE

FAILED_LOGIN_ATTEMPTS
PASSWORD_GRACE_TIME
PASSWORD_LIFE_TIME
PASSWORD_LOCK_TIME
PASSWORD_REUSE_MAX
PASSWORD_REUSE_TIME

Revoke access to TABLES/VIEWS/SYNONYMS that store passwords from general non-dba user access

AUDIT select statements against DBA_USERS, LINK$, USER$

Enforce minimum password length, alphanumeric combination.

Do not HARD code of directories in the PL/SQL

Hard coding the directories in the PLSQL may cause security issues. Hence CREATE DIRECOTRY within meta data and make grants to the required users for READ and WRITE permission and then use those directories in the PL/SQL.

This hides the possible exposure of the directory destinations to public as ALL_SOURCE synonym should have grants to public or specified users in an environment where SQL Navigator or TOAD and like tools.

Audit the Data Access and Modifications

Triggers:

Create log off triggers on the database and populate the table created basing on the enabled system variables using sys_context.

AUDIT_TRIAL

Audit trial is to be enabled to populate the AUD$ table at the database level. This AUD$ table is to be moved out of SYSTEM tablespace and is to be located in a place which will not harm either the application or metadata.

Fine Grained Auditing

This enables one to study the kind of SQL issued and also the bind variable values for each update, delete, insert and select commands issued by the users against in each session.

Data is stored in FGA_LOG$ table and this table can not be moved out of SYSTEM table. DELETE is allowed against this table. Hence a process to is to be created to pump the data from this table to a another table created not in SYSTEM tablespace under the ownership of SYSTEM user with a different name like CP_FGA_LOG$ and DELETE the data periodically depending upon the data accumulations in that table.

Daily or Weekly reports are to be generated and they are to be reviewed for suitable decisions.

Cleaning of DBA_USERS

Weekly or daily the DBAs are to be supplied with the list of the persons with their LAN Ids who are moved out of the project or rolled out of the project.

Their list is to be checked against each production and sub-production database and they are to be locked for a given period and after the expiry of that given period those names are to be deleted/dropped from the databases.

Server Access and attempts to intrude/hack

An in house project to analyze the listener logs using OS level AWK and creating an external table by identifying the listener log file and its directory internally and generating reports and publishing those reports is always helpful.

To achieve this target:

After enabling the trace for the listener as also the administrative restrictions are in place for the administration of listener,

01. create a directory in the database for the listener log directory
02. create an external table to view the listener log thru the external table or
03. write a script using AWK or PERL to generate a report with the listener log file as the source

Use of Passwords In Scripts

Store the passwords as securely as possible in .file_name and call them in the run scripts. In such circumstances those files are to be set with appropriate permission only to avoid any other person not supposed to read has access to read them.

Listener Password

If the listener is not protected by any password, please set that.
Connect to lsnrctl and issue

lsnrctl

LSNRCTL> change_password
Old password: ……….. When for the first time setting the password press enter
New password:
Reenter new password:

After setting the password

LSNRCTL> save_config

This saves the encrypted password to the listener.ora file.

Restrict Access from select Nodes only

Login Triggers

Log In trigger on the database are to be created to disallow access to anybody from a given node with their IP address or DNS resolvable name of the node.

Listener Node Validation

In the $ORACLE_HOME/network/admin/sqlnet.ora

tcp.validnode_checking = yes
tcp.invited_nodes = (server01, node01, node02)
tcp.excluded_nodes = (xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx)

Mask all SENSITIVE data within Database

If any table is having sensitive data like SSN or credit card numbers etc which can potentially used by ill motivated persons, that data is to be masked.

There are various options available.

01. Do not make grants on those tables where you have sensitive data. Create views excluding the columns to be masked and then create synonyms on those views with the names of the tables and then make grants on those synonyms.

02. Use VPD by creating policies. Fine Grained Access Controls (FGAC).

Encrypting SENSITIVE data

Credit Card Numbers and/or SSN numbers and any other identified sensitive data can be encrypted using oracle provided DBMS_OBFUSCATION_TOOLKIT. There are also tools in the market to take care of the encryption. But we are to make sure of the vulnerabilities of those tools before they are bought and check for Security standards implemented in those tools and industry standards.