Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Securing Oracle system/sys access on Windows 2000

I was wondering if you could advise me on securing Oracle system/sys access on Windows 2000? I have found that if you can access the server, then you can stop the service for the instance (OracleService <SID>), delete the password file and recreate it using ORAPWD, where you supply a password. You can then use ORADIM to edit the service with the new password. Once you then start the service you can use the new password to access the sys account. Is there any way to prevent this, or must I ensure that system administrator has secured the server properly?
You've asked a great question as I've run across many sites that have this same issue. I'm no Windows expert, but I think that Windows provides mechanisms to prevent the type of scenario you present. However, it seems that many sites still treat Windows as a desktop OS and figure that if you can login to the host at all, then you should have administrative rights.

The first thing to ensure is that you limit access to the Administrators or Domain Administrators group carefully. I think that's how most people get the escalated privileges that allow them to stop/start services and the like. That is, pay careful attention to *how* you are accessing the server--with what credentials or account. A non-privileged user (not a member of an administrative group) should not be able to stop services.

As for the password file, I think you're right that Oracle doesn't take good care of NTFS file permissions to ensure that files remain secure. I believe that this got a lot better in 9.2, but I still don't think it's perfect. With most of the Windows systems I've worked on, any new files created allow Everyone Full Control. Maybe there's a way to change this default behavior, but I haven't seen it done yet. That said, I don't think that you're required to leave the default permissions as they are. You should restrict permissions to the %OH%database directory and to the password file as well and see how restrictive you can make them without breaking the database server. I don't have any Windows systems to test with, so you'll have to check this one yourself.

You might consider setting remote_login_passwordfile = NONE if you don't require it. I know that on other (non-Windows) platforms, there is no requirement to have a password file in order for the server to function. I don't see why that would be different on Windows.

Finally, your last comment is especially bothersome. I think that no matter what steps you take as the DBA to secure the database and its various files, you should always ensure that the system administrator secures the server as much as possible. Security in the database doesn't help at all if someone can steal the whole server. I think that most of the concerns you describe are things that Oracle maybe could do better, but could easily be addressed by restricting access to the server. Beware that your concerns are valid and it's great that you're thinking about them (not everyone does), but there are also many other potentially easier targets that will be more damaging. For example, if your application has a database super-user that owns all the data and has a password equal to the username. If that's true, you can build the most secure box on the planet and as long as you run a listener, it's still game over.

Dig Deeper on Oracle database security

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.