RE: Securing www server w/Oracle back end.

["Ben Nagy" <ben () iagu net>]

> -----Original Message-----
> From: firewall-wizards-admin () honor icsalabs com 
> [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> Of Georges Jahchan
> Sent: Tuesday, March 18, 2003 8:55 AM
> To: Firewall Wizards
> Subject: [fw-wiz] Securing www server w/Oracle back end.
>
>
> I have been assigned the task of planning the security setup for a (to
> be deployed) online system consisting of a publicly accessible web
> server front-end (https), with an Oracle 9i back-end 
> database. Both run
> on IBM RS/6000 platform w/64-bit AIX O/S).
>
> The scenario where the web server would be placed in DMZ and the
> database server in a restricted private zone, with holes 
> punched through
> the firewall between DMZ and private zones is a dangerous proposition.

Could be worse. I like your platform choices, at least. AIX has the
advantage that there is probably nobody under the age of 35 that knows
enough about it to exploit anything. ;)

If possible, some people recommend using a database proxy of some kind
(ie another database, usually) which only holds the tables from the
master database which are required for the web application. That might
or might not help you. In general, I'd have a good look at your Oracle
security setup. I have heard more than one person scoff at the
"unbreakability" of Oracle. Sadly, Oracle stuff is somewhat of a black
art.

You can do a fair bit of OS hardening on your webserver side, following
best practices depending on your platform. In general, try and restrict
code execution scopes in the event that the server is compromised. You
can also try some read-only messing about, tripwire, yada yada yada
which may or may not fly depending on how your app is built. 

I wouldn't really worry toooooo much about the punching holes from the
DMZ to Internal thing. Yes, it feels ugly, but no amount of messing
about is going stop the webserver talking to the database (otherwise
your app won't work) in the event that the webserver is compromised. As
a general approach, imagine the webserver as an untrusted box and see
how much you can harden the database to reject its evil ways. 

I'm sure some consultants would rant about special extra DMZs for the
DB, the ubiquitous eGap solution (feh), dual-homed database server,
serial line connection not running TCP/IP, hiring an intern to write the
untrusted SQL queries out longhand on a blackboard and all the similar
stuff we've been over and over before. It's not that those things are
harmful, I just (personally) think that their work / reward approaches
infinty.

Finally, a NIDS to watch for weird looking activity coming from the
webserver could be useful. Then again, it might just completely ignore
all the database queries and you'll be none the wiser when someone
selects * from creditcardnumbers.

> Any suggestions regarding securing such a setup are welcome.
>
> TIA

Good luck.

ben

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards