Best Practices for Publishing Web Shares to the Internet

Web shares, or virtual directories, can be very useful in publishing corporate information to users both inside and outside the company's network. By using the existing server or DFS (distributed file system) shares within the company, administrators and end users can publish content without the use of specialized Web editing tools.

Securing such shares requires you to pay special attention to both the underlying operating system and the method by which the end user is accessing the resources. Using both NTFS permissions and Web-based permissions to ensure the security of the Web shares is the best possible method because it provides a layered approach to securing the Web shares.

You should pay special attention to the root folder of each disk volume. By default Windows Server 2003 installs the Everyone group on the system volume. This is the volume where Windows Server 2003 is installed. By default this group has Read and Execute permissions on any new folders that are created on this volume. It's a best practice to remove this group to avoid leaving the entire directory structure vulnerable to attack.

Protecting the Perimeter

Companies should always use a firewall plan and an intrusion detection system (IDS) to create a way to monitor traffic to and from their Web servers. It is called a firewall plan because it's not just a hardware or software product. A firewall plan involves multiple products and security planning, including what to do when there is a compromise in the company's security. Compromises will happen; what you do to reduce exposure is an essential part of the plan.

Part of the firewall plan can be virtual private network (VPN) access and some form of Internet authentication services such as the one provided by RADIUS. Both of these services are available on the Windows Server 2003 platform. The VPN approach should be used when accessing any enterprise resources from outside the firewall perimeter. As is discussed later in this chapter, in "Establishing Virtual Directory Permissions," authentication and document access can be provided by front-end Web servers that are placed between two firewalls in what is known as a demilitarized zone (DMZ).

Protecting the Server Content

There are numerous best practices for protecting Web servers facing the Internet. Here are just a few ways to reduce the impact of a security breach:

• If you have the server resources, do not host the Internet Information Services (IIS) server on a domain controller or even a domain member if possible. The less participation the IIS server has with the domain the better (from a security standpoint).

• Enable only the services that the server will be hosting. Inadvertently forgetting that a service is on or not yet configured is probably the biggest security risk on an IIS server.

• Secure the NTFS permissions on the partition where the operating system is loaded. Remove nonessential groups and allow only administrators and designated groups access to the OS partition and its folders.

• Move the Web and FTP root directories to a partition other than where the operating system resides. This ensures that if a traversal of directories takes place the attackers do not have access to operating system or IIS functions.

Following the HTTP Authentication Request

IIS authentication is the front line of defense in the access authorization process. When a user makes an HTTP request for a Web page several security- related steps take place. The sequence of events is as follows :

1. Is the request coming from an IP address, subnet, or domain name that has authorized access?

2. Is the user required to authenticate with a username and password or .NET Passport?

3. Do the IIS permissions allow the specific HTTP action the client is requesting?

4. If the virtual directory is located on another host, do the UNC share permissions allow access?

5. Finally, do the NTFS permissions allow the authenticated user or anonymous account access to the OS resource?

Following the order in which IIS allows access makes your troubleshooting efforts easier. By turning off or lessening levels of authentication you can determine which authentication method might be disallowing the delivery of the Web content to the end-user.

Allowing Trusted Networks

Narrowing the field of possible vulnerabilities is one of your best tools in protecting Web-based content. By allowing only trusted IP addresses or disallowing known abusers to access the Web content you can keep your eyes on efficiency. To enable or disable IP addresses, IP ranges, or domains perform the following steps:

1. Open IIS Manager, and click on the desired server.

2. Right-click on the Web site you want to protect, and choose Properties.

3. Click on the Directory Security tab, and select Edit in the IP Address and Domain Name Restrictions section.

4. Initially the By Default, All Computers Will Be Granted Access radio button is selected. You now have two possible options:

• Choose the Granted Access radio button and then choose Add. This option enables you to Deny Access to individual IP addresses, Groups of computers (by subnet), or by Domain names .

• Choose the Denied Access radio button and then choose Add. This option gives you the ability to Allow Access to known trusted IP addresses, Groups of computers (by subnet), or trusted Domains.

The method by which you choose to limit access will most likely depend on whether the Web site will be used solely on an intranet, in which you should allow access by domain name. If the Web site is going to be accessed via the Internet as well, you might have to grant access to domains as well as front-end Web servers and known IP addresses or subnets of users.

Creating the Virtual Directory

To publish content to the company's intranet or to an SSL-secured Internet site, you need to create a Web site in IIS and then Virtual Directories under that Web root. These Virtual Directories can exist in the directory structure of the server that IIS is running on, or a UNC (Universal Naming Convention) path . These Virtual Directories can be created either from the IIS Management console or in the file system using Explorer.

IIS Administrator Needs to Allow Either Browse or Directory Browsing

To allow content to be viewed that doesn't have an HTML formatted home page, the IIS administrator needs to allow either Browse or Directory Browsing. Otherwise an error page will appear instead of the desired folder contents.

Creating a Virtual Directory with IIS Manager

To create a Virtual Directory in the Internet Information Services (IIS) Manager, perform the following steps:

1. Right-click on the Web site to which you want to publish.

2. Select New, Virtual Directory.

3. The Virtual Directory Creation Wizard opens; click Next .

4. Fill in the Virtual Directory Alias box. (This should be an abbreviated version of the directory or UNC that will be published.) Click Next.

5. Fill in the Path box (this can either be a folder located on the IIS server or a UNC path to a share). Click Next.

   • If the Path box was filled in with a locally hosted folder the Virtual Directory Access Permissions page will be displayed. Choose the appropriate permissions and click Next.

   • If the Path box was filled in with a UNC path, the Security Credentials page will be displayed. Either fill in the desired username and password of an individual user or select the check box stating Always Use the Authenticated User's Credentials When Validating Access to the Network Resource and click Next.

6. Finally, click Finish.

Creating a Virtual Directory with Windows Explorer

You have the option of creating a Web site Virtual Directory through the Windows Explorer. This is an easy way to publish content quickly that resides on the IIS server without opening up the IIS Manager tool. To create a Web share, perform the following steps:

1. On the IIS server navigate to the desired drive and right-click on a folder to share, and then select Properties.

2. Click on the Web Sharing tab and select the desired Web site from the pull-down menu.

3. Select the Share This Folder radio button shown in Figure 19.1. The Edit Alias dialog box appears.

   Figure 19.1. The Edit Alias dialog box.

   

4. Enter an abbreviated Alias for the Virtual Directory. Also select the appropriate Access Permissions and Application Permissions for this folder. Click OK twice.

Establishing Virtual Directory Permissions

When creating either a new Web site or a virtual directory under that site, you must decide who will have access, and of which type to the published content. A preferred method of protecting the content is by first choosing the access rights to the content.

Securing Virtual Directories Mapped to Local Directories

IIS Virtual Directories that reside on the local server are secured by both the underlying NTFS permissions and the permissions granted through IIS. To set the permissions on a locally hosted Virtual Directory perform the following steps in IIS Manager:

1. Right-click on the virtual directory to secure, and then select Properties.

2. On the Virtual Directory tab find the section called Local Path.

3. In the Local Path section, select the desired boxes that are associated with access permissions:

   • Script Source Success. Used with IIS features such as FrontPage and WebDAV to allow access to executable content as long as Read or Write, or both are enabled.

   • Read. Allows the browser to read content published within the virtual directory folders. If this box is checked without any others being checked it creates a read-only scenario.

   • Write. This option is desirable when publishing folders where contributors might post content such as a document repository or through IIS tools programs like FrontPage and WebDAV.

   • Directory Browsing. You should enable this feature when no home page document is present in the root folder of the virtual directory. This feature is useful when publishing a set of folders and documents that might normally reside on a file server in a legacy Windows environment.

Securing Virtual Directories Mapped to Windows Shares

As described previously, virtual directories can point to UNC paths containing content hosted on other servers or workstations on the local area network. Shares can have their own permissions as well. It's a best practice to leave the share permission to Everyone Full Access. This method makes it much easier to track the applied permissions on folders and files within the enterprise.

Placing permissions on the folders and down to the files, if desired, allows for more granular management and auditing of file access. NTFS permissions enable you to discretely allow or deny any group or user permissions down to the file level. Authentication either directly from the Web site or passed through to the host of the UNC share will determine the permissions allowed to that user.

IIS 6.0 now allows you to use pass-through Web authentication to UNC share and NTFS permissions. Simply put, the Web server sends the authentication request on to the server or workstation that is hosting the virtual directory UNC resource and asks permission for access. The steps to allow this process to take place are as follows:

1. Open IIS Manager, select the server and click on Web Sites, and then the Web site that is hosting the virtual directory.

2. Right-click on the virtual directory to secure and click Properties.

3. Click on the Connect As button located next to the Network Directory box containing the UNC path.

4. In the Network Directory Security Credentials dialog box you can choose either of the following:

   • Choose a static User Name and Password to authenticate against the remote UNC share and NTFS permissions.

   • Use delegation to pass the Web user's username and password to the computer hosting the UNC share. To do this select the Always Use the Authenticated User's Credentials When Validating Access to the Network Resource check box. When this box is checked the User Name and Password boxes become grayed-out.

Choosing Proper User Access Controls

Just as you set permissions on traditional file shares, you must also take this approach on directories and files exposed via IIS virtual directories. There are also several options related to Web content access as mentioned in the "Securing Virtual Directories Mapped to Local Directories" section earlier in this chapter.

As stated previously, there are several lines of defenseat the IIS level, at the share level, and at the file level. How you choose to secure their shared data depends quite a bit on their installed environment. Creating the IIS 6.0 virtual directories will definitely give you more tools and levels of authentication than ever before. To choose the proper authentication method you need to take the following steps:

1. Open IIS Manager, select the server, and double-click on Web Sites.

2. Right-click on the Web site that is hosting the virtual directory, and then choose Properties.

3. In the Web Site Properties dialog box, choose the Directory Security tab, and then choose Edit in the Authentication and Access Control section.

4. In the Authentication Methods dialog box you are presented with several choices, as shown in Figure 19.2. The options and their function are as follows:

   Figure 19.2. Authentication methods.

   

• Enable Anonymous Access, in which a default "IUSR_MachineName" User Name and Password are prefilled in. This option should only be used for nonsecure publishing of content, in which the user's identity is less important for tracking access.

• In the Authenticated Access section you have the following choices:

  Integrated Windows Authentication This option is checked by default and is the easiest to use in a Windows domain environment. Internet Explorer works well with this authentication method.

  Digest Authentication for Windows Domain Servers This method is best used to selectively grant access to users in select realms. This is much easier to do within strictly a Windows Server 2003 environment. In a mixed environment with both Windows 2000 and 2003 IIS sub-authentication must be installed and configured.

  Basic Authentication (Password Is Sent in Clear Text) This method should only be used when the client's credentials are being sent through SSL, VPN, or on an intranet that is secured. If you need to support browsers other than Internet Explorer they must use this method.

  .NET Passport Authentication If you choose this method, all other authentication methods are unavailable. This method should only be chosen if your Web sites are enabled to work with .NET Passport authentication from the Microsoft servers.