转：http://www.techrepublic.com/article/secure-an-iis-web-server-with-these-10-steps/5226103
Take these 10 steps to secure IIS:
- Set up an NTFS drive just for the IIS application and data. If possible, don't allow IUSER (or whatever the anonymous username is) access to any of the other drives. If the application runs into any problems because the anonymous user doesn't have access to programs on the other drive(s), then use FileMon from Sysinternals to troubleshoot which file it can't access and try working around it by moving the program to the IIS drive. If that is impossible, then allow IUSER access just to that file.
- Set the NTFS permissions on the drive:
Developers = Full
IUSER = Read and execute only
System and admin = Full - Use a software firewall to make sure that none of the end users (only the developers) have access to any other port on the IIS machine besides port 80.
- Use the Microsoft tools for locking down the machine: IIS Lockdown and UrlScan.
- Enable logging using IIS. In addition to the IIS logging, if possible, use logging from the firewall as well.
- Move the logs from the default location, and make sure that they are being backed up. Set up a replication for the log folders so that a copy is always available in a second location.
- Enable Windows auditing on the machine, because there is never enough data when trying to backtrack any attacker's activity. It's even possible to have a script run to check for any suspicious activity using the audit logs, and then send a report to an administrator. Now this might sound a bit extreme, but if security is really important in your organization, this type of action is a good practice. Set up auditing to report any failed account logons. Plus, as with the IIS logs, change the default location (c:\winnt\system32\config\secevent.log) to a different location, and make sure that you have a backup and a replicated copy.
- On a regular basis, go through as many security articles (from various sources) as you can. It is always better that you understand as much as possible about IIS and general security practices and not just follow what others (like me) tell you.
- Sign up to a mailing list for IIS bugs and stay up to date in reading it. One such list is X-Force Alerts and Advisories from Internet Security Systems.
- Finally, make sure that you regularly run Windows Update and verify that the patches actually get deployed.
IIS security tips
IIS servers are especially vulnerable because of the many weapons designed to target Microsoft products. Knowing that, administrators must be ready to implement a variety of security measures. What I would like to provide here is a checklist that a server operator might find useful.
1. Maintain Windows updates: Staying on top of critical updates and security patches is the easiest security measure to take. Consider downloading updates to a dedicated machine on your network and pushing out the updates to the Web servers from that machine. By doing so, you can prevent your Web server from ever engaging in direct Internet browsing.
2. Use the IIS lockdown tool: There are some nice benefits to this tool. There are some drawbacks, however, so use it cautiously. If your Web server interacts with other servers, test the lockdown tool to make sure it is configured so that connectivity to backend services is not lost.
3. Remove the default Web site: Many attackers target the inetpub folder to drop in little goodies that can bring your server to a screeching halt. One way to prevent this attack is to disable the default Web site that installs with IIS. Then, as surfers try to access your Web site by IP address (as one address in a list of tons of IPs they are hitting in a day), the request will die. Point your true Web site to a folder on a back partition, with secure NTFS permissions (more on NTFS later).
4. Uninstall FTP and SMTP if you don't use them: The easiest way into a machine is via FTP. FTP was designed for easy read/write access, and if you try to implement authentication, you'll find that your usernames and passwords are going across the Internet in clear text. SMTP is another service that allows write access to its folders. By disabling those two services, you'll take away a lot of easy fun for hackers.
5. Check your Administrators group and list of services regularly: One day I came into our classroom and found a new user in our Administrators group. By the time someone has gotten this far into your system, he or she has usually dropped in some little time bomb that either can eventually destroy your system or take up all of your bandwidth for the hacker's use. Hackers also tend to leave behind a helper service. Once that has happened, it is probably too late to do anything but reformat your hard drive and restore from the server backup that you should be making each day. Make it a part of your daily/weekly routine to check the list of services on the IIS server(s) and make sure as few as possible are running. You should memorize the ones that should be there. The Windows 2000 Resource Kit comes with a utility called tlist.exe that lists the groups of services running under each instance of svchost. Running that utility may find some hidden services you need to know about. Here's one hint: Any service with the word "daemon" in its name probably isn't native to Windows and shouldn't be on an IIS server. For a list of Windows services and what they do, click here.
6. Regulate write access to server: This sounds simple, but, on a college campus, a Web server has many "authors." Faculty members want to make classroom information accessible to remote students. Staff members want to share job information with other employees. This can be a nightmare of permission levels for each folder on the server. One way to get around that is to install a second server for share and storage purposes only. Then configure your Web server to point to folders on the share server. This one step can allow an administrator to limit write access on the Web server itself to only the administrators group.
7. Implement complex passwords: I came into a classroom recently and found evidence in the Event Viewer of a would-be hacker. He or she had gotten into our lab domain structure far enough to run password-cracking software on each domain user in alphabetical order. If there were any users with weak passwords (such as "password" or changeme" or any dictionary word), then this hacker would have quickly and easily procured access to those users' accounts.
8. Reduce/eliminate shares on Web servers: If administrators are the only users with permission to write to a Web server, then there is no reason to have any shares. Shares are a great enticement to attackers. Again, by running a simple, looping batch file, a hacker can go down a list of IP addresses with the \\ command looking for shares that have been left open to Everyone/Full Control.
9. Disable NetBIOS over TCP/IP: This is a tough one. Many authors want to be able to access the Web server through the UNC pathname. With NetBIOS disabled, they won't be able to do that. On the other hand, with NetBIOS disabled, hackers won't be able to see resources on your LAN, either. It's a tradeoff. If an administrator implements this tool, then the next step is to educate Web authors on how to engage in Web publishing without NetBIOS available.
10. Use TCP port blocking: This is another tough tool. If you know every possible TCP port that is used to access your server for legitimate reasons, then you can go into the properties of your network adapter card's binding with TCP/IP and block all ports but the ones you need. Use this tool with caution, though, because you don't want to lock yourself out of the Web server, especially if you're accessing it remotely. For the latest listing of TCP ports, click here.
11. Check *.bat and *.exe files regularly: Make it a once-a-week practice to run a search of *.bat and *.exe files to see if there are any executables on the Web server(s) that may be a hacker's delight and your worst nightmare. Among these bad guy files, there may be some *.reg files. If you right-click these and choose "edit," then you can see what registry hacks may have been made that enable a hacker access to your system resources. You can then delete keys that serve no purpose to anyone but the person who infiltrated your system.
12. Manage IIS directory security: IIS directory security allows you to deny specific IP addresses, a subnet, or even a domain name. Alternatively, I use a tool called WhosOn (it costs about $200), which lets me know what IP addresses are attempting to access specific files on a server. WhosOn gives a list of "Exceptions," which are cases where more investigation is needed because, for a variety of reasons, the browser is suspect. Once you find a bad guy trying, for instance, to access your cmd.exe, then you can choose—while you are in the program—to exclude the user from further use of the Web server. Of course, on a busy Web site, this could end up being a full-time job! Keep in mind that the server takes a performance hit when you use these tools, especially when you deny an entire domain name. Name resolution has to happen with each visitor to make sure that the user is not part of the denied domain. However, in the case of an intranet, this tool is invaluable. You can make in-house resources available to all users of the LAN and only a few select others.
13. Use NTFS security: By default, your NTFS drives are open to EVERYONE/Full Control until you lock them down. The key is to not lock yourself out. Everyone should be unclicked for all levels of access. Administrator needs full control, your backdoor admin account (if you have one) needs full control, and System and Services each need a level of access, depending on each file. The most important folder is System32, and as few permissions as possible should be allowed on that folder. Using NTFS permissions on a Web server can help lock down the files and applications that Web surfers do not need to be able to access.
14. Manage user accounts: If you have IIS installed, you probably have a TSInternetUser account. Disable it, unless you really need it. This user is easily infiltrated and is a big target for hackers. To help manage user accounts, make sure your local security policy is as tight as possible. The IUSR should have as few rights as necessary.
15. Audit your Web server(s): Auditing takes a big hit on your machine's performance, so don't do it if you aren't going to check it regularly. If you do use it, audit for system events and add audit tools as you need them. If you are using the WhosOn tool mentioned above, then the auditing isn't as important. IIS is always logging access, by default. WhosOn will turn those logs into a very readable database that you can open via Access or Excel. If you just read the Exceptions database regularly, you will have a really good idea about how vulnerable your Web server is at any given time.
Summing up
All of the aforementioned IIS tips and tools (with the exception of WhosOn) are natively available in Windows. Don't forget to try just one at a time before you test your Web accessibility. It could be disastrous if all of these were implemented, then you rebooted to find that you had lost access.
One final tip: Go to your Web server and Run netstat -an at the command line. Observe how many different IP addresses are trying to gain connectivity to your machine, mostly via port 80. If you see that you have IP addresses established at a number of higher ports, then you've already got a bit of investigating to do!