Oracle Hardening Part-1

June 29, 2013, by | Start Discussion

Introduction

Oracle and SQL databases are one the most used databases in enterprises. I will be taking you through Oracle Hardening to make it hard for malicious users to break it the system. Focus will be on the parameters you need to consider and explanation on what the parameter does; why it should be changed; and how it can be done.

This will be covered in multiple parts as it’s a huge topic.

Abstract

Following template will be used for each parameter

  • WHAT: This will explain what the parameter is used for and where it can be found.
  • WHY: The reason you should consider changing it
  • VERSION: Versions of Oracle it is applicable for;
  • COMMAND: The command to help you make the changes (wherever applicable)
  • Thumb-rule: The Information security clichés (wherever applicable)
  • Recommended settings: Table of recommended settings mostly combined for multiple parameters that are similar type.

Solution

Firstly, a general but very important check.

  • WHAT: NEVER run Oracle as super-user (i.e. root for UNIX and Local System for Windows)
  • WHY: Obvious reasons, you don’t want your operating system to be compromised through an already exploited Oracle database.
  • Thumb-rule: Always, run your applications with privileges less than that of system.
  • VERSION: ALL

Before we get into the database parameters let’s look at some required OS level File permissions.

Oracle uses several file-systems to place a variety of files. Most of the oracle software files are stored in Oracle home labeled ORACLE_HOME. Oracle recommends files be placed in a format called Oracle Flexible Architecture (OFA) but it increases the security risk.

  • WHAT: Execute and write permissions for others on $ORACLE_HOME directory to be revoked.
  • WHY: Unauthorized access to everyone on the critical files of installation.
  • Thumb-rule:Revoke the execute permissions on executable from end users
  • VERSION: ALL
  • Recommended settings:
File/Directory/ Parameter Permission/ Value
$ORACLE_HOME directory rwxr-x— and/or non-world writable
$ORACLE_HOME/bin/* directory rwxr-xr-x
$ORACLE_HOME directory (most files) rwxr-xr-x

Next are some more important directories.

Audit and log directories may contain important information about system. Some errors in Oracle lead to generation of Trace files. We can generate them forcefully after enabling SQL_TRACE parameter. In general all trace files have read and write permission for Oracle software owner and group of Oracle installation has permission of read only.

  • WHAT: Access to important directories like audit, log or networktrace directories to be restricted from others.
  • WHY:  Unauthorized access to logs information and disclosure of information as any user can access this directories.
  • VERSION: ALL
  • Recommended settings:
File/Directory/ Parameter Permission/ Value
$ORACLE_HOME/rdbms/audit directory No access to others or everyone
$ORACLE_HOME/rdbms/log directory No access to others or everyone
$ORACLE_HOME/network/trace directory No access to others or everyone

Check Permissions on files again.

  • WHAT: Files/executable owned by root should not have setUID and/or setGID permissions.
  • WHY: Process that runs this file is granted access based on the owner of the file (usually root), rather than the user who is running it leading to unauthorized changes to system
  • VERSION: ALL
  • Recommended settings:
File/Directory/ Parameter
Permission/ Value
System Files/executable (especially owned by root) Set-UID and Set-GID permissions should not be set.

And again

  • WHAT: Files owned by Oracle Inventory Group (Oinstall) to be assigned permissions as per requirement
  • WHY: install group owns the Oracle inventory that is a catalog of all Oracle software installed on the system. Unauthorized changes to system due to inappropriate permissions.
  • VERSION: ALL
  • Recommended settings:
File/Directory/ Parameter
Permission/ Value
Files/executable owned by “oracle:oinstall” Set-UID and Set-GID permissions should not be set.

And again and again…. these permissions are not going let you go 😉

  • WHAT: Scheduled scripts should not be accessible by group or others.
  • WHY: Scheduled scripts are meant to be executed by owner on regular intervals, access to group or others may lead to unauthorized scripts being executed on system
  • VERSION: ALL (UNIX only)
  • Recommended settings:
File/Directory/ Parameter Permission/ Value
Scheduled scripts Not readable to group or others
Scheduled scripts of oracle users Owned by “oracle” & “root”

One more OS permission setting and we are done

  • WHAT: Permissions on data files, control file and redo log files to be restricted to owners
  • WHY:
  1. 1.    Data files contain all the database data. If data files are accessible to public, they can be read by any user
  2. 2.    Control files are binary configuration files that control access to data files. Public write access to these files may pose serious threat.
  3. 3.    Should be appropriate size and it should be accessible only to owners. Small redo logs cause system checkpoints to continuously put a high load on the buffer cache and I/O system
  • VERSION: ALL
  • Recommended settings:
File/Directory/ Parameter Permission/ Value
Data file (owner: “oracle:oinstall”) -rw——-
Control file (owner: “oracle:oinstall”) -rw-r—–
Redo log files (owner: “oracle:oinstall”) -rw——-

Finally, we are all set to configure some important database parameters. This post is getting bigger so let’s take a logical break here. Next post, we will focus on general database parameters.

 

 

Author bio not avialable

Leave a Reply