Oracle Database Server

This section lists a series of simple steps that can greatly improve the security of the core Oracle DBMS.

Accounts

Perhaps the easiest way to compromise an Oracle server is to guess a username and password. Oracle provides excellent user management facilities and these facilities can be used to dramatically improve security. This section shows you how.

Lock and Expire Unused Accounts

All unused accounts should be locked and expired . You can do this using the Database Configuration Assistant tool.

New Account Creation

Define a user account naming standard, such as first initial/lastname; for example, jsmith. When creating new accounts this naming standard should be used. All new user account creation should be authorized by a designated Security Officer.

Passwords

Your Oracle installation is only as strong as the weakest password. This section can help you to eliminate weak passwords from your server.

Change Default Passwords

The passwords of all default accounts should be changed. Special attention should be paid to the SYS, SYSTEM, CTXSYS, MDSYS, DBSNMP, and OUTLN accounts. New passwords can be set using SQL*Plus using the "ALTER USER username IDENTIFIED BY newpassword" statement.

Define and Enforce a Good Password Policy

Passwords should be easy to remember but difficult to guess. Password length should be at least 10 characters or more and be alphanumeric . This should be enforced using a password verification function. Once the function is created for each profile, run the following statement from within SQL*Plus:

 ALTER PROFILE profile_name LIMIT             PASSWORD_VERIFICATION_FUCTION new_value 

Passwords for user accounts should be set to expire after a set period of time, for example, 30 days. To enable password expiration run the following statement for each profile:

 ALTER PROFILE profile_name LIMIT             PASSWORD_LIFE_TIME new_value 

Passwords should not be reused for a set period of time. To set this run the following statement for each profile from SQL*Plus:

 ALTER PROFILE profile_name LIMIT             PASSWORD_REUSE_TIME new_value 

Further, it is possible to set how many new passwords must be set before an old password can be reused. This should be employed and can be set by running the following statement from SQL*Plus for each profile:

 ALTER PROFILE profile_name LIMIT              PASSWORD_REUSE_MAX new_value 

Lastly, users should not be given any grace time to select a new password when their password is up for renewal. To enable this run the following from SQL*Plus for each profile:

 ALTER PROFILE profile_name LIMIT             PASSWORD_GRACE_TIME new_value 

Roles

Correct use of roles can improve the security of your system and help to keep it secure in the future. This section describes how.

New Role Creation

New roles should be given a meaningful name and be created by a designated Security Officer. Permissions should be granted to new roles using the principle of least privilege; a role should have the necessary privileges to fulfill its function and no more. New roles can be created using SQL*Plus using the CREATE ROLE statement. When a new highly privileged role is created it should be assigned a password unless the role is to be used for application accounts.

Roles for User Accounts

To help with management of users, all user accounts should be assigned to a specific role with minimal privileges. Other roles may be assigned, too, but on a least privilege principle.

Roles for Application Accounts

Each application account should be assigned to a specific role with minimal privileges. Other roles may be added, too, but try to ensure that the least privilege principle is adhered to.

Limit the Default CONNECT Role

The default CONNECT role can create procedures and database links. These privileges should be dropped, and a new role for each of these be created and assigned these privileges instead. Any user that, as a strict business requirement, needs to be able to create procedures or database links should be assigned membership of these roles.

Set a Password on Highly Privileged Roles

For roles that are highly privileged, such as the DBA role, a password should be set. This can be performed using SQL*Plus by issuing the ALTER ROLE statement.

Authentication

Remote Authentication should be turned off. This is because the responsibility of user authentication is performed by the user's PC and not the database. To turn off remote authentication, edit the initdbsid.ora or spfiledbsid.ora file and add the following line:

 REMOTE_OS_AUTHENT = FALSE 

Stop and restart the database.

Enabled Account Lockout for User Accounts

By default a user has unlimited attempts to log in. This allows attackers to launch a brute-force attack. As such account lockout should be enabled. To do this, take the following action. From SQL*Plus and for each profile, run the following statements:

 ALTER PROFILE profile_name LIMIT FAILED_LOGIN_ATTEMPTS new_value 

You may want to consider assigning application accounts to a new profile and not enabling account lockout on this profile. If the application account is locked out, the application will fail and this is not desirable. In order to mitigate the risk of brute-force attacks against application accounts an extremely strong password should be assigned.

Use the Principle of Least Privilege

Use the principle of least privilege when creating new accounts or roles and assigning privileges. In other words, assign only those object and system privileges that are required so a business function can be performed. For example, if a user SCOTT needs to be able to SELECT from a table FOO, then only grant the SELECT permission. Do not grant SCOTT the INSERT, DELETE, or UPDATE permissions.

Enable SQL92 Security Parameter

The SQL92 Security parameter determines whether users may INSERT or UPDATE a table for which they do not have the SELECT permission. Attackers can use this to determine extant values by using conditional UPDATEs or INSERTs. As such this feature should be turned on.

Revoke any Unnecessary Permissions

By default Oracle object and system privileges are too lax. A full review of permissions should be performed and any that are superfluous to requirements should be revoked . Special attention needs to be paid to the PUBLIC role and the EXECUTE permission on PL/SQL packages, procedures, and functions.

DBA Role

Limit the number of accounts that are assigned membership of the DBA role.

Auditing

Turn on auditing. Auditing of CREATE SESSION should be enabled at a minimum.

Enable Data Dictionary Protection

Users or roles that have been granted the SELECT ANY system privilege will be able to select from the security sensitive tables such as SYS.USER$. Enabling Data Dictionary Protection will prevent this. To enable Data Dictionary Protection, take the following actions. Edit the init dbsid .ora or spfile dbsid .ora file and add the following line:

 O7_DICTIONARY_ACCESSIBLE = FALSE 

Stop and restart the database. Note that if a particular role is required to be able to select from the data dictionary, then it may be assigned the SELECT ANY DICTIONARY system privilege.

Enable Database Link Login Encryption

The SYS.LINK$ table contains credentials for remote database servers. Anybody who can select from this table will be able to view these credentials. As such it is better to have the credentials encrypted.

PL/SQL Packages, Procedures, and Functions

PL/SQL packages, procedures, and functions execute with the privileges of the definer and not the invoker unless the AUTHID CURRENT_USER keyword has been used when the PL/SQL code was written. If the PL/SQL code is vulnerable to SQL Injection, attackers can exploit this to elevate their privileges.

Existing Packages, Procedures, and Functions

A careful review should be made of the permissions set on existing PL/SQL packages, procedures, or functions with special attention being paid to the PUBLIC role. Unless there is a clear business case for PUBLIC, or any role/user, having the EXECUTE permission on a particular package, procedure, or function, it should be revoked.

Custom PL/SQL Packages, Procedures, and Functions

It is important to ensure that the development team responsible for creating custom PL/SQL programs is given a "Secure PL/SQL Coding" standard, which should be read, understood , and followed. Any code should be reviewed for security flaws such as SQL Injection vulnerabilities during the testing stage before being installed on a production system. Where possible, developers should avoid using external procedures because this opens up a security risk.

Triggers

Triggers can be used as a good generator of audit information (see the Auditing section). However, triggers are written in PL/SQL and may be vulnerable to SQL Injection. The source code of all triggers should be reviewed to ascertain if they are vulnerable or not.

Patching

Security patches from Oracle should be tested and installed as soon as possible. A Security Officer should be responsible for checking Metalink for news of new patches. Further, if that Security Officer subscribes to security mailing lists such as bugtraq, vulnwatch, and ntbugtraq, they will catch any new security issues that are not reported to Oracle but are announced to the public without a patch. In such cases, the Security Officer should work with the DBA to find a way to mitigate the risk of the new vulnerability in the absence of an Oracle-supplied patch.

Security Audits

Security audits should be regularly performed by a designated Security Officer to ensure that the security posture of the Oracle environment has not been subverted and that it does not contain any weaknesses. NGSSQuirreL for Oracle can be used for this purpose.

New Database Installs

A little security planning goes a long way toward preventing security incidents in the future. When installing a new database, install only those components that are required. Before installing the database a checklist should be made of what is needed and what is not, and the database server should be installed using this checklist.

New Database Creation

Note that if a new database is created using the CREATE DATABASE command, a user account called OUTLN is created also. This account is assigned a default password of OUTLN and is also given the EXECUTE ANY PROCEDURE system privilege. Consequently, any attacker that compromises this account can easily gain DBA privileges. It is imperative that the password for the OUTLN account be changed immediately.



Database Hacker's Handbook. Defending Database Servers
The Database Hackers Handbook: Defending Database Servers
ISBN: 0764578014
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net