Oracle Hardening – Part 2

August 29, 2013, by | Start Discussion

Introduction

While Oracle is designed “secure by default,” this article explores a variety of those defaults and administrative approaches that help to minimize vulnerabilities. Please remember that the strategies discussed here are presented as options to consider rather than definitive rules to apply. In previous article (June 2013 issue) I went through OS level permissions for securing Oracle databases; I will be taking you a step closer towards Oracle Hardening to make it hard for perpetrators to break into 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. Oracle security parameters will be covered in this part.

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/not-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 of similar type. (wherever applicable);

Solution

As mentioned above let’s start with important OS security parameters in Oracle Database:

O7_DICTIONARY_ACCESSIBILITY

  • WHAT: Controls restrictions on SYSTEM privileges. If the parameter is set to true, access to objects in the SYS schema is allowed. The default setting is false.
  • P.S: System privileges that allow access to objects in “any schema” are not allowed access to objects in the SYS schema
  • WHY: Unauthorized/ Inadvertent access and changes to SYSTEM
  • Thumb-rule: Least privileges
  • VERSION: ALL
  • Command: Login as SYSDBA and execute ALTER SYSTEM command as:ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY = true SCOPE=spfile

TRACE_FILES_PUBLIC

  • WHAT: Some errors in Oracle lead to generation of Trace files. We can generate them forcefully after enabling SQL_TRACE parameter. All trace files are logged in USER_DUMP_DEST or BACKGROUND_DUMP_DEST 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. Other users don’t have privilege of read. Trace files can be found at /opt/oracle/ora11g/admin/orcl/udump.
    Oracle applies this permission using hidden parameter called _TRACE_FILES_PUBLIC. Due to this parameter trace files don’t have read permission to other users or public.
  • P.S: Default value of _TRACE_FILES_PUBLIC is FALSE. It is not recommended to change value.
  • WHY: Trace files may contain important information about database security or some sensitive details of data.
  • Thumb-rule: Need-to-know privileges
  • VERSION: ALL
  • Commands: Login as SYSDBA and execute ALTER SYSTEM command as: ALTER SYSTEM SET “_trace_files_public” = TRUE SCOPE=SPFILEP.S: After changing _TRACE_FILES_PUBLIC parameter to TRUE. Newly generated trace will have read permission granted to other users and public.

USER_DUMP_DEST

  • WHAT: Specifies the directory where the server will write debugging trace files on behalf of a user process. Value should never be set to “*”
  • WHY:  Trace files may contain important information about database security or some sensitive details of data.
  • VERSION: ALL
  • Commands: The parameter can be set in the initialisation file as user_dump_dest = ‘directory’e.g. user_dump_dest = ‘R:OracleAdminNT92001udump’;This parameter can be also set at system levelE.g. ALTER SYSTEM SET user_dump_dest = ‘Q:Udump’;

UTL_FILE_DIR

  • WHAT: Specifies one or more directories that Oracle should use for PL/SQL file I/O. Value should never be set to “*”
  • WHY: All users can read or write to all files specified by this parameter. Therefore this value means that the package UTL_FILE can be used to write to any directory in the system where oracle has write permissions. GREAT!!
  • VERSION: ALL
  • Commands: The parameter can be set in the initialisation file as utl_file_dir = ‘directory’

P.S: Quite often databases have the utl_file_dir is set to the user_dump_dest. If this is the case then it should be possible to be able to read trace files you wouldn’t ordinarily have access to UTL_FILE_DIR and USER_DUMP_DEST should not be same.

RESOURCE_LIMIT

  • WHAT: Specifies whether resource limits are enforced in database profiles. Value should be set to “TRUE”
  • WHY: This is not a security issue but a performance issue. Limits specified in profiles will not be applied to users.
  • VERSION: ALL
  • Commands: This parameter can be set at system level.
    E.g. ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;

TRANSACTION_AUDITING

  • WHAT: TRANSACTION_AUDITING to be set to TRUE. Oracle generates a special redo record that contains the user logon name user name the session ID some operating system information and client insformation. For each successive transaction. Oracle generates a record that contains only the session ID. These subsequent records link back to the first record which also contains the session ID
  • WHY: Redo log will not be generated if set to false. Useful if you are using redo log analysis tools.
  • VERSION: ALL
  • Commands: This parameter can be set at system level
    E.g. ALTER SYSTEM SET TRANSACTION_AUDITING = TRUE;

REMOTE_OS_AUTHENT

  • WHAT: REMOTE_OS_AUTHENT specifies whether remote clients will be authenticated with the value of the OS_AUTHENT_PREFIX parameter.
  • WHY: Allowing the OS to control OS authentication without intervention can be very risky.
  • VERSION: ALL
  • Commands: This parameter can be set at system level
    E.g. ALTER SYSTEM SET REMOTE_OS_AUTHENT= FALSE;P.S: The remote_os_authent parameter has been deprecated in Oracle 11g, and a safer method is now used.
    These are some of the important OS parameters; we will focus on permissions on Oracle tables and packages in next article.



Author bio not avialable

Leave a Reply