Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

The Best Oracle Resource on the Web

An Enterprise Security Primer

by Donald K. Burleson
 

2015 Update - For a complete treatment of the topic of Oracle security on the web, see these books and resources:


 

 

For many system administrators, the terms "open systems" and "security" can seem impossibly opposite. Maintaining security for a centralized database system is difficult enough, and when faced with a network of networked databases, maintaining a level of access and update security is a formidable challenge. Security is often an afterthought, and the database industry is plagued with sub-standard security, especially for enterprise databases that are cobbled-together as a result of external factors such as corporate acquisitions.

There are many problems with security for enterprise databases, far more than the IT industry would care to acknowledge. These security exposures stem from the following architectural issues:

  • Multiple entry points Unlike a traditional centralized database, web-based databases have many entry points. These entry points include web servers, VPN access, app server access and access to databases via web portal protocols. When dealing with literally hundreds of entry points, special care needs to be taken to insure that harmful viruses are not introduced into the system.
     
  • Weakest link problem The recent publicity regarding security holes in enterprise security underscores the weakest link problem. When dealing with such a wide variety of entry points and platforms, the overall system security is only as secure as the weakest link in the federation. No matter how much care is taken to insure security at the database level, problems can still be introduced from a variety of other sources. For example, once a hack get root access to a web server, it is often easy to gain access to the database server, especially when remote shell capability is enabled.
  • Web-based databases Database that are configured to allow external communications from other web portals face an exceptional data security challenge. Hacker can constantly attempt to hack into web portals, eventually locating a weakness in the Net Services architecture.
When we speak of security, we must define the scope of security. Security means different things to different managers, and we must clearly define the scope of security.
  • Server access security
     
  • Internet access security
     
  • Database access security
     
  • Data privacy security
While few security systems are perfect (the exception being the retinal eyeball scanners used by the U.S. Department of Defense for top-secret systems), there are some things that can be done to decease the likelihood of a security breech. Many of these methods are time-consuming and slow down the runtime system, so careful thought must be given to these solutions before implementing them in a production environment. Let's explore each of these areas and see some common security problems.
 

Server Access Security
 

Server access security refers to preventing unwanted access to the server environment and ensuring controlled access to the IT staff. There are several technologies that are employed to assist with external server access:
  • Kerberos security This popular "ticket"-based authentication system provides password-based server access authentication.
     
  • Authentication servers (Radius servers) Secure authentication servers provide positive identification for external users.
     
  • Password security consolidation Many vendors offer tools to consolidate passwords among dozens of servers.
Obviously, all security must start at the server level. The IT manager must provide reliable access methods for IT staff members while ensuring that the database is not open to external threats. Let's start by looking at internal server access tools:
  • Call-back access Using this technique, the IT staff member calls a phone number, enters a password, and the server calls them, thereby ensuring that access is always with pre-defined phone numbers.
  • Time-based access cards This scheme is commonly used by banking institution and classified government systems. A credit-card sized timer is given to each IT employee that generates a new password every 60-seconds. The card is synchronized with a server-side password change routine.
     
  • VPN access Using Virtual Private Networks, IT staff members can gain access to a server using secure shell (ssh) protocols.
However, even all of these precautions do not always prevent un-wanted hacker access, especially for web-enabled databases. There are many ways that a malicious programmer can bypass the security of a database. The media is full of reports of adolescent hackers who have breached top-secret systems, and even the major database vendors have been plagued with bugs that allow external hacker access to web servers and app servers. While there are new approaches to breaking into systems being developed constantly, there are some general categories of methods.

 

There are a large variety of vendors that offer tools to manage internal IT security. Listing 1 shows an alphabetical sample of the major security vendors. As we can see, there is a huge amount of choices in security software.

 
AuthAPI (Entact Information Security)
Cicso Secure Policy Manager (Cisco Systems)
Control-SA (BMC Software)
Control-SA/Links (BMC Software)
Enterprise Security Administration (Computer Associates)
Enterprise Security Manager (Axent Technologies)
Lucent Security Management Server (Lucent Technologies)
OpenEdition DCE Security Server (IBM)
Open e-Security Platform (e-Security)
PassGo CUA (Axent Technologies)
ProtectIT (Computer Associates)
Resource Manager for UNIX (Axent Technologies)
SecureWay Policy Director (IBM)
Tivoli Security Management (Tivoli)
Unicenter TNG (Computer Associates)
VACMAN Radius Server (Vasco Data Security)

Listing 1: A list of IT security vendors

 

Internal Passwords and Database Security

In an open system environment, system access is controlled at the network sign-on level, the individual work station, each database within the federation, as well as each application.

If possible, servers should not be accessible over the Internet unless network and systems administrators have followed the general guidelines for authenticated external access. Some companies use domain servers to restrict server access to specified users. However, hackers still might intercept user IDs and passwords. To prevent this, many companies employ tools that utilize secure shell (ssh) technologies to encrypt external Internet communications. The most popular of these tools is SecureCRT, which gives authorized users Internet access to servers without the fear of someone capturing the user ID and password.

Secure shell tools use sophisticated Huffman cryptography techniques for Internet transmissions; these products are more secure even than the Enigma code that was used during World War II. However, such superb encryption sometimes lulls IT staffs into believing that they are protected from external attack. Remember, the bulk of the security is at the server firewall, not on the Internet.

 
There has been a great debate about the effectiveness of requiring frequent password changes. Advocates argue that it reduces the likelihood that the user will use easily guessed names. Those against enforced password changes point out that the frequent changes may be seen as obtrusive by the end-user and also require the forgetful end-user to write down their current password. With so many possible ports of entry, effective ID management can be quite difficult. Invariably, all of the password control mechanisms have significant problems:
 
  • Password changing routines Many shops have discovered that when a user is forced to provide multiple passwords for each component in an enterprise database, they commonly compromise system security by choosing passwords that are cyclic in nature. For example, a user may rotate between the passwords "north"," south", "east" and "west" in order to avoid having to keep track of the multiple sign-on's to all of the system components. More sophisticated password devises require the end-user to specify passwords of a minimum length, (greater than five characters), prohibit the re-use of passwords and require that the passwords are changed on a periodic basis. One approach that has been especially effective is to link the password changing software with the user's personnel records so that the names of family members, street addresses, and other easily guessed information may not be included in the password.
  • Automatic account disabling If you suspend the server ID after three password attempts, attackers are thwarted. Without user ID suspension, an attacker can run a program that generates millions of passwords until it guesses the user ID and password combination.
  • Random password generators This is one of the most problematic mechanisms of all, and virtually guarantees that your staff will have written lists of passwords. For example, consider the following screen (refer to Figure 1).
 

Figure 1: An ineffective random password generator

 
Without a centralized security component, the end-users are forced to write down all of these passwords to each system component in order to manage the complexity of remembering all of the passwords. While this strategy is a tremendous headache for the end users, it does ensure that system-wide security is not jeopardized through a single breech. In system-wide security environments, security tables are kept which allow the end user to specify their user ID and sign-on once, and the security subsystem automatically manages their access to networks, operating systems, databases and applications.

There are two basic approaches to password security. The first and most common approach utilizes a common security system (refer to Figure 2). This security system maintains a single password, and controls access to all of the system components. This idea has been borrowed from ancient mainframe systems such as RACF and ACF2.

 

Figure 2: Internal Password propagation

 
While this is a great simplification for the end-user of the system, it also increases the risk that a security breech to the system-wide security could have widespread ramifications. One downside to this approach is that a failure on the processor that contains the propagation routine could conceivably lock-up the entire enterprise. Another potential problem with centralized security is the possibility that a user might de-encrypt a password on one component, thereby gaining access to the entire federation.
Another method for controlling security is to make each of the distributed systems components access the security tables directly (refer to Figure 3). This eliminates the exposure of having redundant passwords stored in each processor and provides a simple point of control for the entire federation.

Figure 3: Centralized password security

 

This approach requires user-exits to be installed at the level of each sign-on, at the network, operating system, and database level. The security files of each component continue to exist, but the password fields contain random, unchanging values. While it is nice to have a single point with which to control security, there is also the possibility that a failure on the security system would block access to the entire federation. To alleviate this potential exposure, security tables are stored redundantly on two processors, and a failure on one processor will trigger the security mechanism to check the other processor. Security at each level of the system is still maintained because each individual security component is still active, with random passwords that are never actually used for signing on to the component.

Auditing External Security

With such complexity, many IT manager employ security experts and professional white-hat hackers to ensure that their security is bullet-proof. Such checks usually involve the following areas:
 
  • Firewall security assessment
     
  • Enforcement of Network security policies
     
  • Router security checks
     
  • Review of Kerberos and remote authentication servers
     
  • Review of network security policies
     
  • Review of UNIX vendor security updates
     
  • Password strength checking
     
  • Use of UNIX shadow passwords
     
  • Checking for improper rhosts connectivity
     
  • Checking sticky bits for exposures
Of course, security is more than for internal IT staff. You must also provide access over the web to end-users from all over the world. Let's explore this issue.

 

Web-based Access Security
 
Today's Web architectures include four layers of servers: Web listeners, Web servers, application servers, and database servers. Each of these layers is vulnerable to hacks.

Figure 4: A four-tiered eCommerce architecture (courtesy Builder.com

In general, security concerns over Internet access are similar to security issues in an internal network. To understand the similarity, let's examine the entry points for hackers and demonstrate show some techniques that attackers use to gain access to confidential data. All Web-based applications have numerous possible entry points, and security must be enforced at each level. Hackers look at the following areas when they try to break into a Web application.
 
  • Internet access If hackers can guess the IP address of a server, they can telnet to the server and get a login prompt. At this point, all they need is a user ID and password to gain access to the server.
     
  • Port access All Web applications are configured to listen on a predefined port for incoming connections, and they generally use a listener daemon process to poll for connections.
  • Server access A four-tiered Web application incorporates a series of Web servers, application servers, and database servers. Each of these servers presents a potential point of entry, and if remote shell (rsh) access is enabled, a hacker that gets access to a single database may get access to many servers.
  • Network access OracleNet, as an example, allows for incoming connect strings to the Oracle listener process. If hackers know the port, IP address, Oracle ID, and password, they can gain direct access to the database.

After you identify possible attack points, you must restrict access to those points and disabling external entry can be accomplished though several methods. Next, let's examine web-based security access.

Ecommerce security is especially important for Web-based databases where hackers can gain complete control of the environment. Many managers are justifiably concerned about opening up mission-critical applications to the Internet. With dozens of potential entry points and almost daily news about large companies being hacked, proper database security is critical.
  • Web port access security All applications are directed to listen at a specific port number on the server. Like any standard HTTP server, the Web Listener can be configured to restrict access.
     
  • XML-based access security The latest trend among web-enabled database is in the area of Web services, specifically the inter-communications between databases over the Internet. We have the Microsoft .NET initiative and web service tools offering to assist in managing security between web portals. Most of these use XML security to verify communications across an insecure network.
Internet hackers are constantly searching for servers to attack. To do this, the hackers write simple scripts that randomly generate and ping IP addresses, looking for servers that respond with an "ack". The response is called a "ping acknowledgement" and is a standard feature of the TCP/IP ping utility. For example, here we ping the IP address for a major eCommerce database web server:

C:\ ping 172.234.33.101
 
Here's the output:

Pinging 172.234.33.101 with 32 bytes of data:
Reply from 172.234.33.101: bytes=32 time=164ms TTL=254
Reply from 172.234.33.101: bytes=32 time=162ms TTL=254
Reply from 172.234.33.101: bytes=32 time=170ms TTL=254
Ping statistics for 172.234.33.101:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 162ms, Maximum = 170ms, Average = 165ms

The acknowledgement packet tells the hacker that there's an active server at this IP address. Next, the hacker simply uses the telnet utility to go to the server and begins a series of attempts to hack the root or the Oracle user password. The best way to foil this type of attack is to disable all server accounts after three password attempts.

 
Below you'll find the pseudocode for a UNIX shell script to cruise the Internet for vulnerable servers. I have deliberately obfuscated the actual code as a courtesy, but this script should give you the idea. Hackers run such scripts as daemon processes and they can scan hundreds of thousands of IP addresses every hour. Please note that I have deliberately introduced syntax errors into the pseudocode routine to prevent it being used by any potential hackers.

/*#/bin/ksh
while true
do
#****************************************************
# Generate a random IP address
#****************************************************
$IP_ADDRESS=rnd(1-255).rnd(1-255).rnd(1-255).rnd(1-255)
#****************************************************
# Submit the IP address to the ping command
#****************************************************
nohup ping $IP_ADDRESS > /tmp/t.lst 2>&1 &
#****************************************************
# If ping is responding - start the attack
#****************************************************
if `cat /tmp/t.lst|wc -l` > 0 then invoke attack_routine
fi
done


Even a novice computer user can write an attack program and locate server attack opportunities, and the average 12-year old knows the fundamentals of a denial of service (DOS) attack. Although the main method of attack is directly from the IP address, some creative hackers gain entry with I/O-enabled Java applets or programs that compromise cookie-writing. To prevent these types of external attacks, savvy companies employ some of the following techniques:
 
  • Use trusted IP addresses UNIX servers are configured to answer only pings from a list of known and trusted IP addresses. In UNIX, this is accomplished by configuring the rhosts file, which restricts server access to a list of specific users.
  • Special tools Products such as Zone Alarm send an alert when an external server is attempting to breach your firewall security.
    Let's, let's drill-down deeper and explore database security.
     
Database Access Security

Database access security refers to the access controls placed upon the end-users of the database. Database access security is generally customized at the database level through a variety of methods:

  • Internal role-based security Specific object-level and system-level privileges are grouped into roles and granted to specific database users. Object privileges can be grouped into roles, which can then be assigned to specific users.

     
  • Grant-execute security Execution privileges against database procedures can be tightly coupled to specific users. When a user executes the procedures, they gain database access, but only within the scope of the procedure. Users are granted execute privileges on functions and stored procedures. The grantee takes on authority of procedure owner when executing the procedures, but has no access outside the procedure.
     
  • Application-level security This type of access control is popular with ERP solutions such as Oracle Applications and SAP. With application level security, the app servers establish pre-spawned connections to the database, and the app server manages connectivity to the database layer.
     
  • Data Privacy Security
    Data privacy security is the off-shoot of stringent US privacy laws such as HIPAA. Under US HIPAA rules, all database access must be tracked and complete audits must be made of all updates and retrieval of sensitive information. There are a variety of techniques used for this challenge.
     
  • Update auditing Many database managers use the database recovery logs (redo logs) as an audit trail for database updates. The database logs record every change to the database and information about who made the change. Examples of such tolls are Oracle LogMiner and BMC's SQL-Backtrack
     
  • Schema change auditing Many databases provide methods for tracking every change to a database schema using system-level DML triggers. Here is a link to DBAZine article on DML tracking for Oracle
     
  • Virtual private databases VPD technology can restrict access to selected rows of tables. Virtual Private Databases (fine-grained access control) allows for the creation of policies that restricts table and row access at runtime.
     
Many companies are developing security systems that ties security to the data that feeds the enterprise applications rather than the applications themselves. This data-level approach insures that the database controls access to the data and eliminates the possibility that someone may bypass the application and the security.
Conclusion
Database security has become a very critical task, and the MBO goals of many IT managers require that they lock-down security at the server-level, web-level and database level. However, with a plethora or choices, the IT manager must make a decision regarding the best security techniques and tools that will be cost-effective and also provide the desired levels of security.

In our next installment, we will examine the Oracle9i suite of security tools and look at how they are used in Oracle environments to ensure proper database security and access control.


 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational