| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Database security
Thanks you Paul for the detailed info, and all others that replied.
You have pretty much confirmed what I thought to be true.
This supplies me with some solid material as we do gap analysis on our database security.
Jared
Paul Drake <discgolfdba_at_yahoo.com>
Sent by: oracle-l-bounce_at_freelists.org
03/16/2004 04:59 PM
Please respond to oracle-l
To: oracle-l_at_freelists.org
cc:
Subject: Re: Database security
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
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Tue Mar 16 2004 - 19:04:22 CST
 |
 |