Listener passwords: always for 9i, never for 10g
My rule of thumb:
- For 9i and below: always set a listener password (= change from default)
- For 10g and above: never set a listener password (= leave at default)
And here’s why:
9i and below
Without a listener password set, any ‘oracle’ account on any machine (even a client) can stop and change listeners on any other machine on your network, including production servers.
So, running a command like this from a dev box as the oracle userid:
$ lsnrctl stop liveserver
will stop the listener running on server “liveserver“. Which you probably don’t want.
And its not enough to make every “oracle” account on every server secured to DBAs: people can and will create their own clients or virtual clients with oracle userids. As long as they are plugged into your network, they control all your listeners. And there’s nothing you can do about it – except set a listener password.
With a listener password, nothing can be done to any of your listeners except by someone who knows your password.
To set a listener password, use the change_password command in listener control:
$ lsnrctl
LSNRCTL> change_password
LSNRCTL> save config
The fist time you do this, no password is set, so just press return when you are asked for the existing password.
Once that has been done, you have to specify the password before attempting most listener operations. Use the “set password” command for that:
$ lsnrctl
LSNRCTL> set password
“lsnrctl start” still works without the password being specified, but pretty much everything (even status!) requires the password set first.
That makes system shutdown commands a little more complex, see this post for details.
10g and above
The above is such a glaring security hole that oracle changed the default behaviour with 10g and made everything secure. More secure even than the above setup of a password protected listener. Because with 10g, the default is to refuse lsnrctl operations from other machines.
If you actually wanted lsnrctl operations from other machines (very unusual in my experience), then setting a listener password will allow that.
So notice the behaviour has switched:
- Most secure = no password, the default
- A little less secure = set a password
Setting a password doesn’t make anything more sucure – passwords are ignored if you are the oracle userid/member of dba group on the local machine. While on 9i and below the password, if set, would always be required.
Oracle Support have some carefully worded (“customers may wish to consider“) advice on that:
For database releases prior to Oracle Database 10g Release 1: you should set an administrative password for the TNS listener. For Oracle Database 10g Release 1 and later releases, the default authentication mode for the TNS listener is local OS authentication, which requires the TNS listener administrator to be a member of the local dba group. Setting a password for the TNS listener in Oracle Database 10g Release 1 and higher simplifies administration. However, setting a password requires good password management to prevent unauthorized users from guessing the password and potentially gaining access to privileged listener operations. Because the listener acts as the database’s gateway to and from the network, it is important to secure it. Customers may wish to consider not setting a password for the TNS listener starting with Oracle Database 10g Release 1, because in the interest of increasing security and reducing risks, the default behavior changed in this and later releases.
[Metalink note 340009.1]
That is: for 10g, don’t set a listener password, unless you really need/want to control listeners from different machines.
Thanks to Beth, Howard Rogers, Mark Ashby for the info on 10g behaviour.