Checklist Item: Set Appropriate IIS Log File ACLs
The checklist recommends the following permissions for the IIS log files:
- Administrators (Full Control)
- System (Full Control)
- Everyone (RWC)
One problem with these settings is that Win2K has no C permission. Windows NT 4.0 has a C for Change permission and Win2K has a Create Files/Write Data special permission, but I don't know whether C refers to either of those permissions. (The Change permission in NT 4.0 is equivalent to the Modify permission in Win2K.) To make matters more confusing, the checklist includes the illogical statement that these permissions "help prevent malicious users deleting the files to cover their tracks."
The recommended permissions give users Read and Execute capabilities on the Logfiles folder. Thus, the IUSR account or any user on the Web server has the ability to change the log files. My research shows that users don't need to write to the log files, and I don't know why Microsoft suggests granting these permissions. I suggest that the only permissions you grant to the log files are to give the local Administrators group and the System group Full Control.
Checklist Item: Set IP Address/DNS Address Restrictions
The checklist suggests that although few people set IP address restrictions, you could do so to prevent specific users from accessing the server. However, you can also use this feature to configure IIS to accept connections only from the firewall, a Network Address Translation (NAT) device, a proxy server, or other network devices and servers that you intend to access the server. IIS then refuses all packets except those from the specified addresses. Some firewalls and application proxies forward the source address of the original request (otherwise, Web logs show the firewall's address for all requests), so the effectiveness of this recommendation depends on the firewall or proxy server and how you configure it.
In addition to using IP address restrictions in IIS, you can implement the same restrictions in IPSec when you implement port filtering. Then, if an intruder defeats IPSec, the IIS rules still apply.
Using DNS address restrictions is a bad idea. Performing a reverse DNS lookup on each Get request is unworkable because not all IP addresses are resolved by using reverse DNS lookups, and a reverse DNS lookup isn't feasible for performance reasons.
Checklist Item: Remove Unused Script Mappings
Removing unused script mappings is widely regarded as a best practice in IIS. However, the IIS Lockdown tool has an even better approach. Instead of removing unrequired application mappings, the tool maps them to 404.dll (a DLL that the IIS Lockdown tool provides for this purpose), as Figure 1 shows. The IIS Lockdown tool's approach is an improvement over simply removing the application mappings because, in some circumstances, absent application mappings are reinstalled on the server without your knowledge. For example, if you enable the Web Based Printing Group Policy, Win2K will reinstall the printer mapping, even after you've explicitly removed it. Additionally, if you install Index Services on the server, the Index Services installation program will install related extensions (e.g., .idc, .htx) if they're absent.
So, although leaving the application mappings in place to better secure the server (i.e., if you plan to use the IIS Lockdown tool) might seem counterintuitive, it's a good strategy. You can extend this technique to further secure the server by mapping extensions such as .inc (include files) and .mdb (Microsoft Access database files) to 404.dll. Then, if an attacker attempts to download a file with those extensions, they receive a 404 File Not Found error, but your applications can still access such files. If you don't plan to use the IIS Lockdown tool or don't plan to manually implement the dead-end strategy, you certainly should remove the extensions.
Other Security Steps
Other checklist recommendations are excellent as written, including the following:
- Executable Content Validated for Trustworthiness
- Disable or Remove All Sample Applications
- Check <FORM> and Querystring Input in Your ASP Code
- Disable Parent Paths
- Disable IP Address in Content-Location
However, you should take a few other steps as well.
Place your Web content on a drive other than your system drive. Placing your Web content on a drive other than your system drive helps mitigate the damage that an intruder who breaks out of the Web content tree can do. If you use this widely accepted technique, an intruder who tries a directory-traversal exploit must move from the Web content drive to your system drive (where you would have additional protections) to look for useful utilities such as tftp.exe and cmd.exe in known locations.
Register
