DMZ design

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

-Frank

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

cu

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

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

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.

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

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

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 f***ed 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.

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

Only if it has enough buzzwords in it. But this is getting off-topic ;)

True. I was ranting a little here.

True as well. But were here to discuss firewall topics, not general security topics. That's what comp.security.misc is for.

cu

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.

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.

I'll take that for a 'yes'.

cu

Do you plonk everyone that doesn't see things your way?

I happen to have a point that is different than yours, works for all of our clients, has not been compromised, and is easy to manage at the same time. Just because I don't agree with you doesn't mean we can't discuss it like men, and I think it's childish of you to plonk anyone.

Back to some definitions and basics. A LAN can be many things, none of which are accessible by public IP address assignments.

A DMZ is a set of components isolated from the Internet and the backend processors by firewalls on both sides Public -- FW(#1) --- DMZ systems -- FW(#2) --- backend processing(BEP)

Best practices says the corporate LAN should not be accessible from the DMZ or the public Internet.

The WWW.* systems have components in the DMZ which may be compromised from time to time (which is why we need backups, pagers and have jobs). By segmenting the networks and using non-default ports in the backend processing, access from the Public net to the BEP can only be achieved by software in the DMZ properly configured (ie no scripting kiddy is crossing two firewalls which have no natural routes into the BEP). Now you can run a DBMS in the BEP subnet and again, the kiddies can't run injections scripts and smash your data.

Yea, there's much more to configure, and you need to bind the applications externally rather than default address and ports, but it's also safe, secure, and scalable when expansion is needed.