Pete Finnigan's Oracle Security Forum


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

        Oracle Security >> Oracle Security >> Web visibility and security
        
(Message started by: Pete Finnigan on Jul 27^th, 2005, 2:26pm)

Title: Web visibility and security
Post by Pete Finnigan on Jul 27^th, 2005, 2:26pm

I've had my Oracle databases happily existing behind two firewalls. But now we've got a business requirement that going to mean limited exposure via a web application indirectly to our production database. From the paranoid DBA perspective, exposure is binary, I guess, so limited == exposed. What it boils down to is, I've not been too concerned about security beyond normal internal user security. This question may be too broad to be useful, but where do I need to start getting smarter to deal with the new setup?

Thanks,
Harry

Title: Re: Web visibility and security
Post by Pete Finnigan on Jul 27^th, 2005, 2:43pm

Hi Harry,

Two thoughts come to mind. The first is that you indicate that the database is not locked down as tight as it might be? - if this is so I would start to look seriously about auditing the database for configuration issues and to take action. The same applies to the server it runs on. This is to prevent bigger damage than necessary if someone does find a way in via your indirect exposure. There are some good resources on the main site. The CIS benchmar is a good starting point along with its free tool (you can find a link on my white papers page (http://www.petefinnigan.com/orasec.htm) and also have a look at the default password checker (http://www.petefinnigan.com/default/default_password_checker.htm) and some of the other free tools on the http://www.petefinnigan.com/tools.htm]tools page.

My second thought is that unless a hacker finds a direct way to attack your database server then he would most likely get in via SQL Injection initiated in your application or use of an existing bug (SQL buffer overflow for exmple). It is hard to comment further on SQL injection without knowing more about the app. I would start by looking at some of the papers on SQL Injection (again see my white papers section) to get an idea about what this is and how it works.

hope this helps,

cheers

Pete

Title: Re: Web visibility and security
Post by Pete Finnigan on Oct 24^th, 2005, 5:00pm

Pete, I read your blog on a regular basis. Very informative.

I have the same setup as the original poster of this discussion topic. All of my databases are behind multiple firewalls.

Since my company's databases are protected by the firewalls, do I need to be as concerned about these quarterly patches as others who have their databases outside the DMZ?

My unit has applied the earlier patches, but I am trying to come up with a strategy that will keep our databases secure but not force our developers to test application functionality every 3 months or so.

After the problems with patch 68, our application developers will be required to test ALL of the functionality in their applications. Some are so complex that this could take days/weeks.

Opinions?

Title: Re: Web visibility and security
Post by Pete Finnigan on Oct 26^th, 2005, 9:44pm

Hi Chris,

Thanks for your nice comments about my blog. I think the answer to this is very simple, if your applications (and hence database) is exposed to the internet then despite firewalls you are still exposed if you do not patch. The latest CPU Oct 2005 patch has a large number of SQL injection issues in standard built in packages. This means that your database is vulnerable. Of course I am making these comments without knowledge of your application and its coding and the amount of data exposed. For me the bottom line is that if any part of the database is exposed via an application to the net/intranet or even local network then its vulnerable. a Deloitte survey this year of the top 100 financial institutions revealed that for the first time internal attacks are higher in number than external. So don't think that your safe because the data is protected from the external bad guys.

lock down the database configuration, patch and try and reduce the chances of SQL Injection.

cheers

Pete