DComTalk.com

Leythos wrote:
In article <3v40jiF13hjo6U1@individual.net>, usenet-2005@planetcobalt.net says...
Leythos wrote:
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.

No. Simply because replication and web application use different
mechanisms to access the server. Besides, I didn't say anything about
real-time replication.

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.

In article <3v40jiF13hjo6U1@individual.net>, usenet-2005@planetcobalt.net says...
Leythos wrote:
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.

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.

In article <3v5rhjF13va87U2@individual.net>, usenet-2005
@planetcobalt.net says...
Leythos wrote:
In article <3v40jiF13hjo6U1@individual.net>,
usenet-2005@planetcobalt.net says...
Leythos wrote:
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.

No. Simply because replication and web application use different
mechanisms to access the server. Besides, I didn't say anything about
real-time replication.

No, you didn't, but lets take an online ordering system, or a project
management system or anything else that doesn't use a Static DB, and
then you either punch a hole or setup replication, so you're back to
having a security issue that you have to deal with one way or another.

"Leythos" <void@nowhere.lan> wrote in message
news:IUkjf.244394$lI5.78042@tornado.ohiordc.rr.com...
In article <3v5rhjF13va87U2@individual.net>, usenet-2005
@planetcobalt.net says...
Leythos wrote:
In article <3v40jiF13hjo6U1@individual.net>,
usenet-2005@planetcobalt.net says...
Leythos wrote:
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.

No. Simply because replication and web application use different
mechanisms to access the server. Besides, I didn't say anything about
real-time replication.

No, you didn't, but lets take an online ordering system, or a project
management system or anything else that doesn't use a Static DB, and
then you either punch a hole or setup replication, so you're back to
having a security issue that you have to deal with one way or another.

Data lives in DMZ1. Only connection to it is an administrative interface
like RDP, from the trust zone, and some sort of file transfer method like
sftp, both initiated from particular trusted, hardened hosts.

Server lives in DMZ 2. Only connection to DMZ1 is SQL. Only connection to
outside is via incoming http. No connection to trust.

Hacker must compromise web server first using only inline in-line port 80,
and then inject an in-line SQL compromise to the DB server in DMZ1, which in
fact has no outbound policies to anywhere, and therefore can only reply to
SQL sessions initiated from that web server.

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 article <3v5rhjF13va87U2@individual.net>, usenet-2005@planetcobalt.net says...
Leythos wrote:
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.

No. Simply because replication and web application use different
mechanisms to access the server. Besides, I didn't say anything about
real-time replication.

No, you didn't, but lets take an online ordering system, or a project
management system or anything else that doesn't use a Static DB, and
then you either punch a hole or setup replication, so you're back to
having a security issue that you have to deal with one way or another.

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.

It's not about "easy", it's about money.

A realistic risk analysis verses costs. Some's worth it, some's not.

Leythos wrote:
In article <3v5rhjF13va87U2@individual.net>, usenet-2005@planetcobalt.net says...
Leythos wrote:
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.

No. Simply because replication and web application use different
mechanisms to access the server. Besides, I didn't say anything about
real-time replication.

No, you didn't, but lets take an online ordering system, or a project
management system or anything else that doesn't use a Static DB, and
then you either punch a hole or setup replication, so you're back to
having a security issue that you have to deal with one way or another.

As I said: even if I use (live-)replication, I'm not likely to be
vulnerable to the same exploit. And even if I were: my exposure would be
*at most* as high as it were in your scenario.

It's not about "easy", it's about money.

Anything not easy is going to cost money, so it's the same.

A realistic risk analysis verses costs. Some's worth it, some's not.

Honestly, don't most of those "realistic" risk analyses amount to "it's
more likely to hit others first, so we don't need to spend money on that
now", until they actually get hit?

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.

It's not about "easy", it's about money. A realistic risk analysis verses
costs. Some's worth it, some's not.

-Frank

In article <3v6choF13kt77U1@individual.net>, usenet-2005@planetcobalt.net says...
Leythos wrote:
lets take an online ordering system, or a project management system
or anything else that doesn't use a Static DB, and then you either
punch a hole or setup replication, so you're back to having a
security issue that you have to deal with one way or another.

As I said: even if I use (live-)replication, I'm not likely to be
vulnerable to the same exploit. And even if I were: my exposure would
be *at most* as high as it were in your scenario.

So, we're on the same page and just not seeing it. If the exposure is
the same for real-time access, then it's not worth doing it with
multiple DMZ's.

It's not about "easy", it's about money.

Anything not easy is going to cost money, so it's the same.

Disagree. Often the easiest thing is to throw money on it.

A realistic risk analysis verses costs. Some's worth it, some's not.

Honestly, don't most of those "realistic" risk analyses amount to
"it's more likely to hit others first, so we don't need to spend
money on that now", until they actually get hit?

Nope. Not if they are done right.

Another thing... it's kind of ridiculous to spend much time and money
to protect a system without real data storage that you can rebuild and
have back to original in an hour. Just depends. OTOH, it could be that
an hour of downtime would cost your company thousands or millions.
Just depends.

Do you read only every other word or something? The exposure is AT MOST
the same.

In general it is LOWER. So using multiple DMZs IS worth the
effort.