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.
$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
Check that the operating system user chosen as the owner of Oracle E-Business Suite owns all of the files in the
Prevent remote login to the
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.
Refer to the product installation documentation for the complete instructions on setting file permissions.
On UNIX systems:
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).
Set file permissions for
sqlnet.ora to 0600.
Set file permissions for
tnsnames.ora to 0644.
Set file permissions for the database data files
*.dbf to 0640.
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
$ORACLE_HOME/rdbms/admin directory including
catproc.sql and backup scripts.
On the application tier, ensure that the DBC files
$FND_SECURE/*.dbc have mode 600.
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.
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.
The database and applications require that the underlying operating system provide certain services.
Oracle Installer requires access to the X server which in turn may require access to an X font server.
Application tiers and web tiers do not require an X server.
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.
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.
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).
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:
NTP (Network Time Protocol) - for synchronizing the clock on the UNIX hosts to provide accurate audit records and simplify troubleshooting.
CRON - for operating system cleanup and log file rotation
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.
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.
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.
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.
Use scanning tools to find common security violations.
Consider installing an Intrusion Detection System (IDS), For example, Snort is a capable and free IDS system.
Good security requires secure accounts.
Make sure all OS accounts have a non-guessable password. To ensure that the passwords are not guessable, use Crack or John the Ripper (password cracking tools) on a regular basis. Often, people use passwords associated with them: license plate numbers, children's names, or a hobby. A password tester may check for these. In addition, change passwords from time to time.
Automatically disable accounts after several failed login attempts.
The fewer people with root access, the easier it is to track changes.
The root password must be a strong, non-guessable password. In addition, change the root password every three (3) months and whenever an administrator leaves company. Always logout of root shells; never leave root shells unattended.
Limit root to console login, only (specified in
Root, and only root, should have UID 0.
Check root '.*' files for security holes. The root '.*' files SHOULD have 700 or 600 permissions. The minimal umask for root is 022 (rwxr-xr-x). A umask of 077 (rwx------) is best, but often not practical.
To avoid Trojan horse programs, always use full path names including aliases. Root should never have "." in path. Never allow non-root write access to any directories in root's path.
If possible, do not create root's temporary files in publicly writable directories.
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.
Only run NFS as needed. When creating the
/etc/exports file, use limited access flags when possible (such as readonly or nosuid).
/dev/console should be world writable but never executable. Most other device files should be unreadable and unwritable by regular users.
Always get programs from a known source. Use a checksum to verify they have not been altered.
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:
Regularly run the Security Check Scripts on your production instance to ensure that it is, and continues to be, in compliance with the recommendations in this document. Reference My Oracle Support Knowledge Document 2069190.1, Security Configuration and Auditing Scripts for Oracle E-Business Suite, for more information on how to run the Security Check Scripts.
Install the latest software patches and stay current on the latest Critical Patch Updates (CPUs).
Install latest operating system patches.
Verify user accounts - delete or lock accounts no longer required.
Run security software and review output.
Keep up to date on security issues by subscribing to security mailing lists, reading security news groups and following the latest security procedures.
Test the system with Application Fuzzing tools, network security tools, and password crackers. See Appendix A: Running Web-Scanning Tools for information about false positives when running these tools.
Install Tripwire to detect changes to files.
Monitor log files including btmp, wtmp, syslog, sulog, etc. Consider setting up automatic email or paging to warn system administrators of any suspicious behavior. Also check the snort log.