This chapter of the Server Extensions Resource Kit describes general Web hosting security issues and how FrontPage protects Web server security on UNIX-based Web servers and on the Internet Information Server (IIS) Web server for Windows NT. This chapter has three sections:
Regardless of what software you are running, the two major security issues when you host Web sites from your computer are:
Hosting Web sites, even on an intranet, opens your host computer to a wider community of users. Authentication is the process of allowing users access to the Web service based on usernames and passwords or based on IP addresses. Restricting users by IP address is less secure, because clever users can "spoof" an IP address and gain access to the host computer.
Programs can run on your computer based on the content of a Web site for many reasons. For example:
FrontPage addresses these security issues by using the built-in security mechanisms of the host computer. Using the FrontPage Server Extensions requires no changes to the host computer's security method. You do not have to recompile any Web-server programs and there are no custom filters or other security modifications.
For a full discussion of FrontPage security on UNIX-based Web servers, see FrontPage Security on UNIX-based Systems.
For a full discussion of FrontPage security on IIS-based Web servers, see FrontPage Security on IIS Systems.
The FrontPage Server Extensions on UNIX Web Servers
FrontPage Server Extensions File Structure
FrontPage Access File Settings
Setting Permissions on Web Content
Setting the Server Extensions to SUID/SGID
Modifying the Web Server’s Configuration File
The Server Extensions Configuration File
In the UNIX security model, the Web server maintains a list of accounts, with usernames and passwords, and a list of groups of users with various levels of permissions to use the services of the Web server. The accounts and groups maintained by the Web server are entirely separate from the list of users and groups with access to the host computer’s file system. To fetch files and run scripts and programs on the host computer, the Web server runs as a UNIX account, typically "www."
Access to a Web server’s content, CGI scripts, and configuration files is controlled by entries in an access file. On Apache and NCSA Web servers the file is .htaccess, on Netscape servers it is .nsconfig, and on CERN it is .www_acl. These files associate users, groups, and IP addresses with various levels of permissions: GET (read), POST (execute), PUT (write), and DELETE. For example, a FrontPage author would have permission to use HTTP POST commands (to save new content), and a user with browse permissions would be permitted to use HTTP GET commands (to read content).
Multiple access files can be stored on a Web server. Each access file will provide security for the directory containing it and for any of its subdirectories that do not contain their own access files. By creating access files throughout the web server’s content, different sets of users with varying levels of permissions, can be given access to different areas of the server.
Because the Web server is running under a UNIX account (such as "www") any process it runs and any files that it accesses must be available under the permissions of that UNIX account. Having all content available under a single UNIX account can cause a security problem because one user’s CGI script could read files in another user’s content area on the server. With write access, as with the FrontPage client, if a user’s CGI script has sufficient permissions to write to a file in the user’s own content area, the CGI script could write or overwrite files in other user’s content areas in a multi-hosted environment.
To address this security issue (which is common to all CGI scripts including the FrontPage Server Extensions), the SUID (Set User ID) bit of the CGI script’s execute-permissions can be set, forcing the Web server to switch to the UNIX user account of the owner of the CGI script when the script is run. Because the script owner's account is not likely to have permission to write to other user’s content areas, it protects against unauthorized writing to files.
In UNIX authentication, when a user browses to a page on a Web server, the server receives an HTTP GET request with a username and password. The Web server checks the user’s permissions in the appropriate access file. If the GET cannot be executed under the user’s authentication, the Web server returns a 401 error, indicating that the user is unauthorized. The client then prompts for a new name and password and resubmits the request. Once the user is authenticated, the Web server attempts to fetch the content from the file system. If UNIX does not allow the Web server access to the file for some reason, it will return a fatal error to the Web server. At this point, the user is not prompted for a new username.
When a client or Web browser sends an HTTP POST request, as is the case when a FrontPage author posts to the FrontPage authoring program author.exe, the Web server again checks the user’s permissions in the appropriate access file. If the POST cannot be executed under the user’s authentication, the Web server returns a 401 error. The client then prompts for a new name and password and resubmits the request. Once the user is authenticated, the Web server tries to run author.exe. If the SUID bit of author.exe is set, the process runs as the owner of the file. Otherwise, author.exe runs under the Web server’s UNIX account.
UNIX Web servers usually communicate with client programs using Basic Authentication. When using Basic Authentication, the Web browser (or the FrontPage Explorer) prompts the user for a username and password. The username and password are then transmitted across HTTP, lightly encoded using a technique known as UUencoding. (Some Web servers use a technique known as MD5, but this method is not supported by FrontPage.)
One security risk of Basic Authentication is that usernames and passwords are transmitted across the network in an easily decoded format. However, Basic Authentication is the only authentication technique that works through a firewall via a proxy server.
In FrontPage, there are three kinds of users defined for every FrontPage web: administrators, authors, and browsers (end-users). All permissions are cumulative; all authors also have browsing permission, and all administrators have authoring and browsing permissions.
Each FrontPage web (including each sub-web) contains copies of three executable scripts. These scripts are created in folders below the top-level folder of a FrontPage web: _vti_bin/_vti_adm/admin.exe for administrative tasks, _vti_bin/_vti_aut/author.exe for authoring FrontPage webs, and _vti_bin/shtml.exe for browse-time FrontPage components such as form handlers. FrontPage performs all authoring and administrative tasks by sending HTTP POST requests to these scripts.
In FrontPage, the list of administrators, authors and browsers is defined on a per-web basis. All FrontPage sub-webs either inherit the permissions (list of administrators, authors and browsers) of the FrontPage root web or use their own, unique permissions. (For a description of the root web and sub-webs, see FrontPage Webs.) As with other CGI programs, the FrontPage Server Extensions must be stored in directories that are marked "Executable," indicating that the directories contain executable files. The document root is the top-level directory in a FrontPage web. The FrontPage Server Extensions are stored in three directories in each document root:
/document root
/_vti_bin
shtml.exe
/_vti_adm
admin.exe
/_vti_aut
author.exe
The server’s configuration file needs to be modified to mark the directories _vti_bin, _vti_adm, and _vti_aut as executable directories. A Web server administrator initiates and controls this operation using the FrontPage Server Administrator.
To reduce the total amount of disk space needed to support FrontPage webs, the FrontPage scripts stored in the various _vti_* directories are stub executables. They each invoke a full executable file installed in the directory /usr/local/frontpage/version3.0/exes.
FrontPage creates a directory _vti_pvt for the root web and for each FrontPage sub-web. For each FrontPage web with unique permissions, the _vti_pvt directory contains two files for the FrontPage web that the access file points to:
On Netscape servers, there are no service.grp files. The Netscape password files are:
An access file in the _vti_bin directory controls access to the run-time FrontPage program shtml.exe. If all users have browse permission, this is set in the access file. Otherwise, the access file points to the list of users and groups with browse access. A separate access file in the _vti_adm directory sets POST permissions for the administrative program admin.exe. A third access file in the _vti_aut directory sets the POST permissions on the authoring program author.exe.
When a Web administrator uses the FrontPage Explorer’s Permissions command to give a user browse access to a FrontPage web, the user is given an account on the Web server by adding a username and password to the single service.pwd file pointed to from _vti_bin directory’s access file. (On Netscape servers the file is users.pwd.) Also when an IP address restriction is set on users of the FrontPage web, this restriction is added to the _vti_bin access file.
When a Web administrator gives a user authoring access to a FrontPage web, the user is given an account on the Web server. This is done by adding the user’s name and password to the service.pwd file and to the authors group in the service.grp file pointed to from the access files stored in the _vti_bin and _vti_aut directories. This enables the user to do HTTP POST requests to author.exe and to use the run-time program shtml.exe. (On Netscape servers the process is similar.)
When a Web administrator gives a user administrative access to a FrontPage web, the user is given an account on the web server. This is done by adding the user’s name and password to the service.pwd file and to the administrators group in the service.grp file pointed to from the access files stored in the _vti_bin , _vti_aut, and _vti_adm directories. This enables the user to do HTTP POSTs to admin.exe, author.exe, and shtml.exe. (On Netscape servers the process is similar.)
The set of access files for a FrontPage web is illustrated in the following two diagrams. The first diagram shows the access files and UNIX file permissions for the content of a FrontPage web: the directories, files, and executable files that an author creates. The second diagram shows the access files and UNIX file permissions for the FrontPage _vti directories:
For a list of the entire contents of a FrontPage installation, see FrontPage UNIX Files.
Setting secure access-modes for files and directories in a customer’s content directory is a key to maintaining your Web-server security. All files and directories should be owned by the customer’s user identifier/group identifier. Suggested UNIX permission settings are shown in the following table:
| Single UNIX account per customer | files: | rw- r-- r-- |
| directories: | rwx r-x r-x | |
| umask: | --- -w- -w- | |
| Multiple UNIX accounts per customer | files: | rw- rw- r-- |
| directories: | rwx rwx r-x | |
| umask: | --- --- -w- |
The permissions for customers with multiple UNIX accounts per customer also apply to an organization that has several UNIX accounts that are part of the same UNIX group. Shared write-access allows any members of the group to write to all shared Web documents.
Using the FrontPage Server Administrator (fpsrvadm.exe), you can change the execute-permissions of the Server Extensions executables to SUID/SGID. This forces the Server Extensions to execute with the file system permissions of the owner of shtml.exe, author.exe, and admin.exe. Combined with suitable permissions for each customer’s content area, the FrontPage Server Extensions (and any other CGI scripts) for one customer are prevented from writing to the content areas of other customers.
The FrontPage Server Extensions do not require root access at any time. However, the FrontPage Server Extensions installation script should be run as root, because it sets EXECUTE privileges of the extensions to SUID. Because it is written in Perl, the Web administrator can review the script before running it on the Web server.
On some web servers, such as NCSA, CERN and Apache, the FrontPage Server Extensions need to modify the Web server's configuration file to mark directories containing the Server Extensions as "executable." Since the FrontPage Server Extensions run as "www" and the Web-server configuration file is owned and modifiable only by "root," the FrontPage Server Administrator must be manually run as "root" on the host computer to do this. This prevents administrators from remotely creating FrontPage webs because the Web server's configuration file would need to be owned by "www," which would potentially compromise the host system's security.
The FrontPage Server Extensions also read the Web server’s configuration file to learn what virtual servers there are, where the content roots are, and what directories are marked executable.
Some security settings of the FrontPage Server Extensions can be controlled in the Server Extensions configuration file. The configuration file is in /usr/local/frontpage and is named wexxxx.cnf or, on multi-hosted servers, host:xxxx.cnf, where xxxx is the port number of your server and "host" is its name or IP address. The global configuration file /usr/local/frontpage/version 3.0/frontpage.cnf contains the default settings which apply to all FrontPage webs.
See List of UNIX Configuration File Settings for a complete listing of the parameters that you can set in this file.
IIS Authentication
The Anonymous Account
Basic Authentication
Windows NT Challenge/Response
Distributed Password Authentication
Windows NT Challenge/Response and Network vs. Local Logon Rights
The FrontPage Server Extensions on IIS
The FrontPage DLLs
FrontPage Access Control List Settings
FrontPage and System DLLs
Virtual FrontPage Directories
Restricting Windows NT Account Lists
Making a Directory Unreadable
Windows NT security helps you protect your computer and its resources by requiring assigned user accounts for all operations. You can control access to all computer resources, including Web content, by limiting the user rights of these accounts. Windows NT maintains account lists of local users and groups and of users and groups in the domain.
Every operation on a Windows NT computer identifies who is doing the operation. The username and password that you use to log on to Windows NT identifies who you are and defines what you are authorized to do on that computer.
What a user is authorized to do on a computer is configured in User Manager by setting User Rights in the Policies menu. User rights authorize a user to perform certain actions on the system, including the right to "Log on locally," which is required for users to use Internet Information Server services under Basic Authentication.
NTFS is the recommended file system choice for Windows NT systems that host Web sites. Windows NTFS allows the association of an access-control list (ACL) with any file or directory. An ACL contains users and groups with sets of permissions that control whether or not a user or group can read, write, execute, or delete that file or directory.
Windows NT also supports the File Allocation Table (FAT) file system. Because there are no file permissions maintained there, storing web content in a FAT partition completely bypasses FrontPage and IIS access control. You are warned about this when you attempt to install the FrontPage Server Extensions on a FAT partition. To apply security to a Web site, you must either convert the partition from FAT to NTFS or move the content to an NTFS partition. With either solution you will have to uninstall and reinstall the FrontPage Server Extensions.
For more information on Windows NT Security, see Windows NT Server for IS Professionals.
Under IIS design, each HTTP request to IIS from a Web browser (or from the FrontPage client) runs under a user account on the Windows NT computer hosting IIS. The operations that are performed during the execution of that HTTP request are limited by the capabilities granted to that user account on the Windows NT Server.
When IIS receives an HTTP request from a Web browser or from the FrontPage client, it does the following:
The request is first attempted as the anonymous account, IUSR_<hostname>. If that execution fails to have sufficient access to complete the request, or if IIS does not have anonymous browsing enabled, then IIS returns error 401 (access denied). At this point, user authentication is performed to allow the remote user to identify themselves using the techniques of Basic Authentication or Windows NT Challenge/Response. If the Web browser or FrontPage client is using Windows NT Challenge/Response, the user may not see a prompt, because the FrontPage client or the Web browser simply supplies the username and password of the logged in user from the client computer.
You can restrict IIS access to only authenticated clients (clients that supply a valid Windows NT username and password), or you can allow anonymous access using the anonymous account. When you use authenticated clients, no access is permitted unless a valid username and password are supplied. Password authentication is useful if you want only authorized individuals to access your Web site or specific portions controlled by NTFS. You can have both anonymous logon access and authenticated access enabled at the same time.
Each Internet service, such as World Wide Web and FTP, maintains a Windows NT username and password that is used to process anonymous requests. The anonymous account for Web services, IUSR_<hostname>, is automatically created by Internet Information Server during its setup. By default, all Web client requests use this account, and clients are given access to Web content using the IUSR_<hostname> account.
When an anonymous account request is received, the WWW service "impersonates" the user configured as the anonymous logon user. The request succeeds if the anonymous logon user has permission to access the requested resource, as determined by the resource’s Access Control List (ACL). If the anonymous logon user does not have permission, the request fails. The WWW service responds to a failed anonymous request by requiring that the user provides a valid Windows NT username and password.
Basic Authentication is supported by the majority of Web servers on the Internet. When using Basic Authentication, the Web browser (or the FrontPage client) prompts the user for a username and password. The username and password are then transmitted across HTTP, lightly encoded using a technique known as UUencoding. Using this username and password IIS then authenticates the user as the corresponding Windows NT user.
One security risk of Basic Authentication is that usernames and passwords are transmitted across the network in an easily decoded format. However, if your Web site must support authoring by FrontPage 1.1 clients (which do not support NTLM), or if you want to ensure that your Web site is accessible from all browser types, then you must keep Basic Authentication enabled. Furthermore, Basic Authentication is the only authentication technique that works through a firewall via a proxy server. If you are running your Web server over the Internet via a proxy server (as opposed to running it within an intranet) you must use Basic Authentication.
Windows NT Challenge/Response (also called NTLM) is a more secure authentication method than Basic Authentication. In Windows NT Challenge/Response, the Web browser or FrontPage client first attempts to use the Windows NT credentials used to log on to the computer on which the browser or FrontPage client is running. If those credentials are rejected, Windows NT Challenge/Response will prompt the user for a name and password.
The username and password are securely encrypted in a multiple transaction interaction between the client and Web server. This interaction is secure against network snoopers that attempt to break into systems by monitoring network traffic between a client and a server.
There are some limitations of Windows NT Challenge/Response:
Because Windows NT Challenge/Response Authentication cannot be performed through a firewall, it is most useful on intranets, where communication occurs inside an organization’s firewall.
You can have both Basic and Windows NT Challenge/Response authentication enabled. If the Web browser supports Windows NT Challenge/Response, it uses that authentication method. Otherwise, it uses Basic authentication. Windows NT Challenge/Response authentication is currently supported only by Microsoft Internet Explorer 2.0 or later.
The FrontPage Server Extensions supports Microsoft Commercial Internet System Membership service, which uses the Microsoft Distributed Password Authentication (DPA) protocol. DPA is a challenge and response authentication protocol that uses passwords and a trusted third-party authentication server. In DPA, a generic user name in the domain is mapped to a set of users maintained in a database. This lets Internet service providers extend the number of users an NT domain can accommodate. Generic usernames, such as "FrontPage_Authors," are available in the FrontPage Permissions dialog box in the same way as other usernames and groups.
FrontPage client machines that use DPA must have Microsoft Internet Explorer 3.0 (or higher) or Netscape Navigator 2.0 or 3.0. If the client machine is running Microsoft Internet Explorer 3.0, the user must install the Microsoft Internet Explorer 3.0x DPA update. If the client machine is running Netscape Navigator 2.0 or 3.0, the user must install the Microsoft Authentication Proxy for Netscape Navigator update.
IIS 2.0 implements Windows NT Challenge/Response and Basic Authentication slightly differently than later IIS versions. When a user is authenticated using Windows NT Challenge/Response, the user is logged on to the Web server computer as a network logon. When Basic Authentication is used, the user is logged on with local logon rights by default, which is similar to logging on for an interactive session at the computer’s console.
In most situations, there are no differences between a network logon and a local logon. The one situation for which this makes a difference is delegation applications. A delegation application is one in which part of the Web server’s work is delegated to a secondary server process running on a different computer. For example, a Web server that accesses a database server running on a different host computer is a delegation application. If the user has logged on locally, Windows NT security permits those user credentials to be honored by the secondary server. If the user has logged on via the network, those credentials are not honored. Consequently, when using Windows NT Challenge/Response, the database server and Web server must be running on the same host computer.
There are two potential problems caused by Basic Authentication’s use of local logon that administrators should be aware of. First, Basic Authentication will not succeed if the user account does not have local logon rights. Even if the FrontPage, IIS, and Windows NT configuration appears to be correct, the lack of local logon rights granted to the user in the Windows NT User Manager will prevent Basic Authentication from authenticating the user. Second, with local logon, if a user can obtain physical access to the host running IIS, the user will be permitted to start an interactive session at the console.
In FrontPage, there are three kinds of users defined for every FrontPage web: administrators, authors and browsers (end-users). All permissions are cumulative; all authors also have browsing permission, and all administrators also have authoring and browsing permissions.
In FrontPage, the list of administrators, authors and browsers is defined on a per-web basis. All content in a FrontPage web will be accessible to the same set of users and groups. It is not possible to control permissions on a per-file or per-directory basis with FrontPage. All FrontPage sub-webs either inherit the permissions (list of administrators, authors and browsers) of the FrontPage root web or use their own, unique permissions.
Each FrontPage web (including each sub-web) contains copies of three ISAPI DLLs that make up the FrontPage Sever Extensions. These DLLs are created in directories below the top-level directory of a FrontPage web:
FrontPage performs all authoring and administrative tasks by sending HTTP POST requests to these DLLs. The FrontPage Server Extensions are stored in separate directories in the customer’s document root:
/document root
/_vti_bin
shtml.dll
/_vti_adm
admin.dll
/_vti_aut
author.dll
FrontPage implements web security on IIS by changing the access-control lists (ACLs) for all files and directories in each FrontPage web. FrontPage controls who can administer a FrontPage web by setting the ACL on admin.dll, the administrative DLL. Similarly, FrontPage sets authoring permissions by setting the ACLs on author.dll. The default ACL sets browsing permission on Web content and lets all users execute the run-time DLL, shtml.dll.
You set the ACLs for a FrontPage web using the FrontPage Explorer’s Permissions command, on the Tools menu. To add new users and groups, this command makes the Windows NT computer account list available. In FrontPage 98, you can set up a restricted list of users and groups that does not expose the entire contents of the Windows NT computer and domain account lists. This lets you protect the confidentiality of your user community. For details, see Restricting Windows NT Account Lists.
FrontPage sub-webs can have unique permissions by maintaining separate access-control lists on their own copies of the admin.dll, author.dll and shtml.dll DLLs. Alternatively, a FrontPage sub-web can inherit the permissions of the root web by keeping the access-control lists on its admin.dll, author.dll and shtml.dll the same as the root web’s lists.
The set of ACLS for a FrontPage web is illustrated in the following two diagrams. The first diagram shows the ACLs for the content of a FrontPage web: the directories, files, and executable files that an author creates. The second diagram shows the ACLs for the FrontPage _vti directories.
Note in these diagrams that two sets of permissions are given. The first set applies to the directory, and the second set applies to the files in the directory. For example, the permissions (rx) (r) specify read and execute-permissions on the directory but only read permissions on the files in the directory.
For the complete set of ACLs set on FrontPage files, along with a list of the entire contents of a FrontPage installation, see FrontPage Windows NT File Permissions.
On Windows NT, a DLL that is called from another DLL must run under the same user account as the calling DLL. Therefore, all system DLL code that is run as a consequence of an IIS request must run on the impersonated user’s permissions. The FrontPage DLLs admin.dll, author.dll, and shtml.dll contain calls to Windows NT system DLLs. To ensure that the system DLLs will have the correct level of permissions to run under any administrator, author, or end-user’s account, FrontPage adds the Interactive and NETWORK accounts to the ACLs of any system DLLs that are used as a result of a FrontPage DLL call. These added users are given "read" and "execute" permissions on the system DLLs. Note that this is necessary when installing any generic CGI scripts that use any Windows NT system services on a Web server. Because FrontPage makes calls to Windows NT system DLLs:
Virtual directories are IIS 2.0 and IIS 3.0 constructs that map the URL space of the Web site onto the file system of the local computer. They control read and execute access to specified directories within the file system and allow seemingly related URLs to refer to noncontiguous content areas in the file system.
FrontPage automatically manages the use of virtual directories for executable and unreadable directories. When installed, FrontPage sets up virtual directories in each FrontPage web to mark the directories that contain the FrontPage Server Extension DLLs as executable and to mark hidden directories as unreadable. FrontPage creates the following virtual directories for each sub-web:
_vti_bin
_vti_bin\_vti_aut
_vti_bin\_vti_adm
_vti_pvt
_vti_cnf
_vti_txt
The root FrontPage web has a seventh virtual directory:
In the FrontPage Explorer, authors can mark directories executable to allow the directories to store executable objects such as Active Server Pages (ASP), Database Connector files (IDC), CGI Scripts, ISAPI Extensions, and Perl scripts. Each directory that is marked executable causes FrontPage to create a virtual directory.
In FrontPage 98, you can set up a single user and group list for each virtual root FrontPage web. This lets you protect the confidentially of your user community by not displaying the full Windows NT account list. To globally enable Windows NT computer account list restrictions, add the following line to your frontpg.ini file, located in the \Winnt directory:
[FrontPage 3.0] RestrictIISUsersAndGroups = 1
Setting the value to 1 enables restrictions. This same line can also be added for a specific virtual root FrontPage web, for example:
[Port 157.55.49.66:80] RestrictIISUsersAndGroups = 1
A setting of RestrictIISUsersAndGroups=0 can be used to explicitly disable restrictions, allowing you to set restrictions by default to enabled for all FrontPage Webs except for those where restrictions are explicitly overridden. The default for the global setting is that restrictions are off if the RestrictIISUsersAndGroups key is missing. The default for individual FrontPage webs is to inherit the global setting.
If users and groups restrictions are enabled for a given FrontPage web, the Server Extensions look for a Windows NT group named in the following convention:
FP_[ServiceName][_Subweb]
On a multihosted IIS2.0/3.0 machine [ServiceName] is the service's IP address and port number combination and [_Subweb] is the name of the sub-web. On a single-hosted machine, the ServiceName portion is simply the port number.
On IIS 4.0, [ServiceName] can be of the form /LM/W3SVC/<N>, where <N> is an instance number. This is the recommended method. On IIS 4.0, [ServiceName] can also be of the form <virtual_server>:<port_number>. If you use this form, you must use specify the virtual server's name; you cannot use the virtual server's IP address on IIS 4.0.
To specify a root web's restriction group, omit the _Subweb portion.
Some examples are:
FP_157.55.49.66:80_MySubweb
FP_80_MySubweb
FP_80
FP_/LM/W3SVC/1_MySubweb
If restrictions are enabled on a sub-web but no local group is defined, the FrontPage Server Extensions look for the group of the root web and use it if found. If no appropriately named groups are found then no restriction is placed on permissions visibility setting or contents.
A standard way of saving form results in FrontPage is to use the default form handler (also called the WebBot Save Results component) to write to a results file in a directory in a FrontPage web. In FrontPage 1.1 and FrontPage 97, writing form results to a directory made the contents of the directory readable to any user who discovered the URL of the results file.
In FrontPage 98, authors can assign a virtual directory mapping for a form results directory that has both the execute and the read bits turned off. This prevents any end-user from reading the contents of the directory, but it requires the FrontPage web author to fetch the contents of the directory using the FrontPage Explorer.
To make a directory unreadable, select it in the FrontPage Explorer’s Folders view and select Properties from the Edit menu. In the Folder Properties dialog box, deselect the two settings: Allow scripts or programs to be run and Allow files to be browsed.
Note that if you make the /_private directory unreadable, some FrontPage Wizards will not work properly.
