Re: Should IIS svr NOT be in domain

• Previous message: Roger Abell: "Re: Remote Desktop MITM Concerns"
• In reply to: mikee.netsec: "Re: Should IIS svr NOT be in domain"
• Next in thread: Joe Richards [MVP]: "Re: Should IIS svr NOT be in domain"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Sat, 11 Jun 2005 18:45:24 -0700

One "small" issue that I have with this post, which does include
good advise, is where it says
<quote>
The main problem with IIS being a domain member is the fact that if it
were compromised, the intruder would have trusts and access into your
internal domain/machines.
</quote>
where in fact the word "could" would be more appropriate than saying
"would have . . ."
It is a matter of how well or poorly things are configured.

-- 
Roger Abell
Microsoft MVP (Windows  Security)
"mikee.netsec" <mikee.netsec@gmail.com> wrote in message
news:1118353086.520330.108790@g47g2000cwa.googlegroups.com...
The main problem with IIS being a domain member is the fact that if it
were compromised, the intruder would have trusts and access into your
internal domain/machines.  It would only be a matter of time (and very
little at that) before they would own the entire network.  Making the
machine a stand alone (ie non-domain member) is better, and putting it
into a DMZ would be best.
However, if you pay very close attention to the server configuration,
IIS configuration, patches, and file system permissions, you can do a
lot to secure the server.  Also, if possible, discontinue the use of
FTP, or tunnel it through a VPN (even,sigh,PPTP would be better than
FTP native).  FTP transmits usernames and passwords in clear text, and
that is very bad for any server on any OS.  Any authentication you
perform with HTTP should be done over SSL (HTTPS) protected portions of
your website.
Some tips with the webserver are (these are general and should be
tested before implementing and definitely backup before you implement
them too, you never know....):
- Put the websites on a different logical drive than the OS.  I don't
believe that directory traversals can cross drives.
- Change the default permissions of the directories you put your
websites in.  Usually you can begin with SYSTEM:FULL,
IUSR_<machinename>:R, <Administrator>:FULL.  Depending on the site and
configuration you may have to add IWAM_<machine name> and INTERACTIVE,
but only if you need to.
- Change the file permissions as needed for sublevels of the website.
Keep in mind that changing permissions through Explorer REMOVES the
existing permissions and then REPLACES with the new changes.  If you
make file permission changes on individual files or folders, becareful
how you do it.  Use the CACLS command to make EDITS to the permissions.
- Rename the Administrator and guest accounts.  Make sure Guest is
disabled.  If it has to be part of the domain, rename that
administrator too.  Never underestimate the tenacity of a hacker to go
after default accounts or to brute force them.
- Set strong passwords for them too.  Think of phrases and then
randomize.  ie:  "I'm six feet from the edge" could become
14m6F##T*fmdäseDG.
- Use local accounts for Web and other access, not domain accounts
(unless needed).
- set account lockouts and password policies locally and for the
domain.
- If you need to use domain accounts, create a default security group
for them, then remove them from all other security groups (including
domain users).  This can help ensure that if an account becomes
compromised they still don't have full access to the network.
- remove all unneeded extensions and IIS capabilities.  Anything that
is installed can and will be used against you.  Does anyone really NEED
internet printing?
- Use a firewall, IPSEC policy, something....to control connections
from the webserver to the rest of the network.  If it's a domain member
then it has to talk to the domain controller, so you are limited what
you can do there, but something is better than nothing (most of the
time).
- Read Google Hacking by Johnny Long.  Learn how people can use Google
to obtain information from your server and how you can limit that
information flow to what you want (mostly).
- Don't store any sensitive information on the server if possible.
- Use the baseline security analyzer (not great but free) and fix as
much as you can on the box.
- Microsoft used to have a securing IIS 4.0 checklist (before the IIS
lockdown tool) that would still provide some very good guidelines for
reviewing the security of your IIS server.  Most of them should already
be implemented in IIS 6.0, but it never hurts to check things right?
- setup auditing on your IIS files, and audit what you feel necessary.
Unsuccessful reads on protected content and directories, successful /
unsuccessful writes on all directories.
- audit logons and other things as well
- As painful as it is, review your audit logs!  Maybe you can catch
something amiss before the box really gets exploited.  Or, you might be
able to at least know who, what, and how.  Why is nebulus and you might
not like the answer anyway.
- Review and protect you IIS logs (see above).
- Patch the box, all of it.  If you are not sure about a patch, back it
up, patch it anyway.  At least then you know YOU broke the box, and
most likely how to recover it.
- Make sure you let your web developers know what you are doing.  More
than likely if the box isn't all that secure, they are taking advantage
of some of the "shortcuts" you should be disabling.
- Read all you can about securing IIS....then read some more...and
don't forget to implement some of what you read (back it up first....).
- Do some sort of penetration testing yourself or hire someone if the
server is important.  You are exposing not just the box, but your
network, and if you value it it's likely that someone out there values
it as well, if not for the same reasons.  Remember, your network is
valuable to any hacker, if just for the bandwidth, processing, storage
capabilities, and bragging rights.
This isn't all that detailed or comprehensive, but it should give you
an idea as to why having a production web server being part of a domain
is not really a great idea.  But, there is a lot you can do to lock it
down.

• Previous message: Roger Abell: "Re: Remote Desktop MITM Concerns"
• In reply to: mikee.netsec: "Re: Should IIS svr NOT be in domain"
• Next in thread: Joe Richards [MVP]: "Re: Should IIS svr NOT be in domain"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]