Sometimes I think that people think of security, especially database security, as a domain for the highly-skilled consultant. However, sometimes it is the most basic little things that need attention and it doesn’t require a high-priced, highly skilled consultant to figure it out. Case in point: I recently arrived at a new customer site to … Continue reading “Security can be basic”
Sometimes I think that people think of security, especially database security, as a domain for the highly-skilled consultant. However, sometimes it is the most basic little things that need attention and it doesn’t require a high-priced, highly skilled consultant to figure it out.
Case in point: I recently arrived at a new customer site to help them with some database issues. They have a development environment, test environment, production database, and a clone of production they use for reporting. To get started, they sent me the TNS entries for each of these four databases. I didn’t have any usernames or passwords, so I was still in a holding pattern. Since I was using instantclient, I didn’t have tnsping, but I still wanted to verify that the TNS entries were created properly and that I had connectivity. So, I thought I’d just use scott/tiger to test and expected the ORA-01017 (invalid username/password) error.
I tried development, ORA-01017 which confirmed that the TNS entry was correct, but there was no scott/tiger account (or at least the password wasn’t tiger). Tried the test database, same result. The reporting database, same result. (You can see the punchline coming, right?) I tried the production database and, wouldn’t you know it, I got connected using the scott/tiger account! I was so shocked I think I let out a little yelp of disbelief.
So, for all the DBAs tuned in: here’s a quick and easy way to make things better (maybe still insufficient, but at least safER than now). Lock all the accounts that are not in use or that you can’t confirm are in use. If you need a hint: alter user scott account lock;. If you still don’t get it, then prepare your resume :). If you can’t confirm that the account is needed, lock it. When someone complains, unlock it (yes, it’s that easy). If they go to your boss to complain, explain that you did what you did in the name of database and data security (which is true) and you’ll generally avoid punishment.
If you aren’t sure whether the account is one of Oracle’s built-in, default accounts, consult Pete Finnigan’s lists. For more information, check out Project Lockdown, Oracle 11g Database Security Guide, and Pete Finnigan’s list of whitepapers and presentations. You can’t mention Oracle Security without a link to Mary Ann Davidson’s blog which is both informative and often entertaining.
Feel free to submit your horror story in comments. This same scenario happens all the time, but this time just seemed too silly to keep it a secret. No, I won’t tell you who the customer was :).