| Author |
Message |
Leythos
Guest
|
 Posted:
Wed Nov 30, 2005 5:21 pm Post subject:
Re: DMZ design |
|
|
In article <3v5rhjF13va87U2@individual.net>, usenet-2005
@planetcobalt.net says...
| Quote: | 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.
--
spam999free@rrohio.com
remove 999 in order to email me |
|
| Back to top |
|
 |
Ansgar -59cobalt- Wiecher
Guest
|
| Posted:
Wed Nov 30, 2005 5:21 pm Post subject:
Re: DMZ design |
|
|
DigitalVinyl wrote:
| Quote: | 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.
|
That would depend on the router/firewall topology. You may very well use
two or three firewalls in this setup, avoiding the risk you mentioned
at the cost of somewhat increased complexity, e.g. like this:
Internet -- Firewall -- DMZ_1 -- Firewall -- LAN
|
Firewall
|
DMZ_2
| Quote: | 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.
|
True. But who said maintaining security in complex scenarios was easy?
| Quote: | 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
|
If that's necessary, I think the whole application and DB design should
seriously be re-considered. It is very likely to be flawed.
| Quote: | or possbily in the reverse direction--although I imagine you wouldn't
allow any such thing.
|
Unless being forced to allow it.
| Quote: | And think about that... you may be placing a DB in a less-secure DMZ
than INSIDE.
|
No. DMZ and DB are just as secure as the LAN in the scenario proposed by
Leythos. Only in my scenario the security of my LAN is *not* reduced.
| Quote: | 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.
|
Wrong approach. You're looking at the hardware first and then consider
what security you can achieve with that hardware. I try to work out what
security I need first and then consider what hardware it would take to
implement this. I'll admit that in the real world you'll have to cut
back sometimes, but you should *never* restrict yourself from the
beginning. That's simply the wrong approach to security.
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 |
|
| Back to top |
|
|
Ansgar -59cobalt- Wiecher
Guest
|
| Posted:
Wed Nov 30, 2005 5:21 pm Post subject:
Re: DMZ design |
|
|
Leythos wrote:
| Quote: | 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.
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 |
|
| Back to top |
|
|
Somebody.
Guest
|
| Posted:
Wed Nov 30, 2005 5:21 pm Post subject:
Re: DMZ design |
|
|
"Leythos" <void@nowhere.lan> wrote in message
news:dh3jf.126591$Hs.74605@tornado.ohiordc.rr.com...
| Quote: | 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.
|
You can put the DB server and th DB App server in separate DMZ's though, and
apply IPS to the in-band traffic to filter out attacks for the few ports and
protocols you have to allow in and out of each zone -- an IPS is going to
update faster than Microsoft patches.
Though this takes a more powerful firewall.
-Russ. |
|
| Back to top |
|
|
Somebody.
Guest
|
| Posted:
Wed Nov 30, 2005 11:55 pm Post subject:
Re: DMZ design |
|
|
"Leythos" <void@nowhere.lan> wrote in message
news:IUkjf.244394$lI5.78042@tornado.ohiordc.rr.com...
| Quote: | 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.
-Russ. |
|
| Back to top |
|
|
Leythos
Guest
|
| Posted:
Thu Dec 01, 2005 12:17 am Post subject:
Re: DMZ design |
|
|
In article <fIljf.4314$43.681@nnrp.ca.mci.com!nnrp1.uunet.ca>, somebody.
@spamout.russdoucet.com says...
| Quote: |
"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.
|
So, users in the LAN people that must process the orders, people that
must see the real-time data, have not connection to the DMZ1 database?
That sure sounds like a static DB to me, and static is simple and easy
to secure without any complications.
How do you handle where the LAN users must access the real-time database
information to process orders, to do misc things with the data, to run
custom reports (like developers) and still block complete access to the
database server in DMZ1?
What makes you think that the Admin Interface using RDP from the LAN
won't allow the compromised DMZ1 Dabase server to ride back into the
LAN? What makes you think that the "file transfer" method won't allow a
compromised file or other back into the LAN.....
Like it or not, if you want LAN systems to have real-time access to the
database that also serves the web, you have exposure and you can't block
it.
--
spam999free@rrohio.com
remove 999 in order to email me |
|
| Back to top |
|
|
Frankster
Guest
|
| Posted:
Thu Dec 01, 2005 12:22 am Post subject:
Re: DMZ design |
|
|
| Quote: | 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 |
|
| Back to top |
|
|
Ansgar -59cobalt- Wiecher
Guest
|
| Posted:
Thu Dec 01, 2005 1:23 am Post subject:
Re: DMZ design |
|
|
Leythos wrote:
| Quote: | 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.
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 |
|
| Back to top |
|
|
Ansgar -59cobalt- Wiecher
Guest
|
| Posted:
Thu Dec 01, 2005 1:34 am Post subject:
Re: DMZ design |
|
|
Frankster wrote:
| Quote: | 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.
|
Anything not easy is going to cost money, so it's the same.
| Quote: | 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?
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 |
|
| Back to top |
|
|
Leythos
Guest
|
| Posted:
Thu Dec 01, 2005 1:46 am Post subject:
Re: DMZ design |
|
|
In article <3v6choF13kt77U1@individual.net>, usenet-2005
@planetcobalt.net says...
| Quote: | 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.
|
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.
--
spam999free@rrohio.com
remove 999 in order to email me |
|
| Back to top |
|
|
Frankster
Guest
|
| Posted:
Thu Dec 01, 2005 4:23 am Post subject:
Re: DMZ design |
|
|
| Quote: | 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.
| Quote: | 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.
-Frank |
|
| Back to top |
|
|
DigitalVinyl
Guest
|
| Posted:
Thu Dec 01, 2005 9:23 am Post subject:
Re: DMZ design |
|
|
"Frankster" <Frank@SPAM2TRASH.com> wrote:
| Quote: | 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
|
Often, I find it isn't about money. It is about the politics. Most of
us get to inherit stuff. As a consultant you inherit almost
everything. If the existing system is foully organized and exposes
the company to problems, capacity, security, performance, or
capability problems, there is all too often a desire to ignore and
hide the problem and pretend it isn't really there. This leads to a
bastardization to work around things. Management doesn't want to admit
they've fucked up in the past. This leads to that ever popular cycle
of "we're the new managemnt-let's change everything". Oldmanagement
would never admit to fuckups , new management wants to blame old
management and pretend that they have some great plan to make things
"better". Technical and real world requirements be damned. |
|
| Back to top |
|
|
Ansgar -59cobalt- Wiecher
Guest
|
| Posted:
Thu Dec 01, 2005 4:27 pm Post subject:
Re: DMZ design |
|
|
Leythos wrote:
| Quote: | 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.
|
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.
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 |
|
| Back to top |
|
|
Ansgar -59cobalt- Wiecher
Guest
|
| Posted:
Thu Dec 01, 2005 4:33 pm Post subject:
Re: DMZ design |
|
|
Frankster wrote:
| Quote: | 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.
|
Only if it has enough buzzwords in it. But this is getting off-topic ;)
| Quote: | 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.
|
True. I was ranting a little here.
| Quote: | 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.
|
True as well. But were here to discuss firewall topics, not general
security topics. That's what comp.security.misc is for.
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 |
|
| Back to top |
|
|
Leythos
Guest
|
| Posted:
Thu Dec 01, 2005 5:18 pm Post subject:
Re: DMZ design |
|
|
In article <3v81h3F14hncrU1@individual.net>, usenet-2005
@planetcobalt.net says...
| Quote: | Do you read only every other word or something? The exposure is AT MOST
the same.
|
At Most - so then at some point it is the same - so, if at some point it
could be the same, then it will be the same (for one reason or another)
and that follows what I said.
| Quote: | In general it is LOWER. So using multiple DMZs IS worth the
effort.
|
In general using multiple DMZ installs if a more secure option, but it's
not always going to work for a particular communications need - like
real-time access from web and lan to a database that is the same
database. Every method has holes, even if they are different holes, as
part of the process. It's a matter of securing the holes as best as
possible.
I'll stick with what I know works and what I've seen stay secure.
--
spam999free@rrohio.com
remove 999 in order to email me |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in