OracleAppsDBAKK1: Security Checklist: 10 Basic Steps to Make Your Database Secure from Attacks (Doc ID 1545816.1)

this Document

APPLIES TO:

Oracle Database - Enterprise Edition - Version 8.1.7.0 to 12.1.0.2 [Release 8.1.7 to 12.1]
Oracle Database - Standard Edition - Version 8.1.7.0 to 12.1.0.2 [Release 8.1.7 to 12.1]
Information in this document applies to any platform.

GOAL

This article provides a quick checklist to help enforce database security.
It serves as a starting point to help DBAs address basic security risks, and provides pointers to further reading and additional discussion.

Ask Questions, Get Help, And Share Your Experiences With This Article

Would you like to explore this topic further with other Oracle Customers, Oracle Employees, and Industry Experts?

Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article.

Discover discussions about other articles and helpful subjects by clicking here to access the main My Oracle Support Community page for Database Security

SOLUTION

Step 1: Change passwords for SYS and SYSTEM

After database creation, if you used the default passwords for SYS and SYSTEM, then change the passwords for these administrative users immediately.
Note 1051982.6 - How to Change SYS and SYSTEM Passwords

If Database Vault is enabled, ALTER USER functionality is affected. See also: What to Expect After Installing Database Vault

Step 2: Lock, expire, and change passwords for default or unused accounts

The number of default accounts varies, depending on the products one chooses to install.
For a list of Oracle products and the accounts created for these products, refer to:

Note 472937.1 - Information On Installed Database Components and Schemas

It is safer to lock accounts, and/or change their default passwords, than to drop them (immediately). For example, one can DROP USER SCOTT without issue, but one might not want to DROP USER CTXSYS if Oracle Context may be used in the future. Components may also have dependencies, such as Database Vault (with Oracle Label Security).

For production environments, do not use default passwords for any administrative accounts, including SYSMAN and DBSNMP.

Step 3: Restrict access to the Oracle home and installation files

The Oracle account should own all Oracle system files and installation files. The OSDBA operating system user group should have privileges on all Oracle system and installation files. No user outside the OSDBA group should have write access on any files or directories in the Oracle installation.

Oracle also recommends restricting symbolic links. Ensure that when providing a path or file to the database, neither the file nor any part of the path is modifiable by an untrusted user. The file and all components of the path should be owned by the DBA or some trusted account, such as root.

(9i only) Secure access to trace files. The ALTER SESSION privilege can produce trace files which may show sensitive data such as literal password changes.
Note 210317.1 - ALERT: ALTER SESSION privilege can dump trace files with possibly sensitive data

Step 4: Review database user privileges

Practice the principle of least privilege: Users should be given only those privileges that are actually required to efficiently perform their jobs.

Note 1347470.1 - Master Note For Privileges And Roles
Note 1020286.6 - Script to Create View to Show All User Privs
Note 1050267.6 - SCRIPT: Script to show table privileges for users and roles
Note 1020176.6 - SCRIPT: Script to Generate object privilege GRANTS

Step 5: Revoke privileges from PUBLIC where not necessary

The PUBLIC role is automatically assumed by every database user account. By default, it has no privileges granted to it, but it does have numerous grants, mostly to Java objects. Because all users have the PUBLIC role, any database user can exercise privileges that are granted to this role.

Security administrators and database users should grant a privilege or role to PUBLIC only if every database user requires the privilege or role.

Note 247093.1 - Be Cautious When Revoking Privileges Granted to PUBLIC
Note 234551.1 - PUBLIC Is it a User, a Role, a User Group, a Privilege ?
Note 390225.1 - Execute Privileges Are Reset For Public After Applying Patchset

Step 6: Protect the data dictionary from unauthorized users

Oracle recommends preventing users from using the "ANY" system privileges on the data dictionary.
Ensure that O7_DICTIONARY_ACCESSIBILITY is set to FALSE. (This is the default on versions higher than Oracle 8i.)

Note 47316.1 - PARAMETER: INIT.ORA: O7_DICTIONARY_ACCESSIBILITY
Note 153510.1 - Use SELECT ANY DICTIONARY or SELECT_CATALOG_ROLE or O7_DICTIONARY_ACCESSIBILITY?

Step 7: Set security related parameters to their recommended values

a. remote_os_authent = false

Setting this parameter to FALSE does not mean that users cannot connect remotely. It simply means that the database will not trust that the client has already been authenticated, and will perform authentication checks accordingly.

Furthermore, this parameter has been deprecated as of Oracle 11g:
Note 456001.1 - ORA-32004: obsolete and/or deprecated parameter(s) specified: remote_os_authent

b. sec_case_sensitive_logon = true

This will allow case sensitive passwords and is also tied to more secure password hash algorithm, for further reading check:

note 429465.1 11g R1 New Feature : Case Sensitive Passwords and Strong User Authentication

As of version 12.1.0.2 parameter sec_case_sensitive_logon is deprecated and its default value is TRUE, this means that if you set the parameter to FALSE, this error will be reported:

ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance

c. global_names = true

This parameter will enforce domain checking, for more information see:

note 957432.1 Health Check Alert: Consider setting GLOBAL_NAMES to TRUE

d. unset parameter utl_file_dir

Instead of using parameter utl_file_dir push your application developers to use DIRECTORY objects to mediate access to OS files, for more information check:

note 196939.1 Using CREATE DIRECTORY Instead of UTL_FILE_DIR init.ora Parameter

Step 8: Protect listener and network connections

Because the listener acts as the database gateway to the network, it is important to consider listener security as well.
Refer to: "Guidelines for Securing the Network Connection"

Note 1328725.1 - Deprecation of Listener Password in Oracle Database 11g Release 2
Note 260986.1 - Setting Listener Passwords With an Oracle 10g or Newer Listener
Note 364388.1 - How To Network Secure Your Oracle Database Listener in Intranet / Internet

Automatic instance registration and CVE-2012-1675

The CVE-2012-1675 vulnerability is about the security for automatic instance registration, instead of a practical attack method it was more of a proof of concept of a security researcher to highjack database connections, for affected versions implement the recommendations as advised in CVE-2012-1675 which provides authentication for the database to the listener using a wallet and certificates (COST), this mechanism also works in higher versions since it is general. However recent Oracle versions also have a feature called VNCR which secures the listener registration also without needing TCPS, for non RAC this does not need additional configuration since local databases are allowed to register with a listener on the same host by default, however for RAC you want all instances to cross register with all listeners on the cluster for load balancing etc. in that case see:

Note 1914282.1 How to Enable VNCR on RAC Database to Register only Local Instances.

If you like the COST method better you can still use: Note 1340831.1 for Oracle Database deployments that use Oracle Real Application Clusters (RAC).

Encrypt sqlnet connections using network encryption.

Consider to encrypt network traffic between clients, databases, and application servers. For an introduction to Oracle network encryption, see "Configuring Network Data Encryption and Integrity". With the Network Encryption feature liberated from the license for the Advanced Security Option there's no longer any reason for not implementing at least native network encryption for Oracle client / server connections.

To mitigate a number of recent vulnerability issues with ssl / tls, please consider to add the following parameters to both sqlnet.ora and listener.ora:

SSL_VERSION = 1.0
SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_AES_256_CBC_SHA)

This will have the following effect on secured connections originating or terminating from the database or oracle listener:

- disable ssl v3 and thus cut-off any vulnerability in this deprecated protocol

- by explicitly configuring only a limited number of cipher suites disable the use of RC4 and the dreaded export ciphers.

Step 9: Protect the database host

Run Oracle databases behind at least one corporate firewall; do not open holes in the firewall (such as by opening port 1521 for listener connections from the Internet). If such remote access is required, consider implementing a third-party VPN solution, to integrate a remote client network securely within the corporate intranet.

Oracle also offers a dedicated database firewall as part of Oracle Audit Vault and Database Firewall, which can be used to further protect the database, particularly against SQL Injection attacks.

Both UNIX and Windows platforms provide a variety of operating system services, most of which are not necessary for most deployments. Such services include FTP, TFTP, TELNET, and so forth. Be sure to close both the UDP and TCP ports for each service that is being disabled. Disabling one type of port, and not the other, does not make the operating system more secure.

Always apply all relevant and current security patches for the operating system.

Step 10: Check Oracle websites for Security Alerts and critical patches

Review the Oracle Technology Network page on Critical Patch Updates (also known as Security Patch Updates) and Security Alerts:

http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Visit My Oracle Support for details on available and upcoming security-related patches:

Note 1454618.1 - Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets
Note 1074055.1 - Security Vulnerability FAQ for Oracle Database and Fusion Middleware Products

Prior to October 2012, Security Patch Update (SPU) patches were called Critical Patch Update (CPU) patches.

Other Items to Consider

Oracle recommends that basic password management rules (such as password length, history, complexity, and so forth) as provided by the database be applied to all user passwords and that all users be required to change their passwords periodically.
Refer to: Note 114930.1 - Oracle Password Management Policy
The Oracle database assumes certain users are trusted. Do some people have (administrative) passwords who actually do not need them?
Set up monitoring to watch for suspicious activity. At the database level, decide how one wants to audit user activity, and configure auditing accordingly.
Refer to: Note 1299033.1 - Master Note for Oracle Database Auditing
Physical security is vital as well. The server maybe safely locked away in the datacenter, but what about backup tapes? If individuals have access to backups, these persons can have an entire system at their disposal, for analysis, attack , or both. Tapes are often stored in an insecure fashion; the same can be said for export files. Consider as well the eventual retirement of hard disk drives.
The use of Transparent Data Encryption, or TDE (available with the Advanced Security Option) can help mitigate risks associated with physical storage.

Online Discussion (My Oracle Support Community)

Draw on the experiences of industry professionals at the Database Security Products Community:

https://community.oracle.com/community/support/oracle_database/database_security_products

Security is a hot topic, and many are working towards this common goal. The Community provides a place to share your questions and comments with your peers.
Oracle Support also monitors the Community and contributes to these discussions as well.

The window below is a live discussion of this article (not a screenshot). We encourage you to join the discussion by clicking the "Reply" link below for the entry you would like to provide feedback on. If you have questions or implementation issues with the information in the article above, please share that below.

Click here to open the discussion in a new browser window.

OracleAppsDBAKK1

Monday, December 2, 2019

Security Checklist: 10 Basic Steps to Make Your Database Secure from Attacks (Doc ID 1545816.1)