Prior to the release of Oracle 10g, the TNS Listener by default was not secured with a password. In the default state, anyone who could access the TNS Listener remotely could issue commands to it, including shutting it down. The TNS Listener had two security settings: ‘OFF’, the default state, without a password set, and ‘ON’ when a password was set.Starting with 10g, Oracle made the TNS Listener a little more secure, adding a new authentication method, ‘Local OS Authentication’, and making it the default setting. This setting allows local administration of the TNS Listener by the user who owns the tnslsnr process.This change split the security ‘ON’ setting into three different states:Security ON: Local OS AuthenticationSecurity ON: Password or Local OS AuthenticationSecurity ON: PasswordThe ‘Security ON: Local OS Authentication’ and ‘ Security ON: Password or Local OS Authentication’ settings are easy enough to reach with LSNRCTL commands, as the first is the default, and the second by simply setting a password for the listener.The ‘ Security ON: Password’ setting requires adding a line to the listener.ora file, which is also the same method needed to modify the more elusive setting of ‘Security OFF’. The necessary line is:LOCAL_OS_AUTHENTICATION_<listener> = OFFIf this line is added to the listener.ora file after a listener password has been set, it will change the security status from ‘Security ON: Password or Local OS Authentication’ to ‘ Security ON: Password’. However, if you add the line before a password has been set, the security status becomes ‘Security OFF’.
With security off the TNS Listener in 10g and later is just as insecure as 9i and earlier versions. While the likelihood of getting into this insecure state unintentionally is decreased since it’s no longer the default setting, administrators should still be aware of this possibility. It is just as important to ensure TNS Listener is secured with a password in 10g and later as it was in previous versions.Title image courtesy of ShutterStock