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.

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 the oracle user'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 (127.0.0.1).

  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

Network

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 packet filtering helps to prevent unwanted access. On the internet or a 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, or be a proxy server, or both. 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, open only those ports known to be required.

Ports to Open to Other Hosts on the LAN for a Single Primary Application Tier

If you have only one application tier, you may have the following network connections between processes on that host.

Example Network Connections Found in a Single Application Tier

the picture is described in the document text

This diagram illustrates all ports that need to be open to other hosts on the LAN or need to be open on the OS host firewall when a LAN is not set up. For example, port 8000 for OHS HTTP access, 4443 for OHS HTTPS access, and 7001 for WLS AdminServer access.

The network configuration for your application tier subnet should only allow access from the LAN to the web entry on OHS (HTTP or HTTPS) and optionally to the HTTP or HTTPS port on the WLS AdminServer.

If you do not have that level of network isolation, you will need to rely on the OS host firewall that by default denies all access except for specifically allowed traffic.

On the OS host firewall on the primary application tier, you must open the following listed ports to other hosts on the network.

If you cannot list the specific host names or IP addresses for all your trusted hosts, then you can use alternative methods to allow access to the Oracle WebLogic Server Administration ports. See My Oracle Support Knowledge Document 2542826.1, Alternative Methods to Allow Access to Oracle WebLogic Server Administration Console from Trusted Hosts for Oracle E-Business Suite Release 12.2.

On a default Oracle Linux host (Oracle Linux 9, 8, or 7), the SSH port will typically be open by default, and you will need to provide access to the OHS web entry point (HTTP or HTTPS). To do so, replace 4443 with the actual port number used in your deployment.

# firewall-cmd --add-port 4443/tcp 
# firewall-cmd --add-port 4443/tcp --permanent

To verify the open ports, run the following command. Services with well-known ports, such as sshd, are listed by service name.

# firewall-cmd --list-all 
 public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp0s3 enp0s8
  sources: 
  services: ssh
  ports: 4443/tcp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks:

Ports to Open on Application Tiers in a Multi Node Configuration

If you have more than one application tier, you will need a load balancer with LAN access and the FMW internal communication will need to cross the network between application tiers.

In this case, you must provide LAN access to the load balancer and implement host firewall rules that allow the internal FMW communication.

Therefore, the port must be open, but must be specific about what IP addresses are allowed to access the open port. To do this, ddefine "rich" rules rather than simply declaring the port "open to anyone" using the command --add-port directive.

An example of rules to add, assuming there are two application tiers, are as follows:

              10.12.2.21  app01 primary-apptier
              10.12.2.22  app02

Each application tier must allow network access to the following ports, but only to requests coming from one of the EBS application tiers.

Access to the following WLS servers is restricted by the WLS connection filter, so they can be enabled without a "rich" rule.

In addition, the OHS web entry (HTTP or HTTPS) must allow access from the load balancer IP addresses.

Still using Oracle Linux firewalld as the host firewall, examples of commands are as follows.

The previously listed commands add the rules to the running version of firewalls. If testing shows that it is working as intended, repeat these commands on each of the application tiers with the --permanent option added.

Create Access Control Lists

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.conf 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.

Authentication

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.

Authorization

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.

Maintenance

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