Recently someone probably went through the slides of my session on "Real Life DBA Best Practices" and had a question on OTN forum why I was recommending setting the parameter to ON, as a best practice. I responded on the forum; but I feel it's important enough to put it here as well.
As a best practice, I recommend setting this parameter to ON (the default is OFF). But as I profess, a best practice is not one without a clear explanation. Here is the explanation.
Over the period of time, the Oracle Database has encountered several security vulnerabilities, some of them on the listener. Some are related to buffer overflow. others involve unauthorized access into the listener process itself. Some of the listener access exploits come from external listener manipulations. Did you know that you do not need to even log into a server to connect to the listener? As long as the port the listener is listeneing on is open (and it will be, for obvious reasons) you can connect to the listener from a remote server.
In 10g, Oracle provided a default mechanism that does not require password from the oracle user manipulating the listener via online commands. Having said that, there have been bugs and there will be. Those vulnerabilities usually get fixed later; but most often the fix does not get to the software quickly enough.
So, what should you do to protect against these vulnerabilities? I consider a simple thing to do is to remove the possibilty altogether; and that's where the admin restrictions come into picture. After setting this parameter, you can't dynamically change the parameter. So, even though a connection is made somehow from an outside server - bug or not - eliminating the possibilty altogether mitigates the risk. And, that's why recommend it.
Let's ponder on the problem a little bit more. Is that a problem is setting the parameter? Absolutely not. When you need to change a parameter, you simply log on to the server, update the listener.ora and issue "lsnrctl reload". This reloads the parameter file dynamically. Since you never stopped the listener, you will not see unsuccessful conection requests from clients. So, it is dynamic. If you are the oracle user, then you can log on to the server; so there is no issue there.
I advocate this policy rather than dyanamic parameter changes, for these simple reasons:
(1) It plugs a potential hole dues to remote listener vulnerability attacks, regardless of the probabilty of that happening.
(2) It forces you to make changes to listener.ora file, which shows the timestamp.
(3) I ask my DBAs to put extensive comments on the parameter files, including the listener.ora file, to explain the change. I also ask them to comment a previous line and create a new line with the new value, rather than updating a value directly. This sort of documentation is a gem during debugging. Changing in the parameter file allows that, while dynamic change does not.
So, I don't see a single functionality I lose by this practice; and I just showed you some powerful reasons to adopt this practice. No loss, and some gain, however small you consider that to be - and that's why I suggest it.
As I mentioned earlier, a best practice is not one without a clear explanation. I hope this explanation makes it clear.
Confessions of an Oracle Database Junkie - Arup Nanda The opinions expressed here are mine and mine alone. They may not necessarily reflect that of my employers and customers - both past or present. The comments left by the reviewers are theirs alone and may not reflect my opinion whether implied or not. None of the advice is warranted to be free of errors and ommision. Please use at your own risk and after thorough testing in your environment.
Tuesday, August 19, 2008
Why should you set the ADMIN_RESTRICTIONS_LISTENER to ON
Subscribe to: Post Comments (Atom)
you can open any search engine and get to know more about the way of filefix clipper, provided by some applications
Arup, good rationale. However, we have run into one loss of functionality that is troublesome. with admin_restrictions =on we can no longer stop the logging for a short time to rotate the listener.log. Any thoughts on this
@Anonymous - you didn't mention if this is 11g or 10g. If 11g, you can't really change the logs. There is a way to do it by switching back to the non-ADR style which I have covered in a blog http://arup.blogspot.com/2013/04/switching-back-to-regular-listener-log.html.
If 10g, are you doing this:
1. stop log
2. move the listener.log to some other name
3. start log
If so, you are missing out on the log writing between steps 1 and 3, however small it may be. Instead why not simply change the log_file_ parameter to the new name, e.g. listener_0405.log and continue as usual? You can set the parameter in listener.ora and reload. There is no need to set it from LSNRCTL command prompt.
Term Paper Help Services firm is credible and have a good reputation for all your Custom Term Paper Writing Services and Term Paper Assignment Help Services.
Post a Comment