My employer has a freeware utility you can run on your network to find and document instances of SQL Server. One of SQL Server’s primary advantages is also one of its primary disadvantages – you can spin one up in a manner of minutes.
To grow deals at a company buying our SQL Server software, we’d offer to document their servers for them. They would claim they only had 10-15 instances of SQL running. We’d run our utility and return with closer to 100-150 instances. Oops!
I was recently asked if we had a similar tool for Oracle. I was a bit taken aback, and my gut reaction wasn’t a very good one.
Wait a sec, most orgs know EXACTLY where they have Oracle running
To answer the question though, “No, we do not have such a tool. This is not a primary concern for our Oracle customers.” But, I was curious and really wanted to find out if there was such a tool, or if DBAs worried about such matters.
A quick Google proves mostly unfruitful. I found one promising lead via a blog post in 2005 from Oracle security expert, Pete Finnigan. Unfortunately going to the download page prompts me for a login, although to be fair it is over 6 years old.
So, am I naive to think that it’s much harder to sneak an instance of Oracle database onto a network? A quick Twitter conversation sprouted up, and apparently it does happen. Or at least, production DBAs are rudely awakened to the presence of unknown databases popping up. Oh, and people normally find these databases when the owner sticks their neck out and asks for help.
What do you do after you find them?
To the victor go the spoils? Do you really want ownership of a database that probably hasn’t been well maintained? In terms of job security I would think having more resources in your domain would be a good thing. On the flip side, most Oracle DBAs aren’t exactly short on work.
A lot of sites have an Enterprise agreement with Oracle that allows them to deploy an unlimited number of databases. Users hear this, and then decide to build a local application using Oracle, and the word never makes it to the IT Support team. The company starts to rely on the service this new app is supplying, and all of a sudden IT is now responsible for another database it never even knew about!
Again, this is a scenario I hear over and over in the SQL Server world. Usually it involves 3rd party vendor apps that use SQL Server. But is this problem just as rampant in the Oracle world? Share your horror stories, and better yet, let us know how you audit your Oracle installs. Have a script, use a tool? Don’t be greedy now!
2 Comments
In reality, you’re thinking too small with respect to whether or not Oracle is installed. It’s not just the fact that I might have to support a poorly maintained database that’s the concern. Oracle continues to have numerous security patches. And chances are Oracle installations the DBAs don’t know about aren’t getting patched. I can recall a pen-tester showing me he could quickly exploit a vulnerability to TNS Listener and escalate to the service account Oracle ran under. Shortly thereafter, he had the box. That was his foot in the door.
How easy is it to spin up an Oracle installation? Just about as easy as it is to spin up a SQL Server one, especially since you can get a copy of the install media for free (or at least, you used to). And chances are if a developer is working with Oracle on a production application, he or she has it installed on the local workstation, too. I compromise the workstation, run under the developer’s account, and since developers tend to have access to production data… you got it.
Once you know how, it is pretty easy. Still not as easy as SQL Server, esp if we’re not talking Windows.
Points taken and then some on the security aspect.
So how do you manage Oracle installs?
I advocate developers installing local copies of Oracle all the time. Maybe I should add a few words about keeping it properly patched, or locking down the listener to local connections only.