General discussion

Locked

Steps to secure an IIS Web server

By jasonhiner Moderator ·
This question is being posted by the TechRepublic staff. The response(s) from this post may be turned into an article on the TechRepublic site. This is a winner-take-all scenario and the winner will be the person who provides the best and/or most complete answer in our judgment. If there are multiple correct answers we will select the one that was posted first. In addition to offering a generous amount of TechPoints, the winner will also receive a free piece of TechRepublic gear (e.g. a coffee mug, a desk flag, or another item sporting the TechRepublic logo). This competition ends at 11:59 PM on Sunday, May 30. Good luck and let the best techie win!

A systems administrator has been tasked with building an internal Web server to run the company?s intranet. ASP scripts need to be used so an IIS Web server will be needed. The admin has an available Win2K license and a server to put it on, but he?s concerned about security and has not worked with IIS very much. What steps does he need to take to lock down IIS before turning over the server to the team that is building the intranet?

This conversation is currently closed to new comments.

13 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

by CG IT In reply to Steps to secure an IIS We ...

if this were a question posted [that isn't from the TechRepublic staff] I would direct them to the Microsoft IIS Security Center for resouces on how to setup and configure IIS. I would further suggest reading the Microsoft Windows 2003 Security Guide - Hardening IIS Servers for an overview of how to harder IIS Servers.

I would further suggest setting local security policies like "Deny access to this computer from the Network" and setting NTFS permissions. Table 8.11 NTFS Permissions

File Type Recommended NTFS Permissions
CGI files (.exe, .dll, .cmd, .pl)
Everyone (execute)
Administrators (full control)
System (full control)

Script files (.asp)
Everyone (execute)
Administrators (full control)
System (full control)

Include files (.inc, .shtm, .shtml)
Everyone (execute)
Administrators (full control)
System (full control)

Static content (.txt, .gif, .jpg, .htm, .html)
Everyone (read ? only)
Administrators (full control)
System (full control)

Collapse -

by CG IT In reply to

and web site permissions
Table 8.12 IIS 6.0 Web Site Permissions

Web Site Permission: Permission Granted:
Read
Users can view the content and properties of directories or files. This permission is selected by default.

Write
Users can change content and properties of directories or files.

Script Source Access
Users can access source files. If Read is enabled, then source can be read; if Write is enabled, then the script source code can be changed. Script Source Access includes the source code for scripts. If neither Read nor Write is enabled, this option is not available.

Important: When Script Source Access is enabled, users may be able to view sensitive information, such as a user name and password. They may also be able to change source code that runs on an IIS server, and seriously affect the server's security and performance.

Directory browsing
Users can view file lists and collections.

Log visits
A log entry is created for each visit to the Web site.

Index this resource
Allows Indexing Service to index resources. This allows searches to be performed on resources.

Execute
The following options determine the level of script execution for users:

? None ? Does not allow scripts executables to run on the server.

? Scripts only ? Allows only scripts to run on the server.

? Scripts and Executables ? Allows both scripts and executables to run on the server.

Collapse -

by CG IT In reply to

All this directly from Microsoft's Windows 2003 Server Chapter 8 - Hardening IIS Servers. Printer friendly version available and highly recommended be printed for future reference.

Collapse -

by CG IT In reply to

probably some snot nosed know-it-all teenager Joe. Oh hey! you and I answered that one about Exchange 5.5. that this same guy posted.

IIS lockdown and URL scan tools are great for public webs. stink for LAN webs.

Collapse -

by jasonhiner Moderator In reply to

Good stuff, but I was looking for some more personal insights.

Collapse -

by Joseph Moore In reply to Steps to secure an IIS We ...

Wait, are people so bored now they are pretending to be Techrepublic staff????? You have GOT to be kidding me!

Well then, fake Techrepublic person, I guess I shouldn't mention the IIS Lockdown tool with URLScan filter, eh?
http://www.microsoft.com/technet/security/tools/locktool.mspx
The BEST way for Techrepublic employees to lock down IIS.

Collapse -

by jasonhiner Moderator In reply to

LOL! This question is really from a TechRepublic staff member -- honest.

Collapse -

by shmaltz In reply to Steps to secure an IIS We ...

1. Setup a NTFS drive just for the IIS Application and data. If possible don't allow IUSER (or whatever the anonymous username is) ANY 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 cant access and try working around it by moving the program to the IIS drive, if that is impossible than allow access just to that file.
2. Set the NTFS permissions on the drive: Developers = Full, IUSER = Read and execute only, System and admin = Full.
3. Whatever network is setup, make sure that none of the end users (just the developers) have any other (<>80) port access to the machine using a firewall.
4. Use MS tools for locking down the machine, IISLockdown and URLScan.
5. Enable logging using IIS. In addition to the IIS logging if possible use logging from the firewall as well.
6. Move the logs from the default location, and make sure that it is being backed up. Setup a replication for the log folders so a copy is always available some other place.
7. Enable Auditing on the machine, there is never enough data when trying to backtrack an attacker?s activity, whatever data might help is important and audit logs are not any different, besides for backtracking, I believe it is possible to have a script run to check for any suspicious activity using the audit logs and report it. Now this might sound a bit extreme, but if security is really important that it should really be setup with alerting. Selecting as many folders as you could to report failure audits is always a good idea since in most cases the attacker gets denied at first. Setup auditing to report any failed account logons. As with the logs, change the default location (c:\winnt\system32\config\secevent.log) to any other location, and make sure that you have a backup plus a replicated copy.
Continued....

Collapse -

by shmaltz In reply to

...Continued
8. Go through as many Cert and MS security articles as you could, I know it sounds like I don't have what else to write but that is not true, it's just that you can never have enough, and it is always better that you understand alone as much as you could and not just follow what others tell you.
9. Sign up to a mailing list for IIS bugs (one such list: http://xforce.iss.net/xforce/maillists/) and BE ON TOP OF IT. Make sure that you run MS System Update and that it actually updates.

Collapse -

by jasonhiner Moderator In reply to

The winner is newyorker211@yahoo.com. Nicely done!

Back to Windows Forum
13 total posts (Page 1 of 2)   01 | 02   Next

Related Forums