Focus on Microsoft
RE: website inside or outside the domain? Feb 17 2003 11:15AM
Michael Devlin (Michael Devlin figleaves com)
Erik, my apologies for doubting you. A new, independent Forest was not
explicitly mentioned throughout the thread (at least until Laura's post)
and I had (unlike you) assumed best practices were *not* necessarily
being followed.....

Forever the pessimist!

Michael

-----Original Message-----
From: Erik Birkholz [mailto:erik (at) foundstone (dot) com [email concealed]]
Sent: 14 February 2003 20:00
To: Michael Devlin; g0d (at) mrplaydoh (dot) org [email concealed]; cparker (at) swatgear (dot) com [email concealed]
Cc: focus-ms (at) securityfocus (dot) com [email concealed]
Subject: RE: website inside or outside the domain?

Micheal,

I was not saying that people should include their external webservers in
their internal domain structure. That is insane. During penetration
tests, I exploit those type of domain structures with ease. However, a
well managed dmz-admin domain makes the job much harder.

I assumed that a seperate DMZ domain was implied in this thread based on
security best practices.

Hope that clarifies things.

Erik

<SNIP<

Erik,

>I see where you are going, however I think your solution is impractical
>due to manageability and leaves out many variables like the increased
>chance of human error. <SNIP>.

>In my opinion, If you are a large shop, your best option is to use
>Active Directory's Organizational Units to subdivide your web servers
>into a container that has limited permissions. This will allow you to
>apply web server specific group policy to this OU and minimize the
>change for human error by reducing the task of individual server
>configuration.

<SNIP>

>By running your web servers as separate
>workgroups you increase the human interaction and chance for human
error
>as your configure and manage them.

I feel it is the "human error" that you mention that is the reason why
the webservers *should* be in a stand alone workgroup isolated from the
domain, with a dedicated admin responsible for the security and config
of the servers. Keeping a domain in a working yet (fully) secure order
is a (nigh on impossible) 24/7 task, the last thing you need to worry
about is whether the front facing webservers are going to suffer or be
compromised due to AD changes (see cockups). I feel the same goes for
the webservers aswell. (With regards the manageability and the task of
server config: it is worth pointing out that a lot of the GPO auto
config functionality and security benefit reaped from being in a domain
can still be obtained on a stand alone 2000 box through the GPEDIT.msc,
coupled with a bit of scripting!)

Being part of a domain also means you need to open up the inner firewall
to an assortment of protocols (DS, Kerberos, ldap etc etc).... So you
have also got to consider that if you are unfortunate enough to have
your webservers compromised (supposedly the tightest part of your
network) then;
A: there is a good chance you haven't been doing your homework with re:
to your domain security aswell as your webserver security.
or
B: the attacker *really* knows what he is doing and is going to walk
straight into your first DC

Having a defaced webserver is bad enough, but direct access to the whole
network through your webservers..... Nasty!

You also need to look at it from the other side of things.... If your
domain is compromised (that contractor with the shifty eyes?) do you
really want access to your website so the perpetrator can announce to
the world how he got in! By keeping the webservers "locked up" (both
physically and virtually) you can make that step as hard (if not harder)
than approaching it from the front door.

Just my tuppence worth,

Cheers

Michael

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus