In order to continue in the effort to harden your popular server roles, let's take a look at how to secure your...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
IIS file servers running Windows Server 2003.
Securing virtual directories
An Internet Information Server has a bit of virtual-directory security built into it. It has permissions for reading, writing, executing scripts and other basic privileges stored within a virtual directory. These permissions are also independent of file-system permissions. Incidentally, this has been true for every version of IIS since its inception. Here's a reminder of the available rights:
- Script source access allows users to view the source code to scripts and applications within the selected directory, assuming that users have read or write permissions to that directory.
- Read access allows users to view or download files or directories, along with their individual properties.
- Write access allows users to upload files to the selected directory. It also allows them to change existing files within that directory.
- Directory browsing allows users to view an HTML page that lists the contents of the selected directory, including any subdirectories. Note that the subdirectories listed in this view are physical file-system directories and not IIS virtual directories.
Make sure any virtual directories on your site have the proper permissions set. To set these rights, use the IIS Manager, found under Administrative Tools inside Control Panel. Once the applet is launched, expand the computer tree in the left pane and expand the node called Web Sites. All of the sites currently on that IIS machine are listed here. To set the permissions, right-click the name of a site and choose Properties. Then, click the Home Directory tab, and you'll be greeted with a screen similar to the following:
On this page, you can make the necessary adjustments to permissions based on what content you have on each Web site. You can also follow the same procedure for each virtual directory on a Web site to further fine-tune the "virtual" permissions that IIS gives you.
The IUSR account
As you might already know, users browsing Web content on your IIS machines are actually logging into a guest-like IUSR account on your machine or directory service. If they're using an account on the system, you can set permissions for that account on the file system to further reduce the chances of unauthorized access.
Out of the box, IIS 6.0 in Windows Server 2003 sets the following restrictions on the NTFS permissions given to the IUSR account:
- A user logged on through the IUSR account can only read and list the contents of the Web root directory. There are no execute permissions present, so scripts cannot run, and no one can write files to the directory.
- The IUSR account has read, execute and list contents permissions inside the Windows directory, just as the Authenticated Users group does.
- You can use NTFS permissions to lock down IUSR's ability to access content on your site even more. Make sure sensitive data on your system is locked down from access to the IUSR account on your server.
Internet Services Application Programming Interface (ISAPI) is CGI's like-minded brother on the Windows platform. It allows for dynamic extensions to static HTML content and to technologies like Active Server Pages, .NET and other dynamic languages that use ISAPI filters to interact with IIS. Of course, this opens up a potential security hole.
You need to make sure that the only ISAPI filters configured on your system are those that are in use. (You can find ISAPI filters in the Properties sheet for any Web site.) For most systems, that would be the ASP.NET service. Look through your Web root directory and note the extensions on all of your content. Are there any that differ from .HTM? If not, make sure any filters that are listed in the Properties tab are removed.
Administrative and default pages
Lots of Web-based programs often come with sample files, instruction pages and installation scripts that assist you in setting up and using the programs easily. I used to own a Web-hosting business, and more than 75% of the scripts I used on a day-to-day basis -- whether they were ones that my customers needed installed or ones that I used to manage the systems -- came with install scripts and default pages that allowed accessing an account, a database or even worse -- a machine -- very easy to do.
IIS is no different than these other programs. Here's an action list of items to get rid of, assuming you're not actively using them:
- IIS 6.0 comes with a Web-based program that allows you to remotely administer an IIS server from afar. Bad idea. Don't install it.
- FrontPage extensions also expose a lot of functionality that might not otherwise be needed. If you've installed the extensions just because you don't feel like digging out the Windows CD (if you ever need it again), then go ahead and uninstall it.
- Delete the Microsoft SharePoint Administration site if you aren't using the extensions or any type of SharePoint site.
- Get rid of Web-based printing by deleting the folder called Printers from the Web root.
About the author: Jonathan Hassell is an author, consultant and speaker residing in Charlotte, N.C. Jonathan's books include RADIUS and Learning Windows Server 2003 for O'Reilly Media and Hardening Windows for Apress. His work is seen regularly in popular periodicals such as Windows IT Pro magazine, SecurityFocus, PC Pro and Microsoft's TechNet Magazine. He speaks around the world on topics including networking, security and Windows administration. He can be reached at firstname.lastname@example.org.