Operating Environment Security

Overview of Operating Environment Security

The environment in which Oracle E-Business Suite runs contributes to or detracts from overall system security. This section contains security recommendations for tightening Oracle file system security along with more general advice for overall system hardening.


Cleaning up File Ownership and Access

  1. The directory $ORACLE_HOME/bin contains Oracle executables. Check that the operating system owner of these executables matches the operating system user under which the files have been installed. A typical mistake is to install the executables in user oracle's directory but owned by root.

  2. Check that the operating system user chosen as the owner of Oracle E-Business Suite owns all of the files in the $APPL_TOP directory.

  3. Prevent remote login to the oracle (and root) accounts. Instead, require that legitimate users connect to their own accounts and su to the oracle account. Better yet, use sudo to restrict access to executables. Most operating systems now ship with sudo. Find more information about sudo at https://www.sudo.ws/. Another possibility is using Oracle Enterprise Manager with the Oracle E-Business Suite plug-in.

Cleaning Up File Permissions

Refer to the product installation documentation for the complete instructions on setting file permissions.

On UNIX systems:

  1. Set the permissions on $ORACLE_HOME/bin to 0751 or less. Set all other directories in $ORACLE_HOME to 0750 or less. Note, this limits access to the Oracle user and its group (probably DBA).

  2. Set file permissions for listener.ora and sqlnet.ora to 0600.

  3. Set file permissions for tnsnames.ora to 0644.

  4. Set file permissions for the database data files *.dbf to 0640.

  5. Ensure that the owner, group and modes of the Oracle files created upon installation are set to allow minimum privilege. The following commands make this change. Note, the group and owner are for illustration only, the correct group and owner should be substituted.

    $chown -R <oracle> $ORACLE_HOME
    $chgrp -R <dba>    $ORACLE_HOM
  6. Protect the $ORACLE_HOME/rdbms/admin directory including catalog.sql, catproc.sql and backup scripts.

  7. On the application tier, ensure that the DBC files $FND_SECURE/*.dbc have mode 600.

  8. Verify that set userid (SUID) and set group id (SGID) are not set on binaries. In general, Oracle recommends that the SUID and SGID bits to be removed from binaries shipped by Oracle.

    Warning: If the concurrent manager runs on the database tier and is using the BEQ adapter to avoid TCP cost, the SUID and/or SGID bit must be set on the Oracle database executable in $ORACLE_HOME/bin. This may also apply for any third party products running on the database tier.

Locking Down Operating System Libraries and Programs

The database and applications require that the underlying operating system provide certain services.

  1. X Server

    1. Oracle Installer requires access to the X server which in turn may require access to an X font server.

    2. Application tiers and web tiers do not require an X server.

    3. A production database does not require access to an X server.

    This means that there is no requirement to install X on any of the Oracle E-Business Suite servers if a remote X Display can be provided during installation. Typically, the administrator's workstation can run the X Server and grant access to the Oracle E-Business Suite servers during installation.

  2. Printers

    Applications may require access to printers - normally via the lpd interface on port 515/TCP. If possible, restrict access to the operating system users who absolutely need the printing facility from the shell.

  3. Email

    Applications may require access to an SMTP Mail Transfer Agent (SMTP MTA) typically sendmail or qmail on port 25/TCP. This is required for outbound emails, typically notifications from the workflow system. If only outbound email is required in your environment, make the mail daemon listen on the localhost interface (

  4. Remote Access

    Use Secure Shell (SSH + scp) to access application tier and database hosts. This replaces Telnet, rsh, rlogin, rcp and FTP, and it only requires one open port 22/TCP.

Although not required by Oracle E-Business Suite, the following services may provide operational convenience:

  1. NTP (Network Time Protocol) - for synchronizing the clock on the UNIX hosts to provide accurate audit records and simplify troubleshooting.

  2. CRON - for operating system cleanup and log file rotation

  3. Monitoring agents - for monitoring operating system, database and application components for health and security


To secure the network, limit access to services users need and make those services as secure as possible. Disabling unused services reduces securing and monitoring work.

Filtering IP Packets

IP filtering helps to prevent unwanted access. On the internet or large network, use a firewall machine or router with firewalling capabilities.

A firewall machine sits between the internet and the intranet or the intranet and the internal servers. It provides a point of resistance by protecting inside systems from external users. A firewall machine can filter packets and/or be a proxy server. Firewalls may be software or hardware based. For software solutions, dedicate a machine to be the firewall. Do not assume that using Network Address Translation (NAT) substitutes for a firewall.

Filtering out unused services at the firewall or router level stops infiltration attempts earlier in the process. Unless running NFS between networks, block all RPC ports on the router. Better yet, implement a default OFF policy, opening only those ports known to be required.

On the host, create access control lists in /etc/ssh/sshd.conf to limit which users can connect to the local machine. Turn off unused services in /etc/inetd.conf, or disable inetd if no services require it.

Preventing Spoofing

To prevent host name spoofing, turn off source routing and filter packets originating outside the network that have source IP address from the inside network.

On the system side, only use fully qualified host names or IP addresses in system files.

For the production system consider enumerating all hosts that are part of the Oracle E-Business Suite instance in the hosts file on each system, this reduces the dependency on DNS for the core system.

Eliminating Telnet, RSH, and FTP Daemons

Enforce the use of SSH (Secure Shell). SSH provides encrypted traffic to prevent snooping. Telnet, rsh and FTP send the passwords in clear text and, for this reason, should not be used.

Verifying Network Configuration

Use scanning tools to find common security violations.

Monitoring For Attacks

Consider installing an Intrusion Detection System (IDS), For example, Snort is a capable and free IDS system.


Good security requires secure accounts.

Configuring Accounts Securely

Limiting Root Access

Managing User Accounts

Do not share user accounts. Remove or disable user accounts upon termination. Disable login for well known accounts that do not need direct login access (bin, daemon, sys, uucp, lp, adm). Require strong passwords and, in some cases, a restricted shell.


Securing NFS

Only run NFS as needed. When creating the /etc/exports file, use limited access flags when possible (such as readonly or nosuid).

Securing Operating System Devices

Device files /dev/null, /dev/tty, and /dev/console should be world writable but never executable. Most other device files should be unreadable and unwritable by regular users.

Securing Executables

Always get programs from a known source. Use a checksum to verify they have not been altered.

Securing File Access

Create minimal writable file systems (esp. system files/directories). Limit user file writes to their own directories and /tmp. Add directories for specific groups. Limit important file access to authorized personnel. Use setuid/setgid only where absolutely necessary.


Good security practice does not end after installation. Continuous maintenance tasks include: