With all due respect, your original assertion was that nobody can claim that
a "best practice" is a best practice for everybody, and that's incorrect. A
best practice is a best practice, period. Whether or not a company chooses
to follow that best practice *or not*, for whatever reason (whether valid or
not), doesn't change it being a best practice. You're confusing "appropriate
solution" with "best practice", and the reality is, it is a best practice to
NOT put IIS on a DC. Performance, security, manageability, risk mitigation,
whatever- it's not a best practice to put IIS on a DC. Whether or not SBS
does it is irrelevant. Whether or not some companies choose to do it and
label it an acceptable risk for them is irrelevant. Given the realistic
option to *not* install IIS on a DC, one simply shouldn't do it if one
intends to follow best practices.
The rest of this is just tangential argument stemming from a flawed premise.
However, to toss my two cents in, I guarantee that we in the "big" world
aren't drooling over SBS. It doesn't matter how nifty or wizardy it has been
made, we're just not into it, or we'd be working with small companies rather
than large ones. (I worked with the first couple of releases of SBS and
aside from hating it for other reasons, it just didn't tweak my geek
buttons. It still doesn't.)And lots of us don't think that command-line
configuration (or much else in the OS) should be made "easier"- that
approach is what caused the majority of the problems with Windows security
in the first place. Remember NT? It was "easy". And out of the box, from a
security perspective, it was a pile of horse dung.
None of what you're saying about SBS, however, has anything to do with the
question at hand, which was "should IIS be installed on a DC". No, it
shouldn't. Period. Is it? Yep, in SBS installations all over the world and
in the datacenters of morons (and trust me, there are morons in big
companies who do things like this, which is why I think they're morons).
That still doesn't make it a good idea, and tossing out an entirely
_different_ security risk as support for your argument is specious. Your
assertions about e-mail attachments and administrator logons at workstations
have no relevance to whether or not IIS should be installed on a DC. They're
straw men.
I think you're reading "blanket statements" where they weren't made- stating
a best practice is not a "blanket statement".
And last, the original poster is not using SBS, which makes the SBS rhetoric
all the more irrelevant to his question. :-)
Laura
-----Original Message-----
From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
[mailto:sbradcpa@pacbell.net]
Sent: Wednesday, January 19, 2005 9:10 AM
To: Depp, Dennis M.
Cc: Sullivan Tim P; focus-ms@securityfocus.com
Subject: Re: IIS6 on W2k3 DCs
There's that checklist again :-)
My sister's large entity that she works at, I'm sure does not
put IIS on their DC... yet they allow any employee to click
on any email attachment.
Yeah... they don't have IIS on their DC....meet that security
best practice all right.. but they've got a slightly bigger
issue in my book [and have the virus infections and malware
to prove it].
All I'm saying is that I cringe when hearing "blanket
statements". For the space that 99.9999999% of the folks on
this list work in your statement is correct.
For one wacko SBSer on this list, I still would argue that we
can take the risk and so far with IIS 6, prove it on regular
basis in the newsgroups.
Susan
Depp, Dennis M. wrote:
The fact that IIS can be made secure does not mean it should be
installed on a domain controller. When IIS is installed on a Domain
Controller the impact of a sucessful hack is much greater
than when it
is installed on a member server. If I compromise an IIS
machine, I can
gain access to all the user accounts stored on this machine. In the
case of a Domain Controller, this gives me access to every
account in
the Domain. From here I have access to all the data stored
on Windows
machines in your network.
If the machine that is compromised is a member IIS server the hacker
will only have access to the local accounts and passwords.
While they
can still use this to attack the domain controllers, they will have
some additional effort involved.
While I can protect each IIS server equally well, the damage
potential
of the IIS server on a DC is much greater. This is why it is
considered a best security practice not to place IIS on a DC.
Dennis
-----Original Message-----
From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
[mailto:sbradcpa@pacbell.net]
Sent: Wednesday, January 19, 2005 1:55 AM
To: Depp, Dennis M.
Cc: Sullivan Tim P; focus-ms@securityfocus.com
Subject: Re: IIS6 on W2k3 DCs
Aren't we all missing something here as far as this discussion of
additional protection and IIS in general?
Didn't an IIS server survive OpenHackIV with IIS, SQL and
IPsec? [IIS
5 even]
http://www.microsoft.com/technet/community/columns/secmgmt/sm
0105.mspx
http://www.microsoft.com/technet/community/columns/secmgmt/sm
121504.msp
x
*Using IPsec for Network Protection. Part 1 of 2* Last month I
introduced you to IPsec, a wonderful but sometimes
bewildering bit of
technology. Now that you understand what it is and how it
works, this
month I'd like to highlight IPSec's ability to help solve
three common
security problems.
http://msdn.microsoft.com/library/default.asp?url=/library/en
-us/dnnets
e
c/html/openhack.asp
I know about it...but know that I need wizards to help me do it
right..... but that's just me. I like wizards to help me do my job.
Command lines that include "netsh ipsec static add filter"
needs to be
made easier IMHO.
Susan
Depp, Dennis M. wrote:
--
An open letter to the Security Community::
http://msmvps.com/bradley/archive/2004/12/12/23540.aspx
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
