Re: Database security
- From: Paul Drake <discgolfdba@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Tue, 16 Mar 2004 16:59:27 -0800 (PST)
--- Jared.Still@xxxxxxxxxxx wrote:
> List,
>
> Here in the midst of Sarbanes Oxley, I've been
> pondering methods
> that might be used to prevent a system administrator
> from connecting
> to any databases running on that box.
>
> I know that it is possible to setup Oracle on
> Windows so that without
> a password, you cannot logon to the database as
> sysdba.
>
> eg. sqlplus "/ as sysdba" will require a password.
>
> The caveat to this is that the SA can simply:
>
> * stop the Oracle service
> * change the init.ora parm
> remote_login_passwordfile to 'none'
> * start up the database
> * create a dba account
> * shutdown the database
> * re-enable the password file
> * restart the database
>
> That won't get you SYSDBA, but it will get you DBA,
> which is probably
> enough
> for any nefarious activities.
>
> On *nix it is a bit different of course. Anyone
> with root can simply su
> to oracle.
>
> I have been perusing Pete Finnigan's "Oracle
> Security Step-by-Step" but
> have
> not yet found information pertaining to this
> particular topic, other than
> revoking
> privs from the DBA account. That action is not
> applicable here, as the
> team of
> DBA's consists of me by myself.
>
> And TIA Mladen, but I already know how it works on
> unix, and that MS is
> the
> dark side of the force, but is unfortunately what I
> have to live with.
>
> Jared
Jared,
I wish we would have talked this over last week while
enjoying a tasty beverage.
DBA and SYSDBA are different animals.
The quick answer is, you can't do it.
You can prevent the (MCSE) Domain Admin from
connecting to an Oracle database instance on a win32
box, when it really isn't a windows box anymore. that
takes alot of work and testing. If he can gain access
to the server room, you can't stop him.
The verbose answer is, you can make it a large PITA
for him to get into it, but the a user having local
administrator can re-grant the local ORA_DBA or
ORA_%ORACLE_SID%_DBA group to the administrators local
group or their account, or could construct a new
password file and connect as sysdba.
You can setup the filesystem permissions such that the
local administrators cannot access the oracle files
(at client sites I allow them read access for backup
purposes, via a local OPER group).
You can audit permissions changes to filesystems.
But you cannot prevent a member of the local
administrators group from clearing the log files, e.g.
security event log.
You can, however, run a syslog client to send such
messages to a *nix box, that a local administrator of
the win32 box (or Domain Admin) could not access. If
you have a security administrator, I'm sure that you'd
muck something up in PERL to send them alerts for such
things in an automated fashion, hopefully not thru the
local MS Exchange server that the evil MS SysAdmin
could also compromise (or already manages).
Now, if the SysAdmin grants a local group to his
account (or local group) or takes ownership of files -
it will show up in the log files on the *nix box.
It depends upon what you are trying to accomplish.
If you simply want to be able to track that a user has
gained access as sysdba, the event logs already
include such information, just get that information
off of the box in real-time fashion. That may be
sufficient for your purposes.
If you seriously want to prevent the Admin from
accessing the database files, you're going to have to
prevent him from accessing any of the backup sets
(including those at rest, on tapes at the offsite
location, etc). That is pretty much impossible without
encrypting the data.
I have done alot of work on making Oracle on Windows
as secure as possible. Some of it as an exercise, some
for real. I had a w2k box that only had one port
listed in a netstat command output, that was the
listener's.
The box was not real useful outside of the listener
and the instance (which is good).
Have you considered, removing the box from the domain,
so that it is in its own workgroup, (thinking clean
re-install) and not granting any accounts out to any
others?
After Nimda hit our network (years ago), all the
oracle servers that were win32 left the domain, and
had netbios ripped out (as well as the server service,
etc.).
If the SysAdmin has no accounts to log onto the box,
then he's not really the SysAdmin anymore. You would
be. caution.
That is the responsibility that I assumed (took) here
years ago. Its alot of work. Careful what you wish
for. I get to apply the hotfixes, change the virus
software, verify that the backupsets were transported
to the staging servers, read the logs.
It meant that the developers no longer had access to
/udump. That is a large price to pay for OS and
filesystem security.
The developers do get access (via ssh) to the new 9.2
dev db running on RHEL 3.0 ES. All ports on that are
closed off below 1024 except for ssh (this is a box on
the internal LAN, and yes, I still run a firewall on
the box).
There is no rpm for sendmail on the server.
There is no rpm for bind on the server.
I did open everything above 1024 tcp so that dedicated
server processes could be obtained and I would not
want to ask anyone to read a trace file created via a
shared server. If it turns out that we're only using
ports below 4000, I'll tighten up the range that
iptables is accepting incoming connections for tcp.
time for beef and beer.
Paul
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
