Re: Should IIS svr NOT be in domain

From: Roger Abell (
Date: 06/12/05

  • Next message: Roger Abell: "Re: Should IIS svr NOT be in domain"
    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
    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.
    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" <> wrote in message
    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
    - Use local accounts for Web and other access, not domain accounts
    (unless needed).
    - set account lockouts and password policies locally and for the
    - 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, 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
    - 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

  • Next message: Roger Abell: "Re: Should IIS svr NOT be in domain"

    Relevant Pages

    • Re: Please help refresh my memory on AD DC
      ... use only domain user accounts. ... "Meinolf Weber" wrote: ... Remote server ... Also that one for IIS. ...
    • Re: Permission Problems SBS2003 R1
      ... website on the SBS server? ... Default permissions and user rights for IIS 6.0 ... Step 3: Please check the permissions in IIS manager: ... Step 4: Re-running CEICW on SBS server: ...
    • RE: SBS 2003/member Web Server and ISUR access
      ... NTFS permissions for the directories and files ... the IIS content directories have the following permissions. ... Server Extensions, ASPNET, SQL Server and other software is installed. ... The IUSR_MachineName account has the following permissions. ...
    • Re: CGI apps break after DCPROMO an IIS6 server
      ... This is one of those things different on a DC vs a member server in regards ... The "built in" accounts have the minimum and necessary privileges to run ... >privileges listed in F1-help of IIS Manager UI required ...
    • [NT] Heap Overrun in HTR Chunked Encoding Could Enable Web Server Compromise
      ... This patch eliminates a newly discovered vulnerability affecting Internet ... in IIS 4.0 and 5.0, and could likewise be used to overrun heap memory on ... allowing code to be run on the server. ... * Microsoft has long recommended disabling HTR functionality unless there ...