IIS Security Checklist

[ltr][LEFT][SIZE=4][B]IIS Security Checklist[/B][/SIZE]

The following checklist is a summary of the security points which should be checked prior to bringing an IIS server online. In cases where these points are not followed, the admin may want to securely document the known security issues for referral should a security compromise occur.

[B]General assumptions:[/B]

- No IIS on a domain controller

- Install only services needed (ftp, www, smtp, nntp). Mailing out does NOT require smtp; use CDOSYS.DLL (a COM based method native to Windows) or a 3rd party executable like blat.exe for web applications that require outgoing mail.

- Virtual directories are NEVER used across servers.

- The underlying Windows OS has been secured.

- Only system administrators are local administrators.


[B]Design Guidelines[/B]

- Websites should NEVER be on the system drive.

- Setup SSL if transmitted information is sensitive. Require SSL (Remove ability to access via port 80) if SSL is enabled.


- All FTP sites, and as needed WWW sites should enable IP filtering for stanford-only sites. Ipsec filters can be used to accomplish this.

- Virtual directories should be used as little as possible. They aren’t needed unless you need to span drives. And if you need to span drives reconsider based on the security implications.

- Remove NTFS write perms everywhere possible.

- Don’t make it easy to find your scripts and code. Hackers target code seeking vulnerabilities they can use to take control of the server. Good ideas include:

o Don’t use an obvious name for your scripts directory. ‘Scripts’, ‘cgi-bin’, ‘exchange’, and ‘bin’ are so common that automated tools look for them.

o Consider renaming the extension on all of your scripts to something uncommon. For example, rename myscript.asp to myscript.dum. This will require adding an ISAPI extension mapping for .dum to the appropriate code handler (asp.dll in this case). This makes your scripts harder to find. Incidentally, specifically renaming all .asp scripts to .html works fine without modifying the ISAPI extension mapping.

o Consider compiling scripts into dll files. This not only protects the code from analysis, but it also results in a major performance gain. Compiled code runs about 20 times faster.

o Web applications (i.e. scripts and executables) only need a limited amount of permissions to run properly. Giving more permissions than is necessary allows a malicious hacker to download and analyze your code for vulnerabilities. The minimum permissions needed are: NTFS: Read, IIS: Execute. IIS: Read is NOT required, and will allow a hacker to download your code.

- Be careful when using the Add/Remove control panel on an IIS Server. If you open the Windows components, Windows will inadvertently reset all ISAPI filter and extensions to the default, and may reset other things. This is a poor design by Microsoft that you need to be careful with.


[B]Installation configuration[/B]

- Delete all default virtual directories (icon w/ world on top of folder) and application roots (icon w/ green ball in box)

o Delete iisadmin

o Delete iissamples

o Delete msadc.

o Delete iishelp

o Delete scripts

o Delete printers

- Delete ALL default content.

o Delete %systemdirectory%\inetsrv\iisadmin

o Delete %systemdirectory%\inetsrv\iisadmpwd

o Delete inetpub\wwwroot (or \ftproot or \smtproot)

o Delete inetpub\scripts

o Delete inetpub\iissamples

o Delete inetpub\adminscripts

o Delete %systemroot%\help\iishelp\iis

o Delete %systemroot%\web\printers

o Delete %systemdrive%\program files\common files\system\msadc. Only websites that integrate with Microsoft Access databases need msadc.

- Configure Default Website with extremely secure settings (e.g. require ssl, Integrated Windows auth only, accessible from only one IP, NTFS perms to none on an empty home directory, etc.), then stop the site. This results in a broken default website that 80% of hackers will blindly attack, instead of your real website.

- Configure all website(s) with host header matching the DNS name of the site. Go to ISM, Web Site tab, Advanced button, Select “All Unassigned” (or the specific IP) and Edit Button, and designate the host header in the appropriate field. Do this for both http and https. Do NOT configure default website with host header. This will prevent 90% of all automated hacking tools from working by sending them to your crippled default website.

- Home directory IIS perms: Enable Read and Log. TURN OFF Write, Index, Browsing, Script Source Access (only WebDAV uses this), and Frontpage Web permissions. Set execute permissions to None. Enable execute permissions for the directory that holds your scripts.

- Disable all unnecessary ISAPI filters. Do this under ISM, ISAPI filters tab.

o Delete the Frontpage ISAPI filter (or extensions on older IIS servers), if you have a choice. If Frontpage ISAPI (extensions) is required, make them read only. On older IIS servers, you disable Frontpage extensions with the following command: “c:\program files\common files\microsoft shared\web server extensions\40\bin\fpsrvadm –o uninstall –p all”.

o Digest Authentication. This authentication method requires support for reversibly encrypted passwords—which is a bad idea. Reversible encrypted passwords aren’t supported in the Stanford Windows Infrastructure. Delete this filter.

o HTTP Compression. This filter allows compression of the http stream. This is a nice feature, but might be at the expense of security.

o SSL. It’s unlikely you wouldn’t want SSL support, but if you don’t need it, then delete it.

- Delete the dll files associated with ISAPI filters that you disabled. Frontpage: fpexdll.dll, Digest: md5filt.dll, Compression: compfilt.dll, SSL: sspifilt.dll.

- Unmap the following extensions (if possible):
.asa, .asp, .bat, .cdx, .cer, .htr, .htw, .ida, .idc, .idq, .printer, .shtm, .shtml, .stm
Within ISM, go to the Home Directory tab, and choose Configuration button.

- Disable “Enable Parent Paths” setting. Go to ISM, Home Directory tab, Configuration button, App Options tab, uncheck checkbox. This prevents malicious web traversal without knowing the underlying directory structure. Web developers can not use paths like ..\..\default.htm and must use fully qualified paths.


[B]Patch level[/B]

- Apply Service Packs and hotfixes. UpdateExpert makes this very easy or Microsoft’s HfCheck tool can be used.

- Install high encryption pack (comes with Windows 2000 SP2) so 128 bit encryption is available.


[B]Authentication model:[/B]

- Basic authentication disabled at site level, virtual directory level, directory level –Everywhere!

- Digest authentication disabled everywhere.

- IUSR & IWAM accounts should not be domain users nor should they be guests. If no anonymous access is required, delete these accounts.

- If web data is ultra-sensitive consider placing server outside a domain.


[B]Authorization Changes[/B]

- Enable IIS auditing, change to W3 extended logging, and check that the info that is being logged is appropriate. (e.g. Is username needed?) Consider enabling the following items: Date and time, IP address of the client, IP address of the server, Server port, Username, HTTP method used to access your site, URI Stern, URI Query, Status of the request.

- Set permission to IIS logs to system and local administrators only.

- Remove write perms to hklm\software for non-admin accounts. Administrators & System: FULL, Everyone: Read/Execute

- Restrict NTFS perms to ALL executables on system. NTFS perms: Administrators & System: FULL, Users: Read/Execute. Give IUSR account execute permissions sparingly.

- Restrict perms to any script interpreters such as perl. NTFS perms: Administrators & System: FULL, Everyone: Read/Execute. Give IUSR account execute permissions sparingly.

- Ensure Everyone has only read on:
Web root
%systemroot%
%systemroot%\system32
%systemroot%\system32\inetsrv
%systemroot%\system32\inetsrv\asp
%systemroot%\program files\common files\
[/LEFT]
[/ltr]