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.
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.
-
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.
-
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.
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.
|