10 Steps to Secure FrontPage Server Extensions

Understanding FrontPage Server Extensions Security
The FrontPage Server Extensions security model integrates IIS and NTFS security. A FrontPage Web has three basic access permissions: Browse, Author, and Administer. Granting a user Browse access means that the person has access to view the FrontPage Web site. Granting a user Author access means that the person can upload and modify FrontPage Web files. If you grant a user Administer access, the person can change FrontPage Web settings. Note that FrontPage Server Extensions 2002 have two additional authoring roles—Advanced Author and Contributor—and let you create custom roles with selected rights.

The NTFS ACL setting on the FrontPage Web's root directory determines the privileges. If a user has NTFS Read permissions on the root directory, the user can browse the directory. Any user with NTFS Write permissions can author a FrontPage Web. To administer a FrontPage Web, a user must have Modify permissions on the FrontPage Web's root directory. Note that these are the NTFS permissions, not the Web permissions set in the Internet Services Manager (ISM) console.

The authentication process starts when a FrontPage client sends a POST request to either author.dll or admin.dll. Interestingly, these two files are the same file with different names. FrontPage Server Extensions use the wording of the file to partially determine which actions are permitted. After the client sends the POST request, IIS first checks the FrontPage Web's root directory to determine whether the anonymous user account has the proper permissions for the requested action. If not, IIS asks the user to authenticate with a username and password. After the user submits the username and password, the server extensions again check the root directory to determine whether the user has proper permissions. If FrontPage Server Extensions authenticate the user, they then impersonate that user for Web authoring or administration.

One common mistake is to either have the wrong permissions set on the FrontPage Web root directory or have the root directory located on a FAT partition. Versions of FrontPage Server Extensions earlier than FrontPage Server Extensions 2000 use a slightly weaker security model and have no password by default. FrontPage Server Extensions 2000 use a stronger model and don't use blank passwords by default, but you'll sometimes see the permissions changed on the root directory to grant everyone Write permissions. Such permission modification is particularly common on development systems in which security isn't always a high priority. If the IUSR_machinename (where machinename is the server's name) account has Write permission to the root directory, anyone connecting to FrontPage Server Extensions is automatically authenticated and has full access to author or administer the FrontPage Web. Also, because FrontPage is totally dependent on NTFS permissions, FrontPage Server Extensions installed on a FAT partition permit everyone full access to all FrontPage Server Extensions administrative functions because FAT partitions don't let you restrict access permissions on files.

When you use FrontPage Server Extensions, remember to check your configuration by attempting to connect to your FrontPage Web site from another location. If the system doesn't prompt you for a password, you need to double-check your permissions.

10 Steps to Secure FrontPage Server Extensions
When you secure server extensions, consider a strategy that involves multiple layers of protection. Your server configuration and security policy largely determine the number of layers and complexity of your strategy. Below is a list of 10 steps you can take to build a FrontPage Server Extensions security strategy. Implement as many steps as are feasible in your organization.

1. Secure user accounts. Use clearly defined user roles. Carefully assign Web authoring and administration to specific user accounts or groups. Give each account strong passwords, and ensure that multiple users don't share an account. To prevent brute-force attacks, rename the Administrator account something less obvious. Carefully consider the effects of your account-lockout policy.
2. Set proper permissions. Make sure the FrontPage Web's root directory doesn't inherit NTFS permissions from its parent directory, then ensure that the anonymous user account doesn't have NTFS Write permissions on any FrontPage Web content. Remove NTFS Execute permissions from the FrontPage Server Extensions _vti_bin directory's subdirectories, but mark each individual file as Executable. Doing so lets the FrontPage Server Extensions binary files execute but prevents new files placed in those directories from executing. You should also specifically deny the anonymous user account the ability to write to the FrontPage Server Extensions binary directories. In ISM, check the IIS permissions on any directory that begins with _vti or _private to ensure that none have the Read box selected. However, one exception is that the _vti_bin directory (and its subdirectories) should be the only FrontPage Server Extensions directory with IIS Execute permissions.
3. Modify the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\All Ports registry subkey. See Table 1 for the recommended values.
4. Keep your software sufficiently patched. Make sure that you always have the latest version of FrontPage Server Extensions and your OS is always updated with the latest service packs and hotfixes. Although FrontPage Server Extensions 2000 updates are included in Windows 2000 service packs, you need to download FrontPage Server Extensions 2002 hotfixes separately from http://msdn.microsoft.com/library/en-us/dnservext/html/fpse02win.asp.
5. Use Secure Sockets Layer (SSL) for authoring. Whenever possible, require the use of SSL for FrontPage Server Extensions access.
6. Enable logging. In the Web site's Properties dialog box, go to the Server Extensions tab and select the Log authoring actions check box, as Figure 1 shows. (The server properties are accessible by right-clicking the computer name in ISM and selecting Properties.) Regularly review and archive the log files that reside in the _vti_log directory of each FrontPage Web.
7. Set IP restrictions on FrontPage Server Extensions directories. In ISM, right-click each directory that begins with _vti and set IP address restrictions to limit access to these files. If you're using FrontPage Server Extensions 2002, also set IP restrictions on the Microsoft
8. Create a mirror site for FrontPage access if you want access to FrontPage Server Extensions from your internal network but don't want them visible to the world. To create a mirror site, add a new site in ISM. Point the new site to the same physical path as your primary Web site. Remove FrontPage Server Extensions (if already installed) from the primary Web site, and install them on the new site. Use any combination of IP restrictions, obscure ports, SSL, and host headers to secure the new site. Note that the old site will still contain some of the _vti directories. Follow Step 7 to restrict access to those directories.
9. Disable authoring. In some cases, you might want to use FrontPage's WebBots but not permit remote authoring or administration. Open ISM and access the Web site's Properties dialog box. On the Server Extensions tab, clear the Enable authoring check box, as Figure 2 shows. (Note that if you're using FrontPage Server Extensions 2002, you disable authoring through the SharePoint Administration site.) Finally, clear all permissions and set Execute Permissions to None for both the _vti_aut and _vti_adm directories.
10. Move the FrontPage Server Extensions binaries. As I mentioned earlier, placing the binaries on the system partition isn't the safest scenario. Consider moving them to a more secure location. To do so, create a directory on a separate partition and copy the entire contents of the C:\program files\common files\microsoft shared\web serverextensions\40 directory (or C:\program files\common files\microsoft shared\web serverextensions\50 if you're using FrontPage Server Extensions 2002) to the new location. Remember to copy the contents—don't move them. (I recommend keeping a copy of the files in the original location because several FrontPage DLLs have hard-coded references to the default location.)