RE: How to keep "root" out?

[Mladen Gogala]

Title: Message

Nope. It's against the law of evolution. SA has to work hard evolve to become a DBA. The regular, unevolved specimens

of systemadministraticus vulgaris would be bored to death on this list. It's about the survival of the fittest, remember?

 

 

--
Mladen Gogala
Oracle DBA

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Ji
Sent: Friday, August 29, 2003 12:29 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: How to keep "root" out?

We assume the SA don't know much about Oracle.  But if some one is particularly interested in

getting into the database, he might be on this list as well learning all our defense mechanisms. :)

Or doesn't have to be subscribed to it since this list is mirrored other places and google is his friend.

I think the bottom line is, if you absolutely don't want the data to be seen, encrypt it.

 

My 2 cents.

 

Richard Ji

-----Original Message-----
From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]
Sent: Friday, August 29, 2003 10:31 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: How to keep "root" out?

Walt,

 

Something that has not been suggested - migrate your database to 9.2.  Connect as internal goes away.

 

Other than that, I think the best suggestion you got was a conversation, and granting access to the v$ tables thru a specific account for that person.

And then put a long trigger in place tracking all connections to the database.  Keep track of all SYS connections.  At least you know when things happen.  And periodically review the init.ora file for the database to make sure that nobody changes anything.

 

Good Luck!

 

Tom Mercadante
Oracle Certified Professional

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2003 4:50 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: How to keep "root" out?

But someone determined to get in the database can simply edit sqlnet.ora

"Tanel Poder" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED]  08/28/2003 10:24 AM  Please respond to ORACLE-L

To:        Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>         cc:                 Subject:        Re: How to keep "root" out?

Hi!
 
Put sqlnet.authentication_services = none in your server's sqlnet.ora. Then everyone has to use a password.
 
Tanel.
 
----- Original Message -----
From: Walter K
To: Multiple recipients of list ORACLE-L
Sent: Thursday, August 28, 2003 6:34 PM
Subject: How to keep "root" out?

Just for grins, I'll ask this question... Is there any way to keep the Unix "root" user from logging into the database (i.e. connect internal or / as sysdba)? Currently using 8.1.7.4 on Solaris 8 here.
 
We have a couple people in our Unix admin group that feel the need to "help" by writing their own DB monitoring scripts. Of course, they don't know what they're talking about. They do not have formal logins for the database, but since they are root users they are connecting via "connect internal". This is not only counterproductive but actually a potential security issue--just because someone has root doesn't necessarily entitle them to see the data in the database. What if it is a payroll database?
 
So, I'm curious, is there any way to prevent access via "connect internal" or "/ as sysdba"?
 
Thanks in advance.
 
W

 

Note:

This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.