RE: Listener Vulnerabilities - how to address them

The solution is to run your listener on 10g and then include the parameter ADMIN_RESTRICTIONS_LISTENER = ON
In your listener.ora file. This restricts all administrative commands in the listener to only users logged on locally to the machine.

Pat

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Johnson, William L (TEIS) Sent: Wednesday, April 09, 2008 11:53 AM To: tony_at_sequeira.org.uk; Oracle List
Subject: RE: Listener Vulnerabilities - how to address them

If I am not mistaken, you can still password protect your listener and then write a wrapper script around your listener commands that will permit you to stop and start the listener through batch processes. As long as you take the time to ensure the listener.ora file is only readable by the Oracle account - and no other accounts on the machine, you should be good to go.

You can set the password for a listener command by picking up the password out of the listener.ora file.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tony Sequeira Sent: Wednesday, April 09, 2008 12:20 PM To: Oracle List
Subject: Listener Vulnerabilities - how to address them

Hi All,

Most of you are probably aware of the following document, or similar.

http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle _Listener_TNS_Security.pdf

We support roughly 100 Oracle databases ranging from 8i to 10g, running on Windows and Unix (Solaris), mostly 9i.

The above documentation has been brought to our attention by one of our users. The questions being asked are:

Are we vulnerable?
If so, how do you propose to address that?

I'm still doing some investigation, thought I would see if someone here has:

1. Come across this problem and sorted it
2. Known about this problem, and taken it into account on installation of Oracle
3. Decided that it's not as bad as it seems, and has disregarded it.

Initial reaction from our team is that setting passwords for the listeners would break backup scripts, apparently the listener is stopped for backups. Hardcoding passwords in these scripts is not really an option.

We are setting in place a plan for applying CPUs to the servers. But as I understand it, these vulnerabilities are not addressed by the CPUs.

Anyone?
--

S. Anthony Sequeira
++
Ralph's Observation:

        It is a mistake to let any mechanical object realise that you
        are in a hurry.

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l

[CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.  

To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
--

http://www.freelists.org/webpage/oracle-l Received on Wed Apr 09 2008 - 12:15:30 CDT