Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> OS Authentication
        
(Message started by: Pete Finnigan on Jan 30^th, 2008, 4:23pm)

Title: OS Authentication
Post by Pete Finnigan on Jan 30^th, 2008, 4:23pm

Good morning folks,

I'd like to know your thoughts on the use of OS authenticated accounts (not Remote OS authenticated) and the OPS$ prefix. As many of you probably know, OPS$ allows a single database account to either log in locally via OS authentication or via a database password if connecting remotely. It has been deemed to be a security vulnerability to use OPS$ accounts because, "When set to the value “OPS$”, accounts defined with the prefix of “OPS$” may authenticate either with a password or with OS authentication. Setting this parameter to a value other than “OPS$” allows only those accounts identified EXTERNALLY to authenticate to the database without providing a password."

I disagree with this assertion. Currently, we have both OS authenticated accounts and regular database accounts for each of our DBAs just to avoid using OPS$ accounts. This enables them to run scripts or even cronjobs on the database server without resorting to clear text passwords, extensive encryption on password files, etc. They can also connect remotely to pull audit records for review, etc, as needed. I do not see how avoiding the use of OPS$ is more secure. In fact, having to use 2 accounts to enable us to perform the same functions simply increases our account management. If someone has insight into why OPS$ accounts should be avoided, please post your reasoning.

Thanks in advance.

Title: Re: OS Authentication
Post by Pete Finnigan on Jan 31^st, 2008, 11:08am

Hi,

I am for and against OS authenticated accounts. I always say never use remote_os_authent of course but you would be surprised how many sites i see this being used. In the case of locally OS authenticated accounts, they are fine if they are designed and used for a specific purpose, i.e. run cron job or other form of batch job perhaps written in Pro*C. They are fine if they are designed for purpose and have the least privilege principal defined during that design.

Using them for DBA accounts well, always edges me to say no. The reason being is that you have potentially increased or at least changed the attack surface, probably changed is a better description. The authentication has moved out a layer to the OS. If you are going to use OS authentication then use it for a specific purpose and even go as far as to lock the OS account if its used for a cron job or similar.

If the issue is holding passwords in files, i.e. thats what stops the use of a database authenticated account then there are other options. The use of a tool such as OPR is great as it allows the password to be stored securley and retreived and also allows the database accounts to be associated with the OS account. There is an argument that this is similar to OS authentication anyway as once the password is in the repository it can be used with a slash logon. The Oracle mkstore uses a similar technique but uses the wallet to store the password and has the same issue. An alternate technique is to use dbms jobs or at worse the scheduler to allow the jobs to be controlled from the database.

Now to the use of OPS$ and the possibility to have an account authenticated in the database and also in the OS. There are two issues with this. First the attack surface in this case has been increased. There are now two vectors not one, somepne can gain access to the OS account and connect or they can gain access (or guess) the password and connect.

The second issue is that once the password is set it makes it slightly harder to identify external accounts. This is not the main issue though the first one is.

MY two penneth, avoid OS authentication if possible, it pushes the authentication out a layer and if joined with DB autentication increases the attack surface.

hth

cheers

Pete

Title: Re: OS Authentication
Post by Pete Finnigan on Jan 31^st, 2008, 3:27pm

Thanks for the reply. BTW, not sure if I stated it, but this is on HP UNIX servers with a dedicated VPN.

I did take the approach of creating special locked OS accounts for recurring cron jobs. So the only way to get to the OS account itself is via root. I also ensure there are no OS accounts except the SA, DBAs and these special application accounts on the production servers. For all practical purposes, if any of those accounts are hacked, no matter what I do, the person will have the ability to sudo to root and thus be able to affect the database however they want. This affectively means the increased attack surface by using local OS authentication is a push since any user account hacked on the production server makes it all vulnerable no matter what other measure I have applied. The database account I'm more worried about are the database authenticated ones since we have external customers that can sqlplus into the database and try to guess passwords. Again, that's something I can't avoid since they have to be able to sqlplus to the database to perform their work. I did take the precaution of having password verify set for interactive accounts as well as require 15-30 character passwords. Hopefully the SAs do their part in identifying weak passwords for OS user accounts.

I have also made the argument that having password files, even in clear text but with directory/file permissions which only allow the locked OS account to access them is as secure as the other open OS accounts. However, the powers that be disagree and insist we must have encryption password files but yet won't give us an approved tool to encrypt them with.

Based upon the additional information I just presented that I failed to in the original posting, would you still feel I'm leaving us open for attack (probably internal threat if anything)?

PS. What does hth mean? :P

Cody

Title: Re: OS Authentication
Post by Pete Finnigan on Jan 31^st, 2008, 5:45pm

Hi Cody,

Thanks for your reply. hth means, "hope this helps" - I think you have summarised the issues, the fact is by having OS and DB authent fior the same account does increase the surface. Whether you can rely on the fact that OS accounts are locked and you can only sudo to them and SA and DBA and worse external people have set strong passwords is the weak link in the process. If you have a process that checks these accounts for weak passwords, checks that the OS accounts are in fact locked, and a process to check DB passwords are strong then you have made it better. But as you point out the risk nowadays is internal. IF (big IF) the DB password is weak then someone can start to guess it, the OS may be locked and strong but thats effectively bypassed if the DB password is weak.

I dont see why you need dual authenticated accounts - if these are DBA like accounts I would avoid the OS authentication altogether and stick with DB ones. If these are used to run jobs then by all means create a seperate OS account with least privs and use that but not dual as a DBA account as well.

Why not use mkstore, its Oracle's product and part of ASO so should not require approval?

cheers

Pete

Title: Re: OS Authentication
Post by Pete Finnigan on Feb 1^st, 2008, 12:09am

Several comments about OS authentication.

OS authentication could be safer than DB authentication if the OS password
rules are strong (password complexity and length, aging, etc.) In other
words, there should be a company algorithm for passwords, and the same
algorithm should be effect for any platform, whether that platform be
database, OS, or applications. The problem with Oracle DB passwords is that
their hashes are visible to some users in sys.user$ in 11G, as well as in
DBA_USERS in 10G and lower. So that's why some would consider OS authentication to be a safer choice. (Depends upon local conditions.)

The problem with dual authentication is that I wonder if the owners know
they are established for both? On the other hand, if there is appropriate
aging applied at both levels, then it doesn't matter if they forget about
one. A blackhat would still need to know the password to obtain access, and
presumably strong password controls would be in place at account creation,
right? (I'm talking to people who care about security here, not the general case!)

The tougher question has to do with non-individual accounts. If somebody
comes across the network into the database as OPS$ORACLE, is it easy to
determine the individual who connected? I think not. Yes, you can chase
through the Listener log and audit entries and maybe get something (from
OS_USERNAME, USERHOST, HOST=, USER=), but it would much simpler if you could
mandate that any interactive work must be done via an account that maps to
one and only one individual.

I believe somebody I know said that if OPS$ was set to null, then accounts
could be established for local authentication but they could not be used to
connect across the network. I haven't had time to test that. Anybody
know?

Title: Re: OS Authentication
Post by Pete Finnigan on Mar 2^nd, 2008, 3:31pm

I disagree with this assertion. Currently, we have both OS authenticated accounts and regular database accounts for each of our DBAs just to avoid using OPS$ wowgoldboss

Title: Re: OS Authentication
Post by Pete Finnigan on Mar 31^st, 2008, 10:52am

Hi,

So you have two seperate accounts. Do you mean an OS account with true database OS authentication, i.e. the database account is identified external and you have a NULL os_authent_prefix or are you connecting as sysdba from an OS account in the OSDBA group? - plus you have a seperate database account?

In any of these scenarios you have increased the "attack surface" of the database as for one individual (or more) you have two methods (and accounts) to enter the database. Good security should always reduce the attack surface, reduce features, defaults, accounts, privileges etc.

cheers

Pete

Title: Re: OS Authentication
Post by Pete Finnigan on Apr 1^st, 2008, 2:49pm

For our site, I have the os_authent_prefix defined. We do lock the OS accounts which are application accounts. Remote authentication is disabled.