A Roadmap for Securing IIS 5.0

Transcription

1 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 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. Twenty-One (21) Steps You Should Take to Secure Your IIS 5.0 Server

2 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. 15. Set permissions for your Web files.

3 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. 4. Do NOT install executable files in the same directory as your

4 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. This is found in Add/Remove Programs (under IIS). Manage all aspects of your server by going to

5 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 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 Change the following TCP/IP parameter to greatly reduce your chances for a SYN Flood.

6 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. 15. Indexing can be turned off completely under the General tab in

7 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: /root (Script Source: No, Read: Yes, Write: No, Browsing: No,

8 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. From here you can safely delete almost all of these ISAPI extensions unless you are certain you will use them. Keep in mind that if you plan on serving *.asp pages, then of course you would not want to delete the mapping for that. This isn't deleting the mappings in case you ever decide to go back and create more content that will actually use them, this is simply disabling them. You can of course go back later and re-enable them if you need. Note: your ISAPI mappings will return to the default if you make any system changes via Add/Remove Programs. Also note that the IIS Lock Down tool (updated to ver. 2.1) will remove the mappings, among other things, for you.

9 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 and getting a command prompt on your machine! 22. Audit files that should be protected via NTFS permissions and log your web site hits. If you have good logs that show someone attempting to break in, Security personnel will have a better chance of tracking down the offender(s) and trying to prevent illegal access to your machine.

10 23. Enable the Event Viewer to monitor accesses to specific files and programs.