Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> recomendations on listener security
        
(Message started by: Pete Finnigan on Jan 23^rd, 2009, 9:01am)

Title: recomendations on listener security
Post by Pete Finnigan on Jan 23^rd, 2009, 9:01am

We have two databases db1 and db2 .
db2 holds v. sensitive data and users only accessed via an app server thru a firewall .
db2 however is accessable via the whole intranet and holds less sensitive data.

These databases are being placed on the same RAC cluster. In order to prevent any unauthorised access to db1, Database db2 will be
restricted via fireall so users only access via a listener on a seperate port (say 1531). Access to db1 will be restricted via firewall
so users access via apps server connecting to a listener on a different port (say 1525)

What we would like confirming is are there any security risks in this methodology, could someone with access to listener 1 on port 1531
(which is listening for db2) gain access or compromise security on db1?

listeners will be password protected and follow listener security guidelines in oracle docs, but it there anything more we should be doing?
many thanks

Title: Re: recomendations on listener security
Post by Pete Finnigan on Jan 23^rd, 2009, 9:42am

Hi Jonathan,

The biggest problem is that both databases are on the same node/cluster/server. If you have taken the oppertunity to enable three (four) aliases during install, OSINSTALL, OSOPER, OSDBA (ASSM) then you have some segregation of duties. Also much more importantly you need to have installed the databases under a different user:group. If you have not then the issue is not the two different listeners but the whole array of other security vulnerabilities/configuration/privilege issues that can occur in the less sensitive database. If it would be possible to exploit the less secure database and you have installed the secure one as the same user:group then you have a problem. Someone breaching the less secure one can breach the more secure one. It; unfortunately is not just about traditional security vulnerabilities that have say been patched by a CPU but more often due to configuration issues. Access to the file system may allow theft for instance. Also remember the issue is often not about escalation of privilege but simple theft of data. Also if someone is able to create a link from the insecure database to the most secure there is also a problem (this problem occurs throughout all your databases!).

My view is its not just about the listener but the fact that you must harden both databases to the same level.

cheers

Pete

Title: Re: recomendations on listener security
Post by Pete Finnigan on Jan 23^rd, 2009, 11:34am

OK thanks Pete, lots of food for thought.

So first step we should really look at keeping the two databases seperated at every level (i.e. os install users/groups , ports used for listeners)
Next step lock down the privileges of the users accessing both the databases so we know exactly what they can/cannot do (which lets face it we should know anyway but can't be 100% we do)
We are only in the planning stage and the two databases will be installed on new servers so these are steps we can defintely take.

I know this is keeping it very general but does that summarise what we are lookin at?

Title: Re: recomendations on listener security
Post by Pete Finnigan on Jan 23^rd, 2009, 4:17pm

Hi Jonathan,

Thanks for your reply. I should have mentioned that most sites I deal with already have multiple databases on the same server with everything installed as oracle:dba so whilst what I said is ideal changing an existing install is often veto'd because of the time/risk of change.

It sounds like you are at the head of the curve, this should be commended; seeking advice before building is fantastic and installing all three Unix groups and seperation for databases at the OS level is something that is easily done on new install.

So yes go for it. Assessing the privileges on the databases is often time consuming but worth the effort. Simplifying and reducing privileges often simplifies maintenance and also inevitably reduces costs because its simpler and easier to work with. Also simplifying privileges can increase performance as every peice of SQL / PL/SQL needs to have the privileges assessed before execution; simpler privileges means faster recursive SQL in these areas.

cheers

Pete

Title: Re: recomendations on listener security
Post by Pete Finnigan on Jan 30^th, 2009, 11:29am

thanks vey much, very useful.