I've always wondered about the effectiveness of a DMZ'ed web
server when it must access an internal database given the following
premises:
1. The web server's http service must be exposed to the public.
2. The http service is the most likely point of penetration either through
direct system compromise or SQL injection.
3. The "firewall" between the web server and the database allows
the web server full SQL access.
If the web server falls, the company database falls regardless of
location. Granted, if they're both on the same network, it may
make it easier to completely compromise the database OS but
the database itself contains the most valuable goodies in many
cases and the web server has full access.
Not to say that I believe the DMZ concept doesn't provide an
extra hurdle but without significant application level intelligence
on the part of the firewall between the DMZ and database,
and without significant and real-time database transaction monitoring
and baselines, I just don't see how the DMZ provides a whole
lot of security.
On a related note, a three tiered architecture where the web server can't
talk directly to the database but must instead use transactions through
an application server may provide some security through obscurity
(many more people are fluent in SQL and HTTP than in Tuxedo, EJB, etc.)
but again, if they're fluent in the application server's API and can
ferret out the business logic, the goodies are up for grabs if the
web server is compromised whatever its location.
It would seem to me that the web server must be hardened to the maximum
regardless of its location and its hardening provides the vast majority
of the
security for the entire infrastructure...not whether its located in a
DMZ or not.
Is this heresy? :)
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
