Designing the DMZ

On Fri, 19 Mar 2004 01:14:47 -0600, "David Slinn"
<dslinn.DeleteThis@accesscomm.ca> wrote:

 >I need a good reference and some recommendations about designing a DMZ -
 >what kinds of applications, ways to set it up, stuff like that.
 >
 >My company wants to deploy an secure web-based application for our
 >customers, and this application will need to interact with the data in our
 >main business database - how do you set up a configuration like this? Since
 >the web app needs access to the database which is located behind the last
 >firewall in the most secure zone, is this a problem? Should this be avoided
 >at all costs? This sounds like something that would happen quite often -
 >how is communication from an externally exposed application to an internal
 >database system avoided?
 >
 >Thoughts?
 >
 >- Dave
 >

Security is always a compromise between risk and usability. When
building a web application from the ground up the data source can be
sufficiently hardened and placed in the DMZ. However you are talking
about exposing an internal application's data via the web. Three
points come to mind for this scenario. First, it is usually not the
intent to expose ALL of the production data. Second, when an internal
application is developed no one thinks to build in the level of
security required for exposing it to the web. Third, the web server is
the most likely box to be compromised in your organization.

What I do when building a web interface to an existing internal
application is to place a second database server in the DMZ and
transfer or, transform to be more accurate, only the data needed for
the web application. The internal firewall rules only allow the
"clean" database server to connect to the one in the DMZ not the other
way around. Connections are only opened for short periods of time. I
like using SqlServer DTS to transform the data but other methods would
be effective as long as all the transfers are initiated from the clean
side and connections are not held open. This is definitely the way to
go if you are only presenting data with the web application. When you
are also allowing additions it gets a little more complicated as you
have to pull the adoptions back through the firewall. And when you are
allowing updates it makes it rather complicated as you have to build
in logic to resolve simultaneous updates to both databases.

How often you run the transformation processes depends on how instant
you need changes to show up on the other side. Sometimes you can get
away with nightly batch type transfers. If you need instant response I
would look into using either MSMQ messages or IBM Websphere messages
to transfer the data across the internal firewall. Message queues were
invented to reliably and quickly transfer small packets of data
between applications without them being tightly connected.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Designing the DMZ 

On Fri, 19 Mar 2004 01:14:47 -0600, "David Slinn"
<dslinn.TakeThisOut@accesscomm.ca> wrote:

 >I need a good reference and some recommendations about designing a DMZ -
 >what kinds of applications, ways to set it up, stuff like that.

There's no "design" to a DMZ, it's simply a zone protected by firewall
rules between it and the WAN (Internet) and between it and the LAN
(Internal Network). Rules can be different for each connection.

 >My company wants to deploy an secure web-based application for our
 >customers, and this application will need to interact with the data in our
 >main business database - how do you set up a configuration like this? Since
 >the web app needs access to the database which is located behind the last
 >firewall in the most secure zone, is this a problem? Should this be avoided
 >at all costs? This sounds like something that would happen quite often -
 >how is communication from an externally exposed application to an internal
 >database system avoided?

Two ways. One is to place the database server also in the DMZ and
replicate it from an internal one, or you can use a single DB server
in either the DMZ or LAN and proviude appropriate access to it from
wherever needed. A front end web server in a DMZ to a back end DB
server in the LAN requires access permissions for accessing the second
server from the first, and firewall rules allowing the access. One
simple methood is to set it up and leave the firewall locked down,
test the connection and look at the firewall logs to see what needs to
be changed.

Jeff<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Designing the DMZ