Oracle DBA – Best Practices

ORACLE DATABASE

Database Security Check list

1
 Oracle DBA – Best Practices

Table of Contents
Introduction....................................................................................2
Common Principles for DB Security Hardening.......................3
Principles for Oracle DB Security Hardening............................5
Definitions and Abbreviations...................................................13
References.......................................................................................13

2
 Oracle DBA – Best Practices
Introduction
Security of databases, a frequent topic of discussion both in the media and at security conferences, is
becoming more important for security managers and database administrators. The database is an obvious
target for external attackers and for internal company abuse. In fact, many databases and systems can be
broken into very easily. This statement is not meant to instil fear but to raise awareness. It is a well-known
fact that databases in general have not been securely installed and maintained. Why is that? While most
organisations take security seriously, they do not take database security as seriously as network and
Internet security. They should. Companies that use databases and the according software use them to
store one of the most valuable assets that the company possesses — their data.

This checklist is written in a cookbook style in order to pass on the experience of many DBAs and DB
security practitioners. Furthermore, it cannot replace in-depth security and DB training, which should be
undertaken for new DB installations.

This edition of this checklist covers only Unix installations of Oracle.

There are three main areas where DB security can be jeopardized:

 The default installation parameters that make the database insecure.

 Known vulnerabilities found by hackers and crackers, which can be fixed either by applying patches
or by implementing workarounds.
 Parameters and settings, those inadvertently set up by the application implementers or the
Database Administrator.

This guide can therefore be used in two ways: to secure a new database as it is built, and to secure an
existing database. The latter can be harder since existing applications, as well as software and business
procedures need to be taken into account.

The text has been divided into parts that cover: general security advice, operating system settings and user
access, database settings and access controls, and applications that access the DB.

Each action includes information about the DB version concerned (only if not generally valid) and about the
security severity level, which ranges from 1, the highest, to 5 the lowest 1. These severity levels are detailed
below:

Level Rating Description

1 VERY HIGH SECURITY RISK
2 HIGH SECURITY RISK
3 SECURITY RISK
4 LOW SECURITY RISK
5 VERY MINOR RISK
Check should be made regularly for non-compliance and solution adopted
immediately.
Check should be made regularly and solution adopted at first scheduled
maintenance opportunity.
Check periodically for non-compliance and make changes promptly.
Check at installation or design / development phase and apply changes if the
application / product will allow it.
Check at installation or design / development phase. Non-compliance could
cause a security risk but would not endanger normal systems – solutions
should be applied on highly secure systems such as military, health, top
secret etc.

1
Currently, only level 1 and 2 requirements have been described.
3
 Oracle DBA – Best Practices
Common Principles for DB Security Hardening

Nr. Sec Topic Compliance

Lvl
1 PREPARATION AND MAINTENANCE
1.1 1 Identify and Record Software Versions and Patch Levels on the System
YES NO
Note: These information have to be stored in a central repository.
1.2 2 Record the Database Configuration
Note: DB configuration must be stored in a source code repository (version control
system) in order to be able to restore settings quickly. Configuration includes
YES NO
especially security settings of the DB.
More detailed information of which files to be recorded could be found in the DB
specific sections.
1.3 1 Check Vulnerability Lists on a Daily Basis
Note: Since databases normally hold the most valuable assets of a company it is
crucial to keep the security configuration and patch level up to date. YES NO
More detailed information about information sources could be found in the DB
specific sections.
1.4 1 Establish and Execute a Patch Plan for Database Security Patches YES NO
2 HOST OPERATING SYSTEM SECURITY ISSUES
2.1 2 Change the Default Name for the DB Owner
Note: The default names for DB owners are well known to attackers. Although this YES NO
is a kind of "security by obscurity", it may help against automatised attacks.
2.2 1 Ensure the DB Owner Account is NOT a Privileged System Account
YES NO
Note: This includes direct account privileges as well as group membership.
2.3 1 Ensure all DB Files are Owned by the DB Owner YES NO
2.4 1 Ensure all DB Files Belong to the DB Group YES NO
2.5 1 Set a Correct umask Value for the DB Accounts
Note: The umask value shall be set to 022 (or 027 if permission are not required YES NO
outside the DB group).
2.6 1 Ensure the DB Owner Account is NOT Reachable Remotely
YES NO
Note: This could be managed by common OS means.
2.7 1 Use a Secure Temporary Directory for Installation
Note: The default temporary directory /tmp is insecure as it's accessible by all
users. Choose another one, e. g., /var/<db>/tmp by creating this directory (mode
YES NO
01750) and setting the according environment variables:
$ TEMP=/var/<db>/tmp ; export TEMP
$ TMPDIR=/var/<db>/tmp ; export TMPDIR
2.8 1 Avoid Scripts or Programmes Using Passwords in the Commandline
Note: Passing the username and password on the command line means user-
YES NO
names and passwords can be seen with a simple "ps" listing. Use techniques to
avoid to hide these information (e. g. hide.c from Oracle metalink).

4
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
2.9 2 Regularly Check for Scripts with Usernames and Passwords
Note: Search the whole machine for scripts that have usernames and passwords
embedded in them. The Passwords should be removed or encrypted.
This check has to be done both on the server and the client host(s).
YES NO
Example for finding suspicious scripts on Solaris:

#!/bin/ksh
find / -exec egrep –il 'connect|sqlplus' {} /tmp/NOT_A_FILE 2>/dev/null \;
2.10 1 Ensure Export Files are Readable by the DB Owner Solely
Example for Oracle on Solaris:
One may find exported files with the following command:
YES NO
#!/bin/ksh
find / -exec egrep –il 'EXPORT' {} /tmp/NOT_A_FILE 2>/dev/null \;
2.11 1 Change User and DB Link Passwords after DB Export (for
Troubleshooting)
Note: If a full export is performed against a production DB, the password hashes
might be exposed to people without permission toor administer access the
YES NO
production environement. In order to prevent a brute force (or a dictionary) attack
on passwords, a process must be established which enforces immediate password
change after the import in those cases where the passwords (password hashes)
have been (potentially) exposed to normally unauthorised staff.
3 AUTHENTICATION
3.1 1 Check and Change / Purge Default Accounts
Note: The database has to be checked on a monthly basis for default accounts.
Unneeded default accounts have to be purged, other default accounts have to be
checked for default passwords – if any found those have to be changed
immediately.
The above check has to be executed immediately after initial installations, patch
installations and any other partial installations or upgrades. YES NO

A process has to be set up to guarantee the enforcement of the actions described

above.

For Oracle a list of default accounts and passwords can be found at

http://www.petefinnigan.com/sans/orastepcode.htm.
3.2 2 List All Accounts and Lock Those Without Linkage to Individuals
Note: All accounts have to be linked to an individual (responsible person).
YES NO
Accounts not linked to an individual (even application or system accounts) must
either immediately be linked to a person or locked otherwise.

Principles for Oracle DB Security Hardening

5
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
1 PREPARATION AND MAINTENANCE
1.1 2 Record the Database Configuration
Note: At least the following files should be stored in a way according to item 1.2 in
section :
 init.ora
 names.ora
 tnsnames.ora
 ldap.ora
 listener.ora YES NO
 snmp.ora
 ifilecbo.ora (for Oracle applications)
 sqlnet.ora or protocol.ora
 the control file (backed up to the trace file, storing the trace file)
 any other operating system configuration file being modified by Oracle
Storing has to be done on a per-instance basis (in case multiple Oracle instances
have been installed).
2 HOST OPERATING SYSTEM SECURITY ISSUES
2.1 2 Create Different User Accounts for Different Pieces of Oracle Software
Note: E. g., the intelligent agent, the listener and the database should have YES NO
separate user accounts.
2.2 1 Configure Correct File Permission for ORACLE_HOME
Note: Permissions for $ORACLE_HOME/bin are to be set to 0751 (0755 in 9iR2) or YES NO
less, all other directories in $ORACLE_HOME are to be set to 0750 or less.
2.3 1 Clean Up the OSDBA Group
YES NO
Note: The OSDBA group must seldom contain the DB owner account.
2.4 2 Encrypt Passwords
Note: Passwords must be encrypted. To ensure this the following environment
variables must be set to TRUE:
 ORA_ENCRYPT_LOGIN (both on server and client) YES NO
 DBLINK_ENCRYPT_LOGIN (in the server initialisation file , init.ora)
DBLINK_ENCRYPT_LOGIN can't be set in version 7.1 and down and must not be
set in version 9iR2, as this would be the default behaviour.
2.5 2 Protect External Table Files
Note: Protect external table files by appropriate file permissions to prevent any YES NO
unauthorised users from accessing or altering these files.
2.6 1 Disable Native Compilation of PL/SQL (9i) YES NO
3 ORACLE AUTHENTICATON
3.1 1 Enabling of the Password Management Features (8, 8i, 9i)
Note: Enabling the password management features by altering the DEFAULT
profile could be used to enforce the O 2 password policy (password length,
YES NO
expiration period, number of users per account, password verification, etc.).
Attention This has to be executed for all default accounts as well.
:

6
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
3.2 1 Check and Change / Purge Default Roles
Note: The database has to be checked for default roles. Unneeded default roles
have to be purged, other default roles have to be checked for default passwords –
if any found those have to be changed immediately.
The above check has to be executed immediately after initial installations, patch
installations and any other partial installations or upgrades.

A process has to be set up to guarantee the enforcement of the actions described

above. YES NO

Currently the following default roles are known:

Role Name Password

ORD_SERVER ODS
WKADMIN WKADMIN
WKUSER WKUSER

4 ORACLE ACCESS CONTROLS

4.1 2 Disable or Restrict Java (8 and above)
Note: Java provides access to the OS from within the DB. If not needed, Java must
be disabled, otherwise the ability to access the OS through Java must be restricted YES NO
by denying the CREATE PROCEDURE access right at least in production and test
environments.
4.2 2 Disable or Restrict the External Procedure Mechanism (8, 8i, 9i)
Note: The ExtProc functionality provides access to external C and Java functions. If
not required, then:
 Remove the entries for ExtProc from the ADDRESS_LIST and SID_DESC
sections of the listener.ora file in $ORACLE_HOME/network/admin
 Remove the EXTPROC entry from the tnsnames.ora file in the same
location as above
 Delete the extproc binary from the $ORACLE_HOME/bin directory
 Revoke the CREATE (ANY) LIBRARY privilege from any users that don't
need it
YES NO
Otherwise, if the ExtProc processing is needed, the listener process has to be
secured as follows:
 Create a separate user who has no permissions (like UNIX user nobody)
 Remove the EXTPROC entries from the main listener.ora and tnsnames.ora
files in $ORACLE_HOME/network/data
 Create a new listener.ora and tnsnames.ora files with only entries for the
ExtProc process and point at these with the TNS_ADMIN environment
variable
 Start a second listener on a different port than the main database listener
for the ExtProc
4.3 2 Set Initialisation Parameter os_authent_prefix to " " (Null String)
Note: It this variable is set to a null string, an account can be used for external
YES NO
authentication or internal, but not both. Use an explicit IDENTIFIED EXTERNALLY
when creating a user if this feature is required.

7
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
4.4 1 Set the Initialisation Parameter o7_dictionary_accessibility to FALSE
Note: Setting this parameter to FALSE stops those users or roles granted SELECT
ANY TABLE access to the data dictionary.
YES NO
Caution: Some 3rd-party backup software may fail when this parameter was set.
This should be checked and any issues involving this parameter should
be reported to the vendor for correction.
4.5 1 Ensure the Initialisation Parameter remote_os_roles being set to FALSE YES NO
4.6 2 Ensure Correct Access Rights for Files pfile and spfile
Note: Both files have to be located in a directory where only the owner of the
YES NO
Oracle software has access to, and the permissions of these files shall only permit
the owner to read and write to them.
4.7 2 Review and Restrict the Privilege EXEMPT ACCESS POLICY (9i & higher)
Note: If this privilege is granted to a user, it is possible to bypass fine-grained
YES NO
security. Any users or roles having this privilege should be reviewed and the
privilege revoked if not necessary.
4.8 1 Clean Up the System Table Space
Note: Any objects owned by users other than SYSTEM have to be removed from
the system table space. YES NO
Caution: Approval from Oracle Support should be sought prior to removing
objects.
4.9 1 Check and Clean Up the DBA Privilege
Note: Check for any users or roles having the privilege DBA and remove this YES NO
privilege where not needed. This has to be done on a monthly basis.
4.10 1 Check and Clean Up the "all privileges" Privilege
Note: Check for any users or roles having all privileges and restrict these ones YES NO
where not needed. This has to be done on a monthly basis.
4.11 1 Check and Clean Up Extended Privileges
Note: Check for any users or roles
 having the keyword "any" included in a privilege
 having system privileges granted
 having the "CREATE LIBRARY" right granted
YES NO
 having the "ALTER SYSTEM" right granted
 having the "CREATE PROCEDURE" right granted
 having the "BECOME USER" right granted
Restrict these privileges / rights where not needed (especially in production). This
procedure has to be done on a monthly basis.
4.12 2 Check and Clean Up Special Privileges
Note: Check for any users or roles having the keywords:
 "with admin" (normally relates to system privileges only)
YES NO
 "with grant" (normally relates to object privileges only)
included in a privilege. Restrict these ones where not needed. This has to be done
on a monthly basis.
4.13 2 Check and Clean Up Users With Direct Privileges
Note: Check for users which have been granted direct privileges on objects and
YES NO
not through roles. Correct privileges in a way that users will have privileges
through roles solely.

8
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
4.14 2 Revoke Host Based Authentication for External Users
Note: External user authentication should be avoided if possible. If really needed,
users must not be authenticated host based but by more sophisticated methods YES NO
like RADIUS or Kerberos (enabling of Oracle Advanced Security).
This is especially mandatory for remotely external authentication.
4.15 1 Restrict Privileges for External Users
Note: Privileges for external users must be restricted to least rights. Especially the
following privileges must not be granted to external users:
 DBA privilege YES NO
 "all privileges" privilege
 SYSDBA role
 SYSOPER role
4.16 1 Revoke the PUBLIC Execute Privilege on "utl_file" (8, 8i, 9i)
YES NO
Note: This package can be used to access OS file systems.
4.17 1 Revoke the PUBLIC Execute Privilege on "utl_tcp" (8.1.7 & above)
YES NO
Note: This package can be used to write and read sockets.
4.18 1 Revoke the PUBLIC Execute Privilege on "utl_http" (8.1.7 & above)
YES NO
Note: This package can write content to a web browser.
4.19 1 Revoke the PUBLIC Execute Privilege on "utl_smtp" (8.1.7 & above)
YES NO
Note: This package can be used to send mail messages from the database server.
4.20 1 Check and Restrict the PUBLIC Execute Privilege on PL/SQL packages
Note: Check for all PUBLIC execute privileges on PL/SQL packages owned by sys. YES NO
Restrict these ones where not needed. This has to be done on a monthly basis.
4.21 2 Revoke the PUBLIC Execute Privilege on DBMS_RANDOM
Note: Use the more sophisticated DESGETKEY and DES3GETKEY routines in the YES NO
DBMS_OBFUSCATION_TOOLKIT package.
4.22 1 Revoke the PUBLIC Execute Privilege on DBMS_LOB (8i & above) YES NO
4.23 1 Revoke Any Granted PUBLIC Execute Privilege on DBMS_SYS and
YES NO
DBMS_SYS_SQL
4.24 1 Check and Clean Up Linked Packages
Note: Any package that is available via a database link that is not part of the YES NO
application has to be revoked.
4.25 2 Revoke the PUBLIC Execute Privilege on DIRECTORY Objects YES NO
4.26 1 Change System Users Default Tablespace
Note: The default system tablespace of the system user has to be set to YES NO
something other than system.
4.27 2 Restrict Users Default and Temporary Tablespaces
Note: Verify that the access rights will not permit creation of objects in tablespaces
user shall not have access to. YES NO

Consider using tablespace quotas in order to mitigate a denial of service attack.

4.28 1 Revoke the RESOURCE Role from Users YES NO
4.29 2 Revoke the CONNECT Role from Users YES NO

9
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
4.30 2 Check and Correct Users Profiles
Note: Ensure that the users profile settings include the following parameters and
that these parameters are set to appropriate values consistent with the
applications and the database.
 CPU_PER_SESSION
YES NO
 PRIVATE_SGA
 LOGICAL_READS_PER_SESSION
 SESSIONS_PER_USER
 CONNECT_TIME
 IDLE_TIME
4.31 2 Check and Restrict DB Triggers
Note: Check for users who have DB triggers where they are not the schema
YES NO
owners and should not have triggers. Disable any such triggers found. This has to
be done on a monthly basis.
4.32 1 Revoke Users Access to Critical Views
Note: Revoke any user access to the tables
 dba_users
 sys.link$ YES NO
 sys.user$
 sys.user_history$
User access to similar tables from 3rd-party applications has to be revoked as well.
4.33 1 Revoke Users Access to Critical Views
Note: Revoke any user access to the tables
 dba_users
 sys.link$
 sys.user$
 sys.user_history$
YES NO
 dba_% views (at least those owned by SYS)
 v_$ views (at least those owned by SYS)
 v$ synonyms (at least those owned by SYS)
 x$ tables (at least those owned by SYS)
 any dictionary objects (at least those owned by SYS)
User access to similar tables from 3rd-party applications has to be revoked as well.
4.34 1 Check and Restrict the SELECT ANY TABLE Privilege
Note: Check for any users having the privilege SELECT ANY TABLE and remove YES NO
this privilege where not needed. This has to be done on a monthly basis.
4.35 2 Revoke Object Creation Privileges from All but Schema Owners and DBA YES NO
4.36 2 Restrict Views to Permit Select Access only
Note: Check the access privileges on all views and ensure that only select access is YES NO
available. This has to be done on a monthly basis.
4.37 2 Disable FTP and HTTP Ports (9iR2 & higher)
Note: As brute force attacks on the default ports (FTP: 2100, HTTP: 8080) are not YES NO
logged, these ports must be closed.
4.38 2 Check and Restrict statspack (8i & higher)
Note: spctab.sql grants select to public on the tables stats$sqltext and
YES NO
stats$sql_summary. Restrict these rights where not needed.
This has to be done on a monthly basis.
5 AUDITING

10
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
5.1 2 Set "audit_trail" to OS
Note: If audit is enabled, records must not be written to DB tables but to OS files YES NO
in order to reduce the risk of a DoS attack using the audit mechanism.
5.2 2 Centralise Audit Trails with the Syslog Facility YES NO
5.3 2 Establish Triggers to Capture Login Events YES NO
5.4 2 Enable Auditing for Security Events
Note: The following events need to be audited by enabling the audit trace:
 Failures of INSERT attempts into critical data objects
YES NO
 Use of CREATE SESSION
 Use of GRANT statements on "Application schema owner" accounts
 Use of ALTER statements on "Application schema owner" accounts
5.5 2 Establish a Process for Audit Log Review
Note: This process must not only cover regularly (at least daily) reviews but also
appropriate actions to handle suspicious events. Take care to purge the audit trail
regularly.
YES NO
As audit logs tend to grow very fast this task could not be handled manually. A log
evaluation tool (best with some kind of "graphical heat indicator") must be used in
order to have the log file evaluation done without requiring too much resources.
5.6 2 Protect the Audit Trail
Note: Protect the audit trail with AUDIT ALL ON SYS.AUD$ BY ACCESS. This will YES NO
alert administrators to attempts to alter the audit trail.
6 NETWORKING
6.1 1 Prevent SET Commands on the Listener
Note: Add the parameter ADMIN_RESTRICTIONS_(LISTENER_NAME)=ON in YES NO
$ORACLE_HOME/network/admin/listener.ora.
6.2 2 Do Not Use Known SID or Service Name
YES NO
Note: Do not use the default database service name or SID name or ORCL.
6.3 2 Set the File Mode of listener.ora to 0600. YES NO
6.4 2 Use CMAN and Oracle Names to Restrict Connections by Source YES NO
6.5 1 Set the Listener Password
Note: Although the syntax permits to set a clear text password within listener.ora YES NO
this must not be done! The password set has to be encrypted.
6.6 1 Check DB Links for Clear Text Passwords
Note: Check DB Links for clear text passwords. If any found, switch the DB link to
type PRIVATE. If this is not possible, restrict access to sys.link$.
YES NO
Try to use "connected user" or "current user" types for establishing a remote DB
connection using a DB link (not "fixed user", as this will always require an
embedded username and password).
6.7 1 Revoke DBA Access via a DB Link YES NO
6.8 2 Provide Only Minimum Configuration Files to DB Clients
Note: The ideal client installation would only include a tnsnames.ora file (if
YES NO
needed) or better, a sqlnet.ora file containing just the name of the Oracle Names
Server.
6.9 2 Protect Clear Text Passwords for SNMP
Note: The files snmp_ro.ora, snmp_rw.ora and sqlnet.ora need to be protected as YES NO
they may contain SNMP passwords in clear text.

11
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
7 AVAILABILITY / BACKUP / RECOVERY
7.1 2 Mirror the On-Line redo Logs YES NO
7.2 2 Ensure the DB is in Archive Log Mode YES NO
7.3 2 Ensure the Archive Log Directories Exist and Appropriately Protected YES NO
8 APPLICATION DEVELOPMENT
8.1 2 Check for and Restrict Dormant Accounts YES NO
8.2 2 Revoke Any DB Links with Access to Production Databases YES NO
8.3 2 Ensure "Live" Data Held in Test / Development is Mangled or Obfuscated
Note: This includes especially production passwords!
Caution: Aside from obfuscating "live" data due to confidentiality reasons the YES NO
requirements of the data protection and telecommunication laws must
be fulfilled as well!
8.4 2 Separate Test and Development DBs from Production
YES NO
Note: This has to be established through security domains separated by firewalls.
8.5 1 Prohibit Any Direct Developer Access to the Production DB YES NO
8.6 2 Ensure No Privileged User Owns Application Objects YES NO
8.7 1 Do Not Duplicate Oracle Authentication
Note: It is important when writing applications not to duplicate the Oracle YES NO
authentication and then effectively ignore Oracle's authentication.
8.8 2 Do Not Use One DB Login to Authenticate All Other Users YES NO
8.9 2 Do Not Use Schema Owners for Administration Tasks
Note: Audit the users used to administer the database, and if the schema owner is
YES NO
being used for admin tasks, stop administrators from using it (permit access to it
for product releases only).
8.10 2 Revoke Any DBA Privileges of Schema Owners YES NO
8.11 2 Lock Schema Owner Accounts YES NO
8.12 2 Do Not Hard Code Usernames and Passwords in Application Source Code YES NO
8.13 2 Do Not Allow Applications to Change the Schema YES NO
8.14 1 Batch Processes Must Have One Specifically Designed Account YES NO
8.15 1 Do Not Use External Accounts for Batch Processes YES NO
8.16 1 Start the Oracle HTTP Server as a Non Privileged User (9i & higher)
Note: Start the Oracle HTTP Server as an operating system user who is not a
YES NO
member of the OSDBA or OSOPER groups, otherwise the iSQL*Plus DBA URL is
automatically authenticated for Oracle 9i by the operating system.
8.17 2 Add Authentication for iSQL*Plus Users (9i & higher) YES NO
8.18 2 Set HTTP Passwords for iSQL*Plus Users (9i & higher) YES NO
8.19 2 Restrict DBs that can be Accessed Through iSQL*Plus (9i & higher)
Note: The tnsnames.ora file of the Oracle 9i database is a problem for access with
YES NO
iSQL*Plus. It is possible by default to access every database in the tnsnames.ora
file of the 9i database. Restricted database access must be enabled therefore.
8.20 1 Disable iSQL*Plus on Production Servers (9i & higher) YES NO
9 APPLICATION SERVERS AND THE MIDDLE TIER

12
 Oracle DBA – Best Practices
Nr. Sec Topic Compliance
Lvl
9.1 2 Secure the Portal DAD Admin Page (9iAS)
Note: Default URL Data Access Descriptor (DAD) admin page has a default URL
YES NO
that is accessible to anyone, and which makes it possible for people to alter,
remove or add DADs.
9.2 1 Restrict Access to DAD Files (9iAS)
Note: The DADs are located in the $ORACLE_HOME/iSuites/Apache/mod_plsql/
/cfg/wdbsvr.app file. This file contains the DAD usernames and passwords either YES NO
unencrypted or simply BASE64 coded. This file has to be protected with 0700
permissions (not 0744 as of the default installation).
9.3 1 Revoke Access to the Table WWSEC_PERSON$ for All Users but the
YES NO
Portal User and SYS (9iAS)
9.4 2 Restrict the Portal Gateway URL (9iAS)
Note: By default, access to the mod_plsql gateway administration URL is not YES NO
protected.
9.5 1 Revoke DBA from Portal Admin DB Users (9iAS) YES NO
9.6 1 Remove Public Read Access from Webcache.xml File (9iAS)
Note: The file $ORACLE_HOME/webcache/webcache.xml contains the YES NO
administrator password being encrypted with a very weak encryption scheme.
9.7 2 Delete DB Cache Creation Export Files or Restrict Access to them (9iAS) YES NO
9.8 2 Protect the Apache Server (9iAS)
YES NO
Note: Details for doing so will be covered in a separate guideline.
9.9 1 Change the Default IFS Guest Password (9iAS)
Note: The default IFS (Internet File Server) password for guest has to be changed
YES NO
within the DB and in file: $ORACLE_HOME/ifs1.1/settings/oracle/ifs/protocols/
/dav//impl/properties/IfsDavServletParameters.properties.
9.10 2 Delete XSQL Servlet Class Files (9iAS)
Note: Delete all of the class files in the default servlet directory and change the
servlet URL /servlet and /servlets in the jserv.conf file. YES NO
If the newer JServ Cartridge with Apache 1.3.19 is used, be careful to change ALL
occurences ot the URLs in this file.
9.11 2 Delete the XSQL XDK from Production Databases (9iAS)
Note: Delete the XML configuration file XMLConfig.xml. Do not install the XDK if it YES NO
is not needed in production.

Definitions and Abbreviations

DB Database
DBA Database Administrator (or the equivalent role)
DoS Denial of Service
OS Operating System

References
Oracle Security, O’Reilly, ISBN 1-56592-450-9
Oracle Security Step-by-Step, SANS Press

13