Introduction to Oracle Security

1. Introduction to Oracle Security 中原大學應用數學系 劉 立 民

2. Know your threats • Erasing your data • Changing your data in an undetectable manner • Reading your data to compromise your organization’s position • Destroying your data

3. Internal and External threats • Internal threats • Behind your firewall • Can access your network • External threats • Hacker (white hat) • Cracker (black hat) • Gray hat

4. Top security myths • Myth: Hackers cause most security breaches. • In fact, 80% of data loss is to caused by insiders. • Myth: Encryption makes your data secure. • In fact, encryption is only one approach to securing data. Security also requires access control, data integrity, system availability, and auditing. • Myth: Firewalls make your data secure. • In fact, 40% of Internet break-ins occur in spite of a firewall being in place.

5. Who can do what • Authentication • The process used to determine that a user is who he or she claims to be • Authorization • Authorization is based on matching an identity with a list of rights, priviliges, or areas of access

6. Typical E-Commerce Architecture

7. Dimensions of Data Security

8. Fundamental Data Security Requirements • Confidentiality • Integrity • Availability

9. Confidentiality • Privacy of Communications • Secure Storage of Sensitive Data • Authenticated Users • Granular Access Control

10. Integrity • System and object privileges control access to application tables and system commands, so that only authorized users can change data. • Referential integrity is the ability to maintain valid relationships between values in the database, according to rules that have been defined. • A database must be protected against viruses designed to corrupt the data. • The network traffic must be protected from deletion, corruption, and eavesdropping.

11. Availability

12. Security Requirements in the Internet Environment • Promises and Problems of the Internet • Increased Data Access • Much More Valuable Data • Larger User Communities • Hosted Systems and Exchanges

13. Data Security Risks • Data Tampering • Eavesdropping and Data Theft • Falsifying User Identities • Password-Related Threats • Unauthorized Access to Tables and Columns • Unauthorized Access to Data Rows • Lack of Accountability • Complex User Management Requirements

14. A Matrix of Security Risks and Solutions

15. A Matrix of Security Risks and Solutions (Con’t)

16. A Matrix of Security Risks and Solutions (Con’t)

17. The System Security Team

18. Security Oracle on UNIX • How the Oracle database runs • PMON, SMON, DBWR, DBW0, LGWR, RECO, CKPT, ARCH • Installing Oracle on UNIX • Create a group named oinstall for installation • Create an account called oracle to install/own the software

19. Oracle’s recommended groups • ORA_ALL: all users allowed to access the ORACLE_HOME directory • ORADBA: users to map to the OSDBA role. • ORAOPER: users to map to OSOPER role. • ORASTARTUP: users who will need to start up an instance. • ORAOWNER: users who will have full access to the operating system file.

20. Oracle’s group hierarchy ORA_ALL ORASTARTUP ORAOPER ORAOWNER ORADBA

21. Set file permissions • Change the group of the ORACLE_HOME directory to ORA_ALL and set the permission to 750 to restricts anyone who has not explicitly been added to the ORA_ALL group. • Change the group of all files and directories under ORACLE_HOME to ORAOWNER and set permission to 775. • For the ORACLE_HOME/rdbms/log and audit directories, set the permission to 750. • For the oracle executable file change the group to ORASTARTUP and set the permissions to 6710.

22. Advantages gained from the architecture • Denies access to all users, yet allows you to grant limited access to SQL*PLUS users • Provides the ability to name OSDBA and OSOPER users who do not have free reign over the file system. • Provides the ability to grant control of files in ORACLE_HOME to individual Unix users. • Prevents users with full control of the ORACLE_HOME from deleting audit logs and manipulating or viewing the data files.

23. Security of raw device • A raw device is a partition on the hard drive that is not mounted or controlled via the UNIX file system. • Use ls on /dev/rdsk directory to locate your raw devices. • Change permissions on raw devices #chown oracle /dev/rdsk/dks2d2s3 #chgrp oinstall /dev/rdsk/dks2d2s3 #chmod 700 /dev/rdsk/dks2d2s3 • Use the raw device create database TESTDB logfile ‘/oracle/dbs/logfile1.f’ size 100k ‘/oracle/dbs/logfile2.f’ size 100k datafile ‘/dev/rdsk/dks2d2s3’ size 10000k reuse;

24. Firewalls and Oracle • A firewall is a single point of control on a network, used to prevent unauthorized clients from reaching the server. • It acts as a filter, screening out unauthorized network users from using the intranet. • Firewalls are rule-based. They have a list of rules that define which clients can connect, and which cannot.

25. Firewall Approaches – Approach I

26. Approach I – Pros and Cons • Pros • The setup is simple • Your internet computers are totally isolated from the external computers • You only require the user of a single firewall • Cons • Both web server and database are open to any attach • How to make this model work • Updating patches and service packs • Disabling unnecessary services • Implementing strong passwords

27. Firewall Approaches – Approach II

28. Approach II – Pros and Cons • Pros • The setup is simple • Low cost of the configuration • Compare to approach I, the security is much tighter • Cons • Allowing packets through the firewall into the internal network weakens the security

29. Firewall Approaches – Approach III

30. Approach III – Pros and Cons • Pros • Compare to approach II, the security is much tighter • Cons • Web server remains exposed to attach • How to make this model work • Must harden the OS that the web server runs on • Many security holes are discovered every day

31. Firewall Approaches – Approach IV

32. Approach IV • Pros • Compare to approach III, the model is more robust • It limits the ability to spoof and separated external machines from internal machines • Even if the machines in the DMZ (demilitarized zone, area between firewalls) are compromised, the setup continues to protect the internal network from servers in the DMZ.

33. What a firewall does not prevent • Firewalls cannot protect you from internal attacks • Firewalls cannot stop a hacker who can get around your firewall. For instance, by calling into a modem on a computer that is connected to your internal network • Firewalls cannot stop a hacker attacking your laptop when it is connected to a cable modem at employee’s home • Firewalls cannot stop virus like Trojan horse inside an email.

34. Using Oracle through a firewall • Firewalls can be implemented in two ways • Firewalls using Oracle Connection Manager in an intranet environment • Firewalls using Oracle Net Firewall Proxy in an internet environment

35. Oracle Connection Manager in an intranet environment • It can be configured to grant or deny client access to a particular database service or a computer, based on the following criteria: • Source host names or IP addresses for clients • Destination host names or IP addresses for servers • Destination database service names • Client use of Oracle Advanced Security

36. Intranet Network Access Control with Oracle Connection Manager For this configuration to work, clients require the JDBC Thin driver.

37. Oracle Net Firewall Proxy in an internet environment • Oracle Connection Manager functionality is offered by some firewall vendors through a software component called Oracle Net Firewall Proxy. • A host computer, called an application gateway, runs the Oracle Connection Manager software.

38. Internet Network Access Control with an Application Gateway

39. Ensuring Security in Three-Tier Systems • Proxy Authentication to Ensure Three-Tier Security • An important security feature for three-tier systems is the ability to proxy authenticated user identity from a middle tier to the database. • Java Database Connectivity (JDBC) • JDBC allows Java programs to send SQL statements to an object-relational database such as Oracle. JDBC enables a middle tier server to access a database on behalf of a client user by establishing a lightweight session for the user. • Java applets can thus transmit data over secure channels. • You can have secure connections from middle tier servers with Java Server Pages (JSPs) to the database.

40. Overview of Oracle HTTP Server Security • Oracle HTTP Server • It comes standard on the Oracle8i and Oracle9i database CDs. • It is a valuable tool for developing CGI or Java applications. • Most of the configuration options required for the Oracle HTTP Server are built during the Oracle install. • Oracle HTTP server user Apache as its engine

41. Oracle HTTP server components • Oracle HTTP Server 1.3.12.0.3a • Oracle HTTP Server Extensions 9.0.1.0.0 • Oracle Mod PL/SQL Gateway 3.0.9.0.7 • Apache Module for Oracle Servlet Engine 9.0.1.0.0 • BC4J Runtime 5.0.0.417.1 • Apache Configuration for Oracle XML Developer's Kit • Oracle eBusiness Management Extensions 9.0.1.0.0 • Oracle HTTP Server Extensions 9.0.1.0.0

42. Steps for Handling URL Requests in Oracle HTTP Server

43. Oracle web server security • Ensure the data stream cannot be viewed or tampered with by a third party • You can use SSL protocol to encrypt • Consider and address authentication and authorization to ensure valid users access and manipulate the data within the stream • Host-based access control • User authentication

44. Oracle HTTP server SSL configuration • ssl.conf includes the SSL definitions and virtual host container. • It is located at: • UNIX: ORACLE_HOME/Apache/Apache/conf • Windows: ORACLE_HOME\Apache\Apache\conf

45. Understanding Host-Based Access Control • You use the deny, allow, and order directives to set this type of access control. <Directory /internalonly/> order deny, allow deny from all allow from 192.168.1 us.oracle.com </Directory> • requests originating from any IP address in the 192.168.1.* range or with the host name us.oracle.com are allowed access to files in the directory /internalonly/

46. Access Control for Virtual Hosts • IP-based, Name-based • place the AccessConfig directive inside a virtual host container in the server configuration file, httpd.conf ... <VirtualHost ip.address.of.host.some_domain.com> ... virtual host directives ... AccessConfig conf/access.conf </VirtualHost>

47. Overview of Host-Based Access Control Schemes • Controlling Access by IP Address • Controlling Access by Domain Name • Controlling Access by Network or Netmask • Controlling Access with Environment Variables

48. Controlling Access by IP Address • To configure IP address-based access control, use the syntax shown in the following example: <Directory /secure_only/> order deny,allow deny from all allow from 207.175.42.154 192.220.208.9 </Directory> • In this example, requests originating from all IP addresses except 207.175.42.154 and 192.220.208.9 are denied access to the /secure_only/ directory.

49. Controlling Access by Domain Name • To combine domain name-based with IP address-based access control, use the syntax shown in the following example: <Directory /co_backgr/> order allow,deny allow from all # 141.217.24.179 is the IP for malicious.cracker.com deny from malicious.cracker.com 141.217.24.179 </Directory> • In this example all requests for directory /co_backgr/ are accepted except those that originate from the domain name malicious.cracker.com or the IP address 141.217.24.179.

50. Controlling Access by Network or Netmask • You can control access based on subsets of networks, specified by IP address. <Directory /payroll/> order deny,allow deny from all allow from 10.1.0.0/255.255.0.0 </Directory> • In this example, access is allowed from a network/netmask pair.