This document was grafted together from various Web and other sources by Thomas Jerry Scott for use in his Web and other Security courses. Jerry hopes you find this information helpful in your quest to secure your IIS 5.0 server.
A Roadmap for Securing IIS 5.0
Microsoft's Internet Information Services (IIS) default install contains several known holes and exploits that can cause significant or even total data loss or compromise. Fortunately there are some basic steps you can take to lock down your server to prevent such attacks from occuring.
This document will provide explicit techniques that can be used to effectively secure your IIS servers without losing major system performance and functionality.
Had a few of these steps been taken, major attacks like Code Red I and II and Nimda could have easily been prevented even without the system patches!
Of course, installing the patches is always the recommended route for any major system in order to ensure the most basic security level. Vulnerabilities often go unknown and are quietly solved in patches and service pack releases. Patches can be obtained for most Windows systems at http://windowsupdate.microsoft.com.
Note: This document is tailored to cover security essentials for IIS Servers running Windows 2000 Server and Advanced Server. Many of these techniques can be applied to NT 4.0 systems, but not all tools will be available.
1. Determine the role of your machine.
2. Do NOT install executable files in the same directory as your web content.
3. Delete all the files from selected directories. 4. Delete the /MSADC folder.
5. Use IPSec to allow your IIS server to communicate with the Domain Controller and other internal machines.
6. Install the IIS Manager snap-in.
7. Create a group policy on your Domain Controller that can be pushed out to all your IIS servers in a domain.
8. Disable all unnecessary services in the Administrative Tools. 9. Disable unused network bindings.
10. Change a certain TCP/IP parameter to greatly reduce your chances for a SYN Flood.
11. Implement some sort of authentication method. 12. Set your NTFS permissions and IIS permissions.
13. Install the Security Configuration and Analysis snap-in. 14. Disable the Indexing Service.
16. Divide your content into different folders, each with different permissions.
17. Never allow write and execute privileges to a folder. 18. Delete all unused ISAPI extensions and HTTP verbs. 19. Use URLScan.dll.
20. Prevent directory traversals.
21. Audit files that should be protected via NTFS permissions and log your web site hits.
Detailed Steps to Securing IIS 5.0
The rest of this document provides more detail for the steps above. 1. Determine the role of your machine. You need to ask yourself the
following simple question.
Is your server going to serve web pages, host FTP content, or both?
2. Do you really need *.asp or cgi-bin support for pages?
3. Ideally, you only want one major service per system. However, often due to budget constraints, you may find it necessary to combine services on the same machine. In IIS, you should definitely put everything you are serving to the public on a
different slice of your drive. So rather than put your pages on the C:\ drive, make a new partition and put your web/FTP content there.
web content. Otherwise, in the event that outside parties are able to access your web volume, they might be able to execute
programs that could damage your volume.
5. Delete all the files from the following directories:
¡ \Inetpub\iissamples ¡ \InetPub\AdminScripts
¡ \Program Files\Common Files\System\msadc\Samples ¡ \WINNT\help\iishelp
¡ \WINNT\System32\Inetsrv\iisadmpwd ¡ \WINNT\web\printers
Deleting these default files is crucial since many current exploits take advantage of default files and samples, especially the
printers folder, including the \printers virtual folder. 6. Delete the /MSADC folder.
7. Use IPSec to allow your IIS server to communicate with the
Domain Controller and other internal machines. The only packets that should not be filtered should be the traffic leaving the
machine on port 80 (web traffic). Use ipsecpol.exe to set up your filtering rules.
8. Install the IIS Manager snap-in.
Start --> Administrative Tools to use IIS Manager.
9. Create a group policy on your Domain Controller that can be pushed out to all your IIS servers in a domain.
This will enforce a policy that can be customized on each host, but will allow a very tight and configurable configuration that can be centrally managed. Security templates can be created by the user or the domain administrator, or you can download and customize good security templates that already exist from The NSA (a great resource) or from Microsoft.
10. Disable all unnecessary services in the Administrative Tools. A web server only needs World Wide Web Publishing Service, Remote Procedure Call, Event Log, Protected Storage, and Windows NTLM Security Support Provider.
11. Disable unused network bindings.
Right-click on My Network Places and select Properties. Unbind File and Printer Sharing at the minimum. This would have
stopped one of Nimda's infection vectors. You can also safely disable NetBIOS over TCP/IP in Windows 2000.
Select the Advanced tab under TCP/IP Settings and check to
disable NetBIOS over TCP/IP. This will set your server to retrive information from file servers and domain controllers via port 445 automatically rather than port 139.
Browse to: HKEY_LOCAL_MACHINE -->
\System\CurrentControlSet\Services\Tcpip\Parameters --> SynAttackProtect
and change the value data to '2'.
This will force the remote host to comply with standard TCP/IP connection protocol.
Implement some sort of authentication method, even if it is only basic (i.e. username and password) for specific folders.
13. Set your NTFS permissions and IIS permissions.
Set your NTFS permissions first, completely disabling write access to any web folders. If you run scripts, put those scripts into another folder and reference them that way.
You may also wish to change the folder that contains your scripts to display something like 'scr' instead of "scripts" or "cgi-bin" or "bin" as most unmanaged vulnerability scanners look for these directories first by name. If you have renamed them, then only a flesh and blood hacker will know they exist.
14. Install the Security Configuration and Analysis snap-in
Check "No access without explicit anonymous permissions" under Local Policies and Security Options. This denies all null sessions and related attacks. Disable the Indexing Service. It is completely unnecessary for your web server, though if you feel you still need it for your machine you should disable indexing on your web content folders.
Windows Explorer.
16. Set permissions for your Web files.
Most files that deal with web content need only the following permissions available: List Folder/Read Data
Read Attributes Read Extended Attributes Read Permissions
This applies to files like *.html, .asp, .jpg., .txt, etc.
The only permissions needed for *.dll and *.exe files should be Traverse Folder/Execute File.
17. Divide your content into different folders, each with different permissions.
Remember that there are separate NTFS and IIS permissions, so all your folders should be marked read for the generic user (i.e. the person viewing the page, not the Administrator, or content developer).
A good way to lay your your folders would be: /root (normally defaults to wwwroot)
/scr (your scripts folder, if you need one)
/exe (for all your executables - make sure the NTFS permissions are set to Traverse Folder/Execute File instead of Read)
/images (optional, though easier to manage, especially if you want to log hits to just your pages and not every image). For these folders you will want the following minimum permissions:
Log: Yes, Index: No, Execute: None)
/scr (the same as above except for Read: No and Execute: Scripts Only)
/exe (the same as above except for Execute: Scripts and Executables)
/images (the same as /root but set Log to No if you don't want to clutter your log files with requests for images)
Never allow write and execute privileges to a folder.
18. Delete all unused ISAPI extensions and HTTP verbs. This is very important and would have completely prevented Code Red and Nimda from compromising a system. This is a small detail, but will save you a lot of time and effort if an attack similar in nature to Code Red and Nimda were to hit again.
Go to Website Properties > Home Directory > Configuration --> App Mappings.
19. You can also change the HTTP verbs on your mappings by selecting Edit and allowing only GET, since this is usually the only verb you'll need. If your content contains a form, you will also need POST.
20. Use URLScan.dll.
This can audit all incoming requests for certain ISAPI filters and drop those attempts to access filters that do not exist or should not be accessed. URLScan can be highly configured to suit your IIS Server.
21. Prevent directory traversals.
Traversals can account for a HUGE portion of attacks. In one University study, traversals caused an average of 500,000 alerts per month.
Go to Website Properties > Home Directory > Configuration --> App Options,
and uncheck Enable Parent Paths. This step is also crucial to maintaing a base level of security for your site. This prevents attackers from entering a URL such as
http://yoursite.com/../../../../../../cmd.exe?/ and getting a command prompt on your machine!
22. Audit files that should be protected via NTFS permissions and log your web site hits.
