[UPDATE to original posting: Howard Rogers pointed out (quite correctly) that starting with 10g the listener defaults to local os authentication. In other words it can only be started by a member of the local dba group. Per the January Oracle Database Security Checklist, "Customers may wish to consider not setting a password for the TNS listener starting with Oracle Database 10g Release 1." See Metalink Note: 340009.1 for additional discussion.]
I've never understood why so many administrators don't secure the listener. We spend hours implementing password policies and data access plans, yet leave the back door wide open.
A year ago I attended an class offered by our application vendor. The instructor was terrific, a very knowledgeable dba in most areas. Still, when we reached the topic of security he completely bypassed mentioning the listener.
When my co-worker and I mentioned this, he looked at us with shock. Secure the listener? Why? It's just the listener.
Sigh.
- The listener can be amdministered remotely
- In its default configuration, the listener can be used to access executable programs on the database server
- The listener can be used to write to any disk location available to the process owner (usually "oracle" or "Administrator")
- Denial of Service is flat-out trivial.
No, I don't plan to post how to achieve all of the above. There's plenty of resources out there to teach you the "how to's."
What should you do?
FIRST: set a password for the listener. If you do nothing else, please at least do this. There's two ways to set a password:
- Add a PASSWORD_LISTENER = yourpasswordhere entry to listener.ora and issue "reload" from within lsnrctl's command prompt. This is NOT recommended since it leaves your password in plain text within the file.
- At the lsnrctl command prompt:
- issue "change_password" and give it the new password when prompted. (If it's the first time, just hit the enter key when prompted for the old password, since there isn't one yet.)
- issue "set password" and re-enter the password when prompted.
- issue "save_config"
In the second method the password still appears in your listener.ora, but it's encrypted.
There's actually a third method -- use one of the graphical interfaces from oracle (Net Manager, Enterprise Manager, etc)
Tomorrow I'll post about removing the listener's ability to call external executables....
6 comments:
How about starting the listener using account other than oracle?
How would I start such secured listener from an os startup script?
Excellent question. You can start a secured listener without the password. The password comes into play when trying to stop it, or to request status or services information. Your startup script should work just fine (at least mine does...).
Regarding starting the listener as an account other than oracle. I don't know if that's even possible for 'normal' listener operations.
(I define 'normal' as passing queries to a database, as opposed to calls to external libraries.)
I rely on password protection in conjunction with logging and monitoring of activities/errors to secure such normal operations.
OTOH, running a separate listener under a restricted account is EXACTLY what you should do if you need to allow calls out to external procedures. In fact, today's post (Securing the Oracle Listener, Part II) discusses just that.
You should perhaps mention that in 10g, the Listener is secured by default: only a member of the dba group can start/stop it. And, rather importantly given your advice, the recommendation these days is therefore NOT to password-protect a 10g Listener.
Doing so actually opens it up to being tinkered with by more users than just leaving things alone.
As you say, security policies need to evolve.
Howard -- good catch! Many thanks for pointing this out. My production databases are 9i, and I hadn't noticed the change in my 10g-related readings.
I will adjust the blog entry to reflect this point.
Post a Comment