Gary Flynn wrote: > 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.
I do agree to some extent, and also would like to add a comment about another commonly used technique. Some people (esp. software vendors; an example would be enterprise-class CMS vendors, such as Gauss Interprise) would suggest database replication from the inside network to a database on the DMZ network in response to your thoughts; however, even though this makes successful *operating system level* attacks against the inside server hosting the database very unlikely, it does not prevent theft or unauthorized modification of the data that is stored once the web server has been compromised. In most environments, this data is in fact a valuable asset that should be protected and may contain things like authentication/authorization data and business critical information. It may be helpful to use some encryption for data storage (ie. symmetric encryption using passwords obtained through the user authentication process) so that data stored on the DMZ database server is unreadable to some extent to an outside attacker, or use [transparent] application level [reverse] proxies for the database protocol, such as an SQL*Net or Tuxedo proxy, to enforce access limits. This is all problematic and does not add a great deal of security, since the web server still needs full access, and still needs to have all information required (for at least sessions that are currently open) to access the data. It may prove helpful in identifying attacks though. One needs to bear in mind though that adding complexity to the architecture will make management more expensive and more complicated, and moving some of the application security responsibility to the application developers, although this would be a good idea in an ideal world (and should at all times be part of the security precautions), usually does not result in safe code. > 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. This is true, but this is also one of the reasons why one *should* separate the inside from the DMZ network. Servers that are directly reachable from the outside are vulnerable to some (great) extent to outside attack in traditional firewall architectures. Putting them in a controlled, well-monitored area therefore is a wise thing to do; the goal is not just to protect them from compromise (they'd be as protected from outside attacks on the inside network as they are on the DMZ), but to make it easier to monitor, manage, and limit the likelihood of compromises on the internal network. > 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. Exactly. > 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. In a classic DMZ-based setup with a standard (read: non-sophisticated, ie. no validation on form fields, parameter types, no positive logic identifying legal/illegal URLs) reverse proxy on the firewall, the hardening accounts for the major part of minimizing the likelihood of *any* compromise through this channel, but the DMZ accounts for minimizing the likelihood of compromise of the internal network. A combination of firewalling and 'air gap'-style split reverse proxies for Tuxedo, SQL*Net or even HTTP-based communication can yield in a huge increase over mere firewalling and DMZ-type network separation. > Is this heresy? :) To some extent, yes, but it I'd still agree with you. Jan _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
