DComTalk.com

Hi everyone, I would like to install a web-server on a DMZ. This
web-server will access a database hosted on the private network.
In a book called "The Practice of Network Security", the 2 following
DMZ design are suggested :

Design #1 (private network and DMZ connected to same FW) :

internet -> FW -> private network
|
+--> DMZ

Design #2 (2 FW) :

internet -> FW -> DMZ -> FW -> private network.

The author says that "The most notable problem with design #1 is that
there is no way to securely update information on the servers. There
are also no facilities in place to secure the database transactions
between the web server and the database server, or any of the backend
servers".

I'm afraid I don't understand what the author means... if I use design
#1 and if the FW is correctly configured, what can prevent me from
securing the database transactions ?

Thanks for helping...

sc_wizard29@hotmail.com wrote:

I would like to install a web-server on a DMZ. This web-server will
access a database hosted on the private network. In a book called "The
Practice of Network Security", the 2 following DMZ design are
suggested :

Design #1 (private network and DMZ connected to same FW) :

internet -> FW -> private network
|
+--> DMZ

Design #2 (2 FW) :

internet -> FW -> DMZ -> FW -> private network.

The author says that "The most notable problem with design #1 is that
there is no way to securely update information on the servers. There
are also no facilities in place to secure the database transactions
between the web server and the database server, or any of the backend
servers".

The mere network topology doesn't support this opinion in any possible
way.

I'm afraid I don't understand what the author means... if I use design
#1 and if the FW is correctly configured, what can prevent me from
securing the database transactions ?

You don't want *any* host in the DMZ to be able to establish connections
into your private network, since that would break the DMZ. Put the
backend servers into the DMZ (or a separate second DMZ). Replicate
(push!) the relevant data from your backend servers to servers in the
DMZ. But *never* *ever* allow connections from the DMZ to the internal
network.

cu
59cobalt
--
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668

In article <3v3d40F13iu6tU2@individual.net>, usenet-2005
@planetcobalt.net says...

sc_wizard29@hotmail.com wrote:
I would like to install a web-server on a DMZ. This web-server will
access a database hosted on the private network. In a book called "The
Practice of Network Security", the 2 following DMZ design are
suggested :

Design #1 (private network and DMZ connected to same FW) :

internet -> FW -> private network
|
+--> DMZ

Design #2 (2 FW) :

internet -> FW -> DMZ -> FW -> private network.

The author says that "The most notable problem with design #1 is that
there is no way to securely update information on the servers. There
are also no facilities in place to secure the database transactions
between the web server and the database server, or any of the backend
servers".

The mere network topology doesn't support this opinion in any possible
way.

I'm afraid I don't understand what the author means... if I use design
#1 and if the FW is correctly configured, what can prevent me from
securing the database transactions ?

You don't want *any* host in the DMZ to be able to establish connections
into your private network, since that would break the DMZ. Put the
backend servers into the DMZ (or a separate second DMZ). Replicate
(push!) the relevant data from your backend servers to servers in the
DMZ. But *never* *ever* allow connections from the DMZ to the internal
network.

The never allow the DMZ to reach the LAN doesn't work in the real world
for Web/Database applications. In the case of a web server with a
database backend, you don't want the DB in the DMZ, you want the DB in
the DMZ. What you setup in the firewall is what makes the difference. In
these cases you allow (for MSSQL) DMZ:IP:1433 to LAN:DB IP:1433 but only
for that port and only those two IP. You don't do Windows
authentication, only SQL User authentication (and you don't use SA).

There are other instances, where you create a rule that allows Nodes in
the LAN to reach the Mail server in the DMZ (exchange in this example),
but the rule also permits the mail server to reach the Nodes, BUT only
if the nodes contact the exchange server first. A FE/BE design for
exchange would be better.

We've used both design #1 and design #2 and I like to have the firewall
appliance setup with the LAN on jack 1 in a subnet like 10.4.0.0/16 and
the DMZ in a subnet on jack 2 like 192.168.4.0/24. The jacks are not
connected like the cheap NAT routers, they require rules to map between
them.

--

spam999free@rrohio.com
remove 999 in order to email me

Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:

sc_wizard29@hotmail.com wrote:
I would like to install a web-server on a DMZ. This web-server will
access a database hosted on the private network. In a book called "The
Practice of Network Security", the 2 following DMZ design are
suggested :

Design #1 (private network and DMZ connected to same FW) :

internet -> FW -> private network
|
+--> DMZ

Design #2 (2 FW) :

internet -> FW -> DMZ -> FW -> private network.

The author says that "The most notable problem with design #1 is that
there is no way to securely update information on the servers. There
are also no facilities in place to secure the database transactions
between the web server and the database server, or any of the backend
servers".

The mere network topology doesn't support this opinion in any possible
way.

I'm afraid I don't understand what the author means... if I use design
#1 and if the FW is correctly configured, what can prevent me from
securing the database transactions ?

You don't want *any* host in the DMZ to be able to establish connections
into your private network, since that would break the DMZ. Put the
backend servers into the DMZ (or a separate second DMZ). Replicate
(push!) the relevant data from your backend servers to servers in the
DMZ. But *never* *ever* allow connections from the DMZ to the internal
network.

In reality this is next to impossible in any real world scenario.
What this would mean is near 100% of your servers would be DMZ'd. If
you put SMTP servers in the DMZ they MUST reach in and deliver mail to
exchange/notes. DMZ these and you open more problems then you solve
because RPC uses 10s of thousands of high ports as service ports.

cu
59cobalt

Leythos <void@nowhere.lan> wrote:

In article <3v3d40F13iu6tU2@individual.net>, usenet-2005
@planetcobalt.net says...
sc_wizard29@hotmail.com wrote:
I would like to install a web-server on a DMZ. This web-server will
access a database hosted on the private network. In a book called "The
Practice of Network Security", the 2 following DMZ design are
suggested :

Design #1 (private network and DMZ connected to same FW) :

internet -> FW -> private network
|
+--> DMZ

Design #2 (2 FW) :

internet -> FW -> DMZ -> FW -> private network.

The author says that "The most notable problem with design #1 is that
there is no way to securely update information on the servers. There
are also no facilities in place to secure the database transactions
between the web server and the database server, or any of the backend
servers".

The mere network topology doesn't support this opinion in any possible
way.

I'm afraid I don't understand what the author means... if I use design
#1 and if the FW is correctly configured, what can prevent me from
securing the database transactions ?

You don't want *any* host in the DMZ to be able to establish connections
into your private network, since that would break the DMZ. Put the
backend servers into the DMZ (or a separate second DMZ). Replicate
(push!) the relevant data from your backend servers to servers in the
DMZ. But *never* *ever* allow connections from the DMZ to the internal
network.

The never allow the DMZ to reach the LAN doesn't work in the real world
for Web/Database applications. In the case of a web server with a
database backend, you don't want the DB in the DMZ, you want the DB in
the DMZ. What you setup in the firewall is what makes the difference. In
these cases you allow (for MSSQL) DMZ:IP:1433 to LAN:DB IP:1433 but only
for that port and only those two IP. You don't do Windows
authentication, only SQL User authentication (and you don't use SA).

This is what makes sense. What you *never* want to do is open
administrative ports(RPC, RDP, telnet, SSH, X-windows) inward.
Insecure servers should never have an opportunity to administrate more
secure servers. This can be difficult to get across to programmers and
operators who will not consider security when deciding where to build
scripts and jobs to run. You want to design communication so secure
servers reach INTO the DMZ as much as possible. FTP Get on a secure
server to pull files, not FTP Put from the insecure one.

There are other instances, where you create a rule that allows Nodes in
the LAN to reach the Mail server in the DMZ (exchange in this example),
but the rule also permits the mail server to reach the Nodes, BUT only
if the nodes contact the exchange server first. A FE/BE design for
exchange would be better.

We've used both design #1 and design #2 and I like to have the firewall
appliance setup with the LAN on jack 1 in a subnet like 10.4.0.0/16 and
the DMZ in a subnet on jack 2 like 192.168.4.0/24. The jacks are not
connected like the cheap NAT routers, they require rules to map between
them.

sc_wizard29@hotmail.com wrote:

Hi everyone, I would like to install a web-server on a DMZ. This
web-server will access a database hosted on the private network.
In a book called "The Practice of Network Security", the 2 following
DMZ design are suggested :

Design #1 (private network and DMZ connected to same FW) :

internet -> FW -> private network
|
+--> DMZ

Design #2 (2 FW) :

internet -> FW -> DMZ -> FW -> private network.

The author says that "The most notable problem with design #1 is that
there is no way to securely update information on the servers. There
are also no facilities in place to secure the database transactions
between the web server and the database server, or any of the backend
servers".

I'm afraid I don't understand what the author means... if I use design
#1 and if the FW is correctly configured, what can prevent me from
securing the database transactions ?

Thanks for helping...

The difference between these two is that there are two physically
different firewalls. And really that is the ONLY practical difference.
You would setup all the same rules. In design #2 if the first FW is
compromised, by that I mean the hacker has admin control over the
firewall, the second FW is intact. You would write all the rules in
the same ways, and you would still have to open the same ports through
the firewall for Web->DB connectivity.

The second advantage to 2 firewalls is administrative complexity.
Writing rules can be easier when you don't have a lot of interfaces
especially if you divide functional traffic across different boxes.


-------OUTSIDE------
| |
FW1 DMZ3--FW2--DMZ4
| |
--------INISDE------

In the above example you can divide rules up across the two firewall.
General Internet access can be handled by FW1, while FW2 focuses on
DMZ related access only. People can easily create INSIDE->ANY rules
that mistakenly give access to DMZs when the Internet rules mix in.
Ifind it easier to screw up rules on the PIX, especially if you try to
use their GUI. Checkpoint had better tools for avoiding those kinds of
mistakes.

Leythos wrote:

In article <3v3d40F13iu6tU2@individual.net>, usenet-2005@planetcobalt.net says...
You don't want *any* host in the DMZ to be able to establish
connections into your private network, since that would break the
DMZ. Put the backend servers into the DMZ (or a separate second DMZ).
Replicate (push!) the relevant data from your backend servers to
servers in the DMZ. But *never* *ever* allow connections from the DMZ
to the internal network.

The never allow the DMZ to reach the LAN doesn't work in the real
world for Web/Database applications.

It does work in the real world, though many people seem to be reluctant
to do it right, because the other way is so much easier. In fact I
pointed out two ways how to make it work.

[...]

There are other instances, where you create a rule that allows Nodes in
the LAN to reach the Mail server in the DMZ (exchange in this example),
but the rule also permits the mail server to reach the Nodes, BUT only
if the nodes contact the exchange server first.

LAN nodes connecting to a server in the DMZ don't break the DMZ. A DMZ
does not mean to prohibit any traffic between LAN and DMZ, it just means
that no connections can be initiated *from* DMZ *to* LAN. That's what
stateful filtering is for.

A FE/BE design for exchange would be better.

It's possible to have setups like that.

We've used both design #1 and design #2 and I like to have the
firewall appliance setup with the LAN on jack 1 in a subnet like
10.4.0.0/16 and the DMZ in a subnet on jack 2 like 192.168.4.0/24. The
jacks are not connected like the cheap NAT routers, they require rules
to map between them.

Both setups are more or less equivalent. Having two firewalls gives a
little more protection to your LAN (because the inner firewall, running
a different system on different hardware, isn't vulnerable to the same
exploits as the outer firewall), but adds some more complexity, because
you need to maintain two different systems. A three-way setup is a
little easier to maintain (and thus probably a little less prone to
configuration glitches), but if an attacker manages to compromise the
firewall he has access to either DMZ and LAN.

However, you still don't want any server in the DMZ to be able to
initiate connections to hosts inside tha LAN.

cu
59cobalt
--
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668

DigitalVinyl wrote:

Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:
You don't want *any* host in the DMZ to be able to establish
connections into your private network, since that would break the
DMZ. Put the backend servers into the DMZ (or a separate second DMZ).
Replicate (push!) the relevant data from your backend servers to
servers in the DMZ. But *never* *ever* allow connections from the DMZ
to the internal network.

In reality this is next to impossible in any real world scenario.

Wrong.

What this would mean is near 100% of your servers would be DMZ'd.

Yeah. So?

If you put SMTP servers in the DMZ they MUST reach in and deliver mail
to exchange/notes.

No. It can easily be *pulled* from the SMTP server and fed to Exchange.
Outbound mail is sent through a smarthost. BTDT. Don't know about Notes,
though.

DMZ these and you open more problems then you solve because RPC uses
10s of thousands of high ports as service ports.

There's no need to DMZ them.

cu
59cobalt
--
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668

Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:

DigitalVinyl wrote:
Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:
You don't want *any* host in the DMZ to be able to establish
connections into your private network, since that would break the
DMZ. Put the backend servers into the DMZ (or a separate second DMZ).
Replicate (push!) the relevant data from your backend servers to
servers in the DMZ. But *never* *ever* allow connections from the DMZ
to the internal network.

In reality this is next to impossible in any real world scenario.

Wrong.

Go into any decent sized enterprise and you will not find that all
inbound traffic from the DMZ is blocked. That's what that says. Your
ruleset set is ONE simple line a DENY SRC:ALL-DMZ-NETS DST:INSIDE ANY.
In a small company with almost no servers that could be possible
largely because you don't do much. But once your shop starting
developing apps and you have dozens of DMZ servers that concept is not
enforceable. Politically you won't win. I wonder if the financial
world manages to maintain that standard. Where SMTP, DNS, NTP, and
every other protocol is restructured to only permit pushes into the
DMZ.

What this would mean is near 100% of your servers would be DMZ'd.

Yeah. So?

So one comprimised server in the DMZ could lead to a hundred. It could
increase the layer 2 security requiremnt in the DMZ to be
administratively painful. The rule I use is if the Internet must
reach in and touch the server it should be in a DMZ. Everything else
should be further in. This is a fairly safe thing, since the DMZ must
protects your company from IT'S OWN SERVERS. This is sometimes
forgotten. The Firewall is protecting your inside network from
compromised DMZ servers. Load your DMZs up with non-internet servers
and you've reduced all your security to that of an internet-accessible
server.

DB & servers which hold financial and legal information should be
reviewed if there is a legal obligation to up the protectio even
further (FW'ing the DB from the Inside network as well).

If you put SMTP servers in the DMZ they MUST reach in and deliver mail
to exchange/notes.

No. It can easily be *pulled* from the SMTP server and fed to Exchange.
Outbound mail is sent through a smarthost. BTDT. Don't know about Notes,
though.

I've never heard of that setup. But you'd have to do the same with
every protocol and transfer in existence. You can't use internal NTP
servers, or SMTP gateways, or DNS, or printservers, or sysloggers, or
FTP servers. It all has to be reversed or you need to establish all
those services within the DMZ.

DMZ these and you open more problems then you solve because RPC uses
10s of thousands of high ports as service ports.

There's no need to DMZ them.

The exchange team here insists that OWA (the web-access server for
Exchange) must be in the same network as Exhcnage and domain
controller. It's likely that it is total hogwash but it sets up a
common political problem. The network/security group is pitted against
other departments trying to reasearch/prove/discredit what tehy say is
true to justify that the above guidelines are adhered to. That's
where this stuff falls apart over time. The human element makes it
impossible.

cu
59cobalt

In article <3v3o3nF13n3meU1@individual.net>, usenet-2005
@planetcobalt.net says...

However, you still don't want any server in the DMZ to be able to
initiate connections to hosts inside tha LAN.

Again, it's not going to hold in a web to database design. You should
never put the database server in the DMZ and you would never put the web
server in the LAN - so, you punch a IP:PORT hole through the DMZ>LAN for
1433 between the exact two IP, and then your web app can access the
MSSQL Server in the protected LAN. Port 1433 isn't going to allow access
to Enterprise manager, and as long as your DB Server is patched, then
allowing 1433 from the DMZ to LAN vial IP:PORT>IP:PORT won't compromise
the network.


--

spam999free@rrohio.com
remove 999 in order to email me

In article <9pbpo1d8e7s2nq0l6s3k6ud47saevqc2r7@4ax.com>,
DigitalVinyl@internet.com says...

The exchange team here insists that OWA (the web-access server for
Exchange) must be in the same network as Exhcnage and domain
controller. It's likely that it is total hogwash but it sets up a
common political problem. The network/security group is pitted against
other departments trying to reasearch/prove/discredit what tehy say is
true to justify that the above guidelines are adhered to. That's
where this stuff falls apart over time. The human element makes it
impossible.

Our exchange installs, many of them with many large clients, don't have
the Exchange server sitting/connected to the LAN Domain, in fact, there
is no DOMAIN Authentication with the Exchange servers. User accounts are
createded in the Exchange DOMAIN (as stand alone domain), passwords are
GIVEN to the employees, and access is setup for them. The Exchange
server IS NOT part of the company LAN or domains. If you have a FE/BE
setup you can change that, but we do a lot of single Exchange server
setups for medical groups with 300+ accounts and have been able to
maintain a single Server in the DMZ for ages.

The firewall is setup to only allow the Exchange server to "respond" to
requests from the LAN - and users can OWA or Outlook via exchange
connector, etc....

With this method, although it means more overhead in maintenance and
setup, we've never had a compromised client/server/node.

--

spam999free@rrohio.com
remove 999 in order to email me

DigitalVinyl wrote:

Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:
DigitalVinyl wrote:
Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:
You don't want *any* host in the DMZ to be able to establish
connections into your private network, since that would break the
DMZ. Put the backend servers into the DMZ (or a separate second
DMZ). Replicate (push!) the relevant data from your backend servers
to servers in the DMZ. But *never* *ever* allow connections from
the DMZ to the internal network.

In reality this is next to impossible in any real world scenario.

Wrong.

Go into any decent sized enterprise and you will not find that all
inbound traffic from the DMZ is blocked.

That doesn't make it impossible.

That's what that says.

No. It's probably what you wanted to say, but not what you did say. And
not what I am talking about at all.

Your ruleset set is ONE simple line a DENY SRC:ALL-DMZ-NETS DST:INSIDE
ANY.

No, my ruleset isn't necessarily that simple, though this is the basic
rule.

In a small company with almost no servers that could be possible
largely because you don't do much. But once your shop starting
developing apps and you have dozens of DMZ servers that concept is not
enforceable.

Of course it is.

Politically you won't win.

That's a completely different story. Of course you can't enforce this
without being backed by management. And guess what: sometimes you
actually get this backup.

I wonder if the financial world manages to maintain that standard.
Where SMTP, DNS, NTP, and every other protocol is restructured to only
permit pushes into the DMZ.

There is no need to "restructure" Protocols. You "just" need to choose
the right protocols and the right topology. Yes, it's not always as
simple as it looks.

What this would mean is near 100% of your servers would be DMZ'd.

Yeah. So?

So one comprimised server in the DMZ could lead to a hundred. It could
increase the layer 2 security requiremnt in the DMZ to be
administratively painful.

Wrong, because you are by no means limited to a single DMZ. Neither must
each DMZ be accessible from each other DMZ or even from the Internet.

The rule I use is if the Internet must reach in and touch the server
it should be in a DMZ. Everything else should be further in. This is a
fairly safe thing, since the DMZ must protects your company from IT'S
OWN SERVERS. This is sometimes forgotten. The Firewall is protecting
your inside network from compromised DMZ servers.

This is exactly what I was saying, and why connections from DMZ to LAN
should not be allowed. Why do we argue about this, then?

Load your DMZs up with non-internet servers and you've reduced all
your security to that of an internet-accessible server.

Nope. There is no law forcing me to make a DMZ accessible from the
Internet. Think of something like this (single firewall setup to keep
the example simple):

Internet
|
DMZ_1 -- Firewall -- DMZ_2
|
LAN

DMZ_1 holds the webserver, DMZ_2 holds the DB server. The following
connections are allowed (plus established traffic, of course):

Internet -> DMZ_1 (e.g. only on port 80)
DMZ_1 -> DMZ_2 (e.g. only on the DB server port)
LAN -> Internet
LAN -> DMZ_1
LAN -> DMZ_2

Now tell me: where exactly did I reduce all my security here?

DB & servers which hold financial and legal information should be
reviewed if there is a legal obligation to up the protectio even
further (FW'ing the DB from the Inside network as well).

DB & servers which hold financial and legal information should be put
into separate networks with no access whatsoever to the Internet.

If you put SMTP servers in the DMZ they MUST reach in and deliver
mail to exchange/notes.

No. It can easily be *pulled* from the SMTP server and fed to
Exchange. Outbound mail is sent through a smarthost. BTDT. Don't know
about Notes, though.

I've never heard of that setup. But you'd have to do the same with
every protocol and transfer in existence. You can't use internal NTP
servers, or SMTP gateways, or DNS, or printservers, or sysloggers, or
FTP servers. It all has to be reversed or you need to establish all
those services within the DMZ.

What the hell are you talking about? Of course I can do all of that. I
can use internal NTP server which get (pull!) their time from NTP
servers outside my network. I just described how an SMTP gateway would
be set up. I can have internal DNS servers for my LAN and forwarders to
resolve external addresses. I don't need print servers outside of my LAN
(much less print servers that are accessible from anywhere outside my
LAN). I don't need one central log host if I need to compromise my
network security for that. And of course I can have FTP servers for
anything I want. Though I usually don't want them.

DMZ these and you open more problems then you solve because RPC uses
10s of thousands of high ports as service ports.

There's no need to DMZ them.

The exchange team here insists that OWA (the web-access server for
Exchange) must be in the same network as Exhcnage and domain
controller.

I have never had such a setup myself and I haven't used Echange in a
while, so I am in no position to prove them wrong, though I would guess
there had to be better ways to OWA other than allowing access to the
internal network.

It's likely that it is total hogwash but it sets up a common political
problem.

True. But I wasn't discussing political issues here. I was talking about
the technical aspects and feasibility of DMZ setups. And especially in
the OPs case I don't see any real problem.

The network/security group is pitted against other departments trying
to reasearch/prove/discredit what tehy say is true to justify that the
above guidelines are adhered to. That's where this stuff falls apart
over time. The human element makes it impossible.

Only if you allow it to.

cu
59cobalt
--
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668

Leythos wrote:

In article <3v3o3nF13n3meU1@individual.net>, usenet-2005@planetcobalt.net says...
However, you still don't want any server in the DMZ to be able to
initiate connections to hosts inside tha LAN.

Again, it's not going to hold in a web to database design. You should
never put the database server in the DMZ and you would never put the web
server in the LAN -

Please tell me: why would I punch a hole into the firewall protecting my
LAN rather than putting a DB server into a (separate) DMZ and opening
that hole only between the two DMZs? Or (if the requirements allow this)
do put a DB server into the DMZ, and have the "real" DB server in the
LAN from where only the required subset is pushed to the DMZ-DB?

so, you punch a IP:PORT hole through the DMZ>LAN for 1433 between the
exact two IP, and then your web app can access the MSSQL Server in the
protected LAN.

No, I don't think I'm going to do this.

Port 1433 isn't going to allow access to Enterprise manager, and as
long as your DB Server is patched, then allowing 1433 from the DMZ to
LAN vial IP:PORT>IP:PORT won't compromise the network.

And with one of the setups I described above, my network wouldn't be
compromised even *if* the webserver got compromised *and* there was an
unpatched vulnerability in the DBMS *and* an attacker had a 0-day.
Defense in depth.

cu
59cobalt
--
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668

Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:

Leythos wrote:
In article <3v3o3nF13n3meU1@individual.net>, usenet-2005@planetcobalt.net says...
However, you still don't want any server in the DMZ to be able to
initiate connections to hosts inside tha LAN.

Again, it's not going to hold in a web to database design. You should
never put the database server in the DMZ and you would never put the web
server in the LAN -

Please tell me: why would I punch a hole into the firewall protecting my
LAN rather than putting a DB server into a (separate) DMZ and opening
that hole only between the two DMZs? Or (if the requirements allow this)
do put a DB server into the DMZ, and have the "real" DB server in the
LAN from where only the required subset is pushed to the DMZ-DB?

The only problem I see with putting a critical DB in a DMZ off the
Internet-edge firewall is that it is now on the doorstep of the
internet. If the firewall is comprimised you've lost the DB already.
Further in, you can have a critical DB behind a second firewall or
implement acl control. Also combining DMZs on one firewall is common,
but can result in rule confusion and unintended opening of access.

Other than that you can do exactly that. However it is common for DB
to interact with multiple backend servers and applications, not to
mention admin/desktops. Rather than open one rule WEB->DBport, you now
have to open many more to allow all the different internal servers to
access the DMZ-DB or possbily in the reverse direction--although I
imagine you wouldn't allow any such thing. And think about that...
you may be placing a DB in a less-secure DMZ than INSIDE. In a PIX all
inside hosts would have access to the DB by default. The DB would be
consider an insecure network by definition. Typically the DB is
considered the most secure element so the DB would run batch jobs and
reach out to other servers. This is a common structure. However, if it
had to reach out to an Internal server that wouldn't be permitted,
because the DMZ-DB is less secure.

so, you punch a IP:PORT hole through the DMZ>LAN for 1433 between the
exact two IP, and then your web app can access the MSSQL Server in the
protected LAN.

No, I don't think I'm going to do this.

Port 1433 isn't going to allow access to Enterprise manager, and as
long as your DB Server is patched, then allowing 1433 from the DMZ to
LAN vial IP:PORT>IP:PORT won't compromise the network.

And with one of the setups I described above, my network wouldn't be
compromised even *if* the webserver got compromised *and* there was an
unpatched vulnerability in the DBMS *and* an attacker had a 0-day.
Defense in depth.

cu
59cobalt

In article <3v40jiF13hjo6U1@individual.net>, usenet-2005
@planetcobalt.net says...

Leythos wrote:
In article <3v3o3nF13n3meU1@individual.net>, usenet-2005@planetcobalt.net says...
However, you still don't want any server in the DMZ to be able to
initiate connections to hosts inside tha LAN.

Again, it's not going to hold in a web to database design. You should
never put the database server in the DMZ and you would never put the web
server in the LAN -

Please tell me: why would I punch a hole into the firewall protecting my
LAN rather than putting a DB server into a (separate) DMZ and opening
that hole only between the two DMZs? Or (if the requirements allow this)
do put a DB server into the DMZ, and have the "real" DB server in the
LAN from where only the required subset is pushed to the DMZ-DB?

If you're going to do real-time replication between a LAN DB and a
Second DMZ DB and expect it to be any different than a DMZ Web to the
LAN DB via only PORT 1433, then you're mistaken.

so, you punch a IP:PORT hole through the DMZ>LAN for 1433 between the
exact two IP, and then your web app can access the MSSQL Server in the
protected LAN.

No, I don't think I'm going to do this.

Fine, don't, I didn't ask you to change anything anywhere.

Port 1433 isn't going to allow access to Enterprise manager, and as
long as your DB Server is patched, then allowing 1433 from the DMZ to
LAN vial IP:PORT>IP:PORT won't compromise the network.

And with one of the setups I described above, my network wouldn't be
compromised even *if* the webserver got compromised *and* there was an
unpatched vulnerability in the DBMS *and* an attacker had a 0-day.
Defense in depth.

Wrong - If the database server in DMZ2 is compromised by a 0-Day
exploit, and you've setup replication between the DMZ1 DB server, so
that you have real-time information available, then the same 0-Day
exploit will reach through and compromise that server too.

--

spam999free@rrohio.com
remove 999 in order to email me