Oracle Hardening – Part I

Hey!! We are back again with some more wealth

I will be taking you through Operating System security and Database Security concepts. This won’t be a checklist based on different standards. Rather I would be grabbing some bits and pieces from best practices and explaining in detail the Risk, requirement and standard required settings. It will help you design a detail guideline for configuring your Databases/Operating systems as per your organization’s requirement.

So, let’s get started

Today, we will be going through Oracle database hardening parameters. Due to vast coverage we will cover the same in multiple parts.

Firstly, a general but 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.
• VERSIONS: ALL

Before we hop 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: Remove the execute permissions on executable from others
• VERSIONS: ALL

Recommended settings:

Next are some important directories.

• WHAT: Access to important directories like audit, log or network\trace directories to be restricted from others.
• WHY: Unauthorized access to logs information and disclosure of information as any user can access this directories.
• VERSIONS: ALL

Recommended settings:

Permissions again

• WHAT: Files/executables 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.
• VERSIONS: ALL

Recommended settings:

And again

• WHAT: Files owned by Oracle Inventory Group (oinstall) to be assigned permissions as per requirement.
• WHY: Oinstall group owns the Oracle inventory that is a catalog of all Oracle software installed on the system. Unauthorized changes to system.
• VERSIONS: ALL

Recommended settings:

And again and again…. these permission are not letting 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.
• VERSIONS: ALL (UNIX only)

Recommended settings:

Ok, just one more OS permission setting and we are done

• WHAT: Permissions on datafiles, control file and redo log files to be restricted to owners.
• WHY:
  • Datafiles contain all the database data. If datafiles are accessible to public, they can be read by any user.
  • Control files are binary configuration files that control access to data files. Public write access to these files may pose serious threat.
  • Should be appropriate size and accessible only to owners. Small redo logs cause system checkpoints to continuously put a high load on the buffer cache and I/O system.
• VERSIONS: ALL

Recommended settings:

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

Thanks!! Please comment below, always welcome for feedback’s.