Database security best_practices


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Database security best_practices

  1. 1. 1Protecting Oracle usingDatabase Security Best PracticesTarik EssawiVeriSignSession#: 217
  2. 2. 2Introduction+ An unsecured Oracle database can have a devastatingeffect on a companys reputation.+ This presentation will provide real world techniques thatwill help secure your Oracle database and data.
  3. 3. 3Areas of Security+ Oracle Binaries+ Listener+ Authorization+ Privileges+ Auditing+ Injection+ Protecting Data Outside Production
  4. 4. 4Oracle Binaries+ Securing Executables▪ SUID – permission flag that instructs the OS to execute the file as theowner of the file regardless of who executes it.▪ For example-rwsr-s--x 1 oracle dba 79746 Oct 12 2007./bin/emtgtctl2+ Securing Oracle dump files▪ Oracle generated files have large amounts of confidential informationthat could help a hacker read data from the database.▪ umask – sets the default permissions for files created in specificdirectories.– User Dump Destination– Background Dump Destination– Audit Dump Destination– Audit trails– rdbms log directories.
  5. 5. 5Oracle Binaries cont’d+ Securing SQLPLUS▪ Do not allow sqlplus to host out to the operating system– Disable the host commandinsert into system.SQLPLUS_PRODUCT_PROFILEvalues (SQL*Plus,SCOTT,HOST,null,null,DISABLED,null,null);– Restrict the host commandsqlplus –restrict 1 scott/tiger+ Writing to the OS▪ UTL_FILE_DIR is no longer needed– Remove UTL_FILE_DIR settings.– Use “create directory” instead
  6. 6. 6Listener+ lsnrctl stop mission_critical_db:1521+ Listener Password▪ The listener can be configured to require a password.– Login to listener - lsnrctl– Issue command - change_password– Save value - save_config+ Restricting the Listener▪ ADMIN_RESTRICTIONS_LISTENER = ON▪ Restricts the ability to set parameters online.▪ Changes have to be made through the listener.ora file.+ Monitoring listener.log▪ Check the listener.log file on a daily basis for suspect activity.– Look for users issuing the stop or other administrative commands
  7. 7. 7Listener cont’d+ Validating Nodes▪ Only allow specific servers to connect to the database▪ Why would servers not known by internal staff need to connect?– tcp.validnode_checking = yes– tcp.invited_nodes = (server1,server2,server3)– tcp.excluded_nodes = (..,..,..)
  8. 8. 8Listener cont’d+ Tool to ensure Listener Security▪
  9. 9. 9Authorization+ Changing Default Passwords▪ Default passwords are an easy entry point.▪ Many resources exist to identify default passwords by looking atthe pattern of the encrypted passord– MetaLink ID 340009.1 – default password check for common users.–– Almost 600 default accounts exist across the various Oracle products.+ Locking Accounts▪ Many default accounts are created during the installationprocess.▪ Lock accounts and remove if possible:– dbsnmp – user for Oracle Intelligent Agent– dmsys – user for Oracle Data Mining Option– mdsys – user for Oracle Spatial Option– ordsys – user for Oracle8i Time Series component– outln – user for stored outlines
  10. 10. 10Authorization cont’d+ Limiting SYSDBA logins▪ A password can be required for users that are part of the DBAgroup.▪ Modify sqlnet.ora– SQLNET.AUTHENTICATION_SERVICES=(NONE)▪ sqlplus / as sysdba will no longer work.▪ User will have to know sys password to connect as sysdba whenconnecting to the database.
  11. 11. 11Authorization cont’d+ Local OS Authentication▪ Typically referred to as ops$ accounts.▪ Controlled by init.ora paramter “os_authent_prefix”▪ os_authent_prefix should never be set to null– Anyone can create an OS user called system and gain super user access toDB.▪ Weak OS password authentication creates easy access to DB.+ Remote OS authentication▪ Controlled by Boolean “remote_os_authent” parameter▪ Should never be set to true.▪ Will allow user on any server to create an OS account and thenhave access to DB if matching DB account exists withoutpassword authentication.
  12. 12. 12Authorization cont’d+ Database Links▪ Prior to 10g Release 2 major security flaw▪ SYS.LINK$– Username and password stored in clear text for links.
  13. 13. 13Privileges+ Removing unneeded privileges▪ Users rarely if ever need privileges such as “drop any table”.Review privileges granted to all users and remove any privilegethat is not needed to perform their job.+ Preventing Privilege Escalation – Getting DBA Privileges▪ Escalation occurs when injection is combined with create orexecute any privileges. The “any” privileges should never begranted.▪ Monitor for privilege escalation.
  14. 14. 14Privileges cont’d+ Roles▪ Separate the owner of the tables and users that access thesystem.▪ Create roles for each type of business user.+ Principle of Least Privilege▪ Grant only the minimal privileges required for each role toperform the function.▪ Start with no privileges, increase privileges only until theoperation can be performed and stop.+ Restricting Access to the Data Dictionary▪ O7_DICTIONARY_ACCESSIBILITY=FALSE▪ Setting the parameter restricts access to sys tables.
  15. 15. 15Auditing▪ Auditing– Oracle provides comprehensive auditing of user activity.– Audit data can be captured in DB, Text file or XML File– Controlled by init.ora parameter audit_trail▪ Recommended Audit Information– Session Creations– Grants of Privileges– Changes to Auditing– Access to the audit trail and updates to audit trail▪ Fine Grained Auditing– Basic auditing captures the the username, terminal and time of a query.– Fine Grained also captures the sql issued and the SCN.▪ Auditing SYS– Standard auditing does not capture SYS– alter system set audit_sys_operations=TRUE▪ Tamper Proofing your Auditing– Monitor access to audit tables.– Move audit data to secondary source with restricted access.
  16. 16. 16Auditing cont’d▪ Extended Auditing– Enabled by setting audit_trail=DB_EXTENDED– Populates two additional columns in sys.$aud.– SQLBIND = stores bind variables– SQLTEXT = stores sql text▪ Auditing with LogMiner/Streams– Both tools can be used to mine data from Oracle redo log files and look forpatterns of malicious behavior.– For example if data is being added or removed without writing to applicationspecific tables such as audit tables an alert should be raised.
  17. 17. 17Auditing cont’d▪ Audit Vault– Standalone product from Oracle– Separates responsibilities of administering the database, modifying objectprivileges, and managing the audit trail.– DBA no longer has super user access in the DB.
  18. 18. 18Injection+ Injection▪ SQL Injection- when additional sql is passed into a dynamically generated sqlstatement sent by the application.– Can be greatly reduced by using of bind variables.– If dynamic sql is required input should be sanitized.– For example the dynamic query:1. "SELECT * FROM students WHERE student_id = " + student_variable + ";2. student_variable is set to “2;DROP TABLE students;”3. The resulting query isSELECT * FROM students where student_id=2;DROP TABLE students;– Validating the student_variable was a number, or using a bind variable wouldprevented the issue▪ PL/SQL Injection – When stored procedures included by Oracle or created bydevelopers allow arbitrary sql to be executed.– Similar to sql injection but pl/sql code can be embedded.– Certain stored procedures delivered by Oracle have this vulnerability.• SYS.DBMS_EXPORT_EXTENSION• CTXSYS.DRILOAD.VALIDATE_STMT (8i/9)– Many fixes in 10g R2
  19. 19. 19Protecting Data Outside Production+ Protecting Data in Development and QA▪ In many environments copies of production data are used for QAand Development purposes▪ Sensitive data must be cleansed when moving data toenvironments with less stringent access controls.+ Securing Backups▪ One of the most vulnerable spot where data can be stolen.▪ RMAN can encrypt backups transparently.▪ Never send backup tapes offsite unencrypted.
  20. 20. 20Summary+ Assuming a firewall will protect your database is a badassumption.+ The Listener is a single point of failure that must be protected.+ Ensure the database executables and directories are secured.+ Audit your system and monitor the audit data for unusualpatterns+ Look for privilege escalation and changes to the audit trail.+ Make your audit data tamper proof.+ Practice the policy of least privilege when designing systems.
  21. 21. 21Questions & Answers
  22. 22. 22Thank YouPlease complete your evaluation formsName: Tarik EssawiSession: Oracle Security Best PracticesSession#: 217Contact Info: