Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Best Practice - Oracle Network thru Firewall

Re: Best Practice - Oracle Network thru Firewall

From: Tony Jambu <>
Date: Tue, 07 Mar 2006 11:18:43 +1100
Message-Id: <>

Hi Stephen

Thanks for the comments. Agree with most of what you said. The client made a decision in the past about letting SQL Net thru the FW. Not much I can do there now. Oracle Advance Security is probably not an option the client will go with but no harm discussing it.

I have to admit it that I did not think of indemnity insurance. That is something to consider.


At 09:48 AM 7/03/2006, stephen booth wrote:
>On 06/03/06, Tony Jambu <> wrote:
>> Hi all
>> Looking for best practice for allowing Oracle Network (functionality)
>> thru a firewall.
>I'd agree with Paul, best pracice is "Don't".
>Given that you have to the only other things not already covered by
>Paul I can think of are to ask if you can know the IP addresses of the
>trusted clients, to suggest that you make sure you audit logins, use a
>non-standard port for your listener and empahsise that you really need
>to keep on top of security patches for Oracle.
>If you know that your trusted clients will only be coming from certain
>IP addresses then you can restrict connections to just those IP
>addresses for your listener port. Using a nonstandard port will help
>a little in reducing the crackability of your database, they have to
>find the port before they can try to exploit it, but not by much.
>You might also want to look at Advanced Security Option. I attended a
>workshop recently on this where they went in the features. Oracle,
>through advenced security, now supports the use of digital
>certificates and SecurID tags for authentication. Not a cheap option
>but the client might be ready to pay, or they might not. if they're
>not prepared to pay then at least they can't say you didn't give them
>the option.
>What ever you do it would be a good idea to make sure that you
>document any and all security concerns and make the client aware of
>them, to cover yourself. Maybe get some professional indemity
>insurance as well, just in case. You don't want to be left carrying
>the can for a client's bad decision.
>Good security is like an onion, it's got plenty of layers so of they
>get through one then they've still got work to do to get through the
>next. Hopefully by the time they're getting close to the database
>they've been detected and counter measures have been deployed.
>It's better to ask a silly question than to make a silly assumption.

Received on Mon Mar 06 2006 - 18:18:43 CST

Original text of this message