securing oracle databases
Download
Skip this Video
Download Presentation
Securing Oracle Databases

Loading in 2 Seconds...

play fullscreen
1 / 11

Securing Databases - PowerPoint PPT Presentation


  • 347 Views
  • Uploaded on

Securing Oracle Databases CSS-DSG JTrumbo Audit Recommendations Make sure databases are current with patches. Ensure all current default accounts & passwords (for example, scott/tiger) are disabled or changed

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Securing Databases' - Audrey


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
audit recommendations
Audit Recommendations
  • Make sure databases are current with patches.
  • Ensure all current default accounts & passwords (for example, scott/tiger) are disabled or changed
  • Institute a password change for existing accounts; minimally those where the password=username (a large effort in itself, but the audit team and countless others /probably/ have most or all of the password hashes)
  • Make it difficult to query the TNS Listener for available databases. The listener password accomplishes this, but may cause problems with database restarts.
audit recommendations3
Audit Recommendations
  • Hide the password field in the SYS.USERS$ table from normal users (if possible)
  • Hide data on the SYS tables that would allow identification of users with high privilege.
  • Encrypt database links
  • If you have multiple logons, use different passwords for each.
  • Audit and lockout accounts with higher than normal invalid password counts.
  • Use Oracle’s Audit tools. We have found this too expensive in disk and cpu cycles. We have a home grown solution instead.
basic maintenance
Basic Maintenance
  • Keep database up to current version
  • Keep database up to current patch level
  • Keep OS up to current version
  • Keep OS to current patch level

No excuses on this. The Lab Director has dictated

that patches will be applied in a timely manner.

Reasonable downtime must be planned & granted to

accomplish patching.

  • Restrict OS access
  • Restrict database server machines to the database only and db monitoring. NO web servers, NO users except Oracle.
passwords
Passwords
  • Change all the default pwds upon installation including:
    • Sys
    • System
    • Dbsnmp (edit snmp_rw.ora)
    • Scott/tiger
    • A host of others

See The Database Hackers Handbook, Litchfield/Anley/Heasman/Grindlay for complete list.

NOTE*** some db installations, (mysql), auto start with the default pwds. These must be changed IMMEDIATELY, as a hack can occur within minutes.

  • Make a reasonable parameter list in utlpwdmg.sql, and run it against your databases to enforce complex passwords.
  • Make sure the utlpwdmg includes a max # of login attempts an lock out accounts trying unsuccessfully to log in.
enforce complex passwords
Enforce Complex Passwords
  • Make sure pwds have a recycle schema (no recyclability is an option)
  • Annual resetting of pwds (hopefully oracle will get kerberos working)
  • The password complexity verification routine ensures that the password meets the following requirements:
    • Is at least eight characters long
    • Differs from the username
    • Has at least one alpha, one numeric, and one punctuation mark character (underscore counts!)
    • Is not simple or obvious, such as welcome, account, database, or user
    • Differs from the previous password by at least 3 characters

Accounts that do not update the database can be the exception to complex password/expiration requirements, with the exception of any read only accounts that has access to SYS tables.

database roles
Database Roles
  • Practice principle of least privilege. Insure users have only the roles & privs they need to complete their function.
dictionary
Dictionary
  • Sys and system tables need to be hidden from users. Do not allow users with see sensitive hashed password columns in the dictionary.
    • change the 07_dict=false in the init.ora
    • retain \'select any table\' for users allowing them can look at each others stuff if necessary
    • grant select any dictionary table only to the user that needs dictionary read access. (this is probably limited to dba or monitoring users, not application owners or end users).
    • Create a role with the limited and acceptable SYS tables users need to monitor their apps, (v$session, v$instance), and apply role as needed.
steps taken
Steps Taken
  • Password protect listeners, although till 10g, this opens up other issues.
  • Drop obsolete dblinks, drop any dev-prod links. Where possible made links read only.
  • Change external authenticated accounts to password protected accounts.
  • Implement the complex pwd function (utlpwdmg).
  • Set up additional login profile(s) to handle read only and group accounts (accounts with globally known passwords that are read only).
  • Protected the read-only accounts from the modification of the password.
  • Force password changes for blatantly soft accounts, locking the accounts if necessary.
steps taken10
Steps Taken
  • Restricting access to the oracle dictionary (SYS objects). We wished to use fine grain access to mask the sensitive columns, however we discovered fine grain was not available to be used on dictionary tables. This forced a review of all the applications’ use of dictionary tables and creation of new role(s) to handle the needed but very limited access to some dictionary tables containing no sensitive columns.
  • Kerberize logins – on the docket with Oracle, should automatically force & synchronize regular scheduled password changes. Currently, standard MIT kerberos is not supported by Oracle thus kerberos cannot be implemented.
references
References
  • Oracle Database Security Checklist http://www.oracle.com/technology/deploy/security/pdf/twp_security_checklist_db_database.pdf
  • The Database Hackers Handbook, Litchfield/Anley/Heasman/Grindlay
  • A copy of the Oracle baseline security document available http://www-css.fnal.gov/dsg/internal/briefings_and_projects/index.html CIS_ORACLE_BASELINE.
ad