|
Posted by . on March 2, 2006, 11:59 am
If you were Registered and logged in, you could reply and use other advanced thread options
A DMZ should only contain servers that are a similar risk. For example, you
could put your email servers in one but you sure as heck should not put a
SQL server in the same one.
If you decide to put multiple NICs in a server, make DARN sure that they
cannot route between each other, which could negate any traffic segregation
that a DMZ can provide. Make sure that each network can only route through
its interface and that any default route cannot inadvertently route traffic
to some place it should not go. Make sure you implement full anti-spoofing
on the firewall so you can catch this easily. And remember that an attacker
with admin rights can change the routing (so don't use multiple NICs on
different networks if at all possible!).
> Is there any miracle solution to allow this
> communication to occur other than opening ports on the firewall?
Use an intelligent application-aware firewall, one that understands what the
normal traffic should look like and that can block abnormal traffic
regardless of the port its traveling on. (not a Pix)
> 3) How do you normally handle Windows domain membership for servers that
> are
> in a DMZ. Do you make them part of your internal network's domain, have
> them
> be in their own domain, or leave all of them in a workgroup?
If they don't need domain membership, they shouldn't have it. If they do
need it, you can set them up on a separate domain with a one-way trust so
they trust internal credentials but not the other way around. That way any
account getting maliciously placed on a DMZ server, even a domain admin,
cannot be used against the internal network. Don't make them domain members
just to simplify remote administration.
I would strongly suggest you enlist the help of an outside company to review
what you're planning to do. The more eyes you can put on it, the better off
you'll be, particularly eyes that were not part of the planning process.
Finally, once it's up, sit at the keyboard of each server and do as much bad
stuff as you can. Or better yet, plug in a laptop with a full complement of
tools such as NMap, Nessus, etc. and bang away. Your knowledge of your
internal network will give you an advantage in finding weaknesses. Anything
you can reach or see from the console can also be reached or seen by
malicious code placed on the server.
Remember that an attacker with admin privileges on a server can change its
IP address to anything that's not used on the DMZ subnet. That also means
any rooted server can be used to attack any server on the same DMZ. Make
sure they're all hardened and that unused IP addresses are denied routing.
You may get advice from people pooh-poohing the DMZ concept and recommending
"publishing" internal servers using an application-aware firewall. That's
poppycock. You absolutely must assume that some failure WILL allow an
attacker to get admin access on any server and you must set up your defenses
of last resort to protect against that possibility. If they get admin access
on an internal "published" server, it's game over. Nobody has ever created
an unbreakable firewall. You need to throw as many hurdles in someone's path
as possible to grant you some time to notice what they're doing.
As Scott Culp so eloquently put it "Technology is not a panacea."
Good luck,
Ray
> We are going to be implementing a new in-house online banking platform. It
> will incorporate several different servers (webserver, database server,
> middleware server). I need to determine a secure method for incorporating
> this into our network, and I have some questions:
>
> 1) How many DMZs do you think I should have? The webserver will go into
> one,
> but should the database servers and middleware servers go into the same
> DMZ
> or go into their own DMZs? Or do I just put the database and middleware
> servers into our internal LAN?
>
> 2) The webserver will need to communicate with a core processing server
> that
> resides on our internal LAN. Is there any miracle solution to allow this
> communcation to occur other than opening ports on the firewall?
>
> 3) How do you normally handle Windows domain membership for servers that
> are
> in a DMZ. Do you make them part of your internal network's domain, have
> them
> be in their own domain, or leave all of them in a workgroup?
>
> 4) Not necessarily related to the above questions, but how do you
> generally
> determine how many DMZs to have on your network? Any particular reason you
> wouldn't want to put a number of unrelated servers in a DMZ to minimize
> the
> number of DMZs you need?
>
> Thanks for your assistance!
| 
XML site map