Re: Should IIS svr NOT be in domain
From: Roger Abell (mvpNOSpam_at_asu.edu)
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
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" <email@example.com> wrote in message news:firstname.lastname@example.org... 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.