Dear Readers,
My name is Franz Devantier, creator of this blog. I am an Oracle Certified
Professional (OCP DBA 11g) Security DBA.
I will be sharing with you the basic duties of an Oracle DBA, and also
some of the undocumented, and not so well known tasks.
I will make a deal with you: If you refer me to a company that needs
database support, from a few hours per week to full time, and I am able to sign
a contract with them.
Then I will give you 10% of the monthly
contract or deal price every month. When
the contract ends, and we re-sign the contract, I will again give you 10% of
the monthly contract price. This will go
on until the company no longer employs or contracts me or my agents to look
after their databases.
I can do this, because that 10% is my
marketing budget. When we re-sign the
contract, in the future, it may depend on you giving the thumbs up again, and
that is worth 10% of the monthly contract price, to be given to you as
commission.
Contact:
Franz
Security
Policies - Part 13
Restrict operating system access.
The first thing to do is to limit the number of operating
system users that are connecting to the server.
Limit the privileges of the operating system accounts. Limit the privileges of administrative, root
and dba on the Oracle database host or machine, to the least privileges needed
for the users tasks.
-> It is good practice to restrict the ability to modify
the default file and directory permissions for the Oracle Database Home
directory or the installation directory and its contents. Even privileged operating system users and
the Oracle owner should not modify these permissions, unless instructed by
Oracle Support.
-> Restrict the use of symbolic links were possible. When there are symbolic links, ensure that
all parts of the link belong to Oracle or a trusted user like root. Make sure that no part of the file or the
directory structure is modifiable by an untrusted user. It is good practice to protect all types of
files in this way, including data files, log files, trace files, external
tables, and bfiles.
Use a firewall.
You should keep your database behind a firewall. The Oracle network infrastructure also
provides support for a variety of
firewalls; such as proxy-enabled firewalls such as Gauntlet from Network
associates, Raptor from Axent. Packet
filtering firewalls such as PIX firewall from Cisco, and stateful inspection
firewalls (Sophisticated packet-filtered firewall) such as Firewall-1 from
CheckPoint. Then of course there is the
Oracle Database Firewall. The Oracle
network infrastructure used with oracle 8 was Net8, and then we moved on to
SQL*Net, and now we have the “Oracle Network Infrastructure”. The important point to remember is to use a
firewall, and keep your data protected behind the firewall.
Never poke a hole through a firewall.
If the database is behind the firewall, then whatever you
do, don’t poke holes in the firewall. For
example do not leave port 1521 open for the Oracle Listener to make a
connection to the internet or vice versa.
This is a well known port address, and so not very secure.
Leaving or poking holes in the firewall can introduce
significant security vulnerabilities; including more port openings being made
in the firewall, multi-threaded operating server issues, and the exposure of
sensitive data on the database behind the firewall.
An Oracle listener running without a password, may be
probed for crucial details about the databases on which it is listening, such
as trace and logging information, banner information and database descriptors
and service names.
All of the above information combined with a badly
configured firewall will provide an attacker plenty of opportunity to launch
malicious attacks on the target database.
For example, if the listener is not protected by a
firewall, then you can do this, and collect enough information to carry out
malicious actions:
C:\Users\fred>lsnrctl status
LSNRCTL for 64-bit Windows: Version 11.2.0.1.0 - Production
on 19-MAR-2013 21:56:20
Copyright (c) 1991, 2010, Oracle. All rights reserved.
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=MyDBA018)))
STATUS of the LISTENER
------------------------
Alias
LISTENER
Version
TNSLSNR for 64-bit Windows: Version 11.2.0.1.0 - Production
Start Date
19-MAR-2013 21:27:12
Uptime
0 days 0 hr. 29 min. 11 sec
Trace Level
off
Security
ON: Local OS Authentication
SNMP OFF
Listener Parameter File
D:\app\product\11.2.0\dbhome_1\network\admin\listener.ora
Listener Log File
d:\app\diag\tnslsnr\fred\listener\alert\log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\fredipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=fred-PC)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1521ipc)))
Services Summary...
Service "CLRExtProc" has 1 instance(s).
Instance
"CLRExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "fred" has 1 instance(s).
Instance "fred",
status READY, has 1 handler(s) for this service...
Service "fredXDB" has 1 instance(s).
Instance "fred",
status READY, has 1 handler(s) for this service...
The command completed successfully
Protect the Oracle listener.
The listener is the database gateway to the network, so it
is important to limit the consequences of malicious interference.
You can restrict the listener privileges to prevent it from
reading or writing files to the database or the Oracle Server address
space. This will prevent external
procedure agents spawned by the listener, from inheriting the ability to do
such reads or writes.
The owner of the
separate listener process should not be the owner that installed Oracle or
executes the Oracle instance, such as Oracle which is the default owner.
You can prevent online
administration by requiring the
administrator to have write privileges on the LISTENER.OrA file, and to
have the listener password.
Add this into the listener.ora:
ADMIN_RESTRICTIONS_LISTENER=ON
Then restart the listener.
You can use SSL when
administering the listener, by making the TCPS protocol the first entry in the
address list. For example:
LISTENER=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcps)
(HOST = fred.oracle.co.za)
(PORT = 8288)))
To administer the listener remotely, you need to define the
listener in the listener.ora file on the client computer.
For example to access the listener USER333 remotely, put
this in your client side listener:
User333 =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = tcps)
(HOST = fred.oracle.co.za)
(PORT = 8288)))
Always establish a secure, well-formed password for the
Oracle listener to prevent remote configuration of the Oracle listener. You can password protect the listener like
this:
LSNRCTL> CHANGE_PASSWORD
Old password: lsnrc80
New password: lsnrc90
Reenter new password: lsnrc90
LSNRCTL> SAVE_CONFIG
The command completed successfully
You can remove the external procedure
configuration from the listener.ora file, if you do not intend to use such
procedures.
Monitor the listener activity.
Monitor who accesses your systems.
Authenticating client computers over the internet is
problematic. It is better to use User
authentication, which avoids client system issues that include falsified IP
addresses, hacked operating systems or applications, and falsified and/or
stolen client system identities.
You can improve Client computer security:
-> By configuring the connection to use Secure Sockets
layer (SSL). SSL communication makes
eavesdropping unfruitful and enables the use of certificates for user and
server authentication.
-> set up certificate authentication for clients and
servers so that:
-> The
organization is identified by unit and certificate issuer, and the user is
identified by distinguished name and certificate issuer.
-> The
applications should test for expired certificates
-> Certificate
revocation lists are audited.
Check network IP addresses.
You can use the Oracle Net “valid node checking security”
feature to allow or deny access to Oracle Server Processes from network clients
with a specified IP addresses. In order
to use this feature, you can set the following parameters in the protocol.ora
file, which is the Oracle Net Configuration File.
TCP.VALIDNODE_CHECKING = YES
TCP.EXCLUDED_NODES = {list of IP addresses}
TCP.INVITED_NODES = {list of IP addresses}
The first parameter turns on the feature. Parameters 2 and 3 deny and allow specific
client IP addresses from making connections to the Oracle Listener. This is a useful strategy in preventing
potential denial of service attacks.
Encrypt network traffic.
You can use Oracle Advanced Security to encrypt network
traffic between clients, databases, and application servers.
Oracle Advanced Security is available with the Enterprise
edition of the Oracle Database. It
installs in typical installation mode, and can be configured, with the Oracle
Net Manager tool or by manually setting six SQLNET.ORA parameters to enable
network encryption. There is of course a
licensing aspect to Advanced Security.
Harden the operating system.
You can harden the operating system by disabling all
unnecessary operating system services.
Both UNIX and Windows platforms provide a variety of operating system
services, most of which are not necessary, for the Oracle application or
deployment. You can definitely disable
services like FTP, TFTP, TELNET.
Remember to close both the UDP and the TCP ports for each service that
is being disabled. You need to disable
both types of port in order to make the operating system more secure.
Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com
Classifieds
No comments:
Post a Comment