Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments نسخه متنی

Planning File Server Security

Planning for file server security is vital for protecting your organization's sensitive or business-critical files. When planning for file server security, you need to protect not only the data but the physical server as well. In addition, if you plan to implement availability strategies, such as DFS or clustering, you need to take additional steps to secure the resources associated with these features.

Figure 2.18 describes the process for planning file server security.

Figure 2.18: Planning File Server Security

Ensuring the Physical Security of Each File Server

For file servers that must maintain high availability, restrict physical access to only designated individuals. In addition, consider to what extent you need to restrict physical access to network hardware. The details of how you implement physical security depend on your physical facilities and your organization's structure and policies. You should also implement methods to restrict access to backup media and any instruction sheets that you create, such as the instructions that go in the recovery manual for a file server. Allowing unauthorized people to study documentation or configuration manuals means that they can quickly cause harm to the system if they are able to obtain access.

Even if the physical server is in a secure room, the file server might still be accessible through remote administration tools. Therefore, implement methods for restricting access to remote administration of file servers, and ensure that remote administration tools do not weaken your organization's security model. For example, remote administration tools do not always use strong authentication protocols, such as Kerberos V5, to authenticate users across the network. You might be able to implement weaker protocols, such as NTLM, depending on the remote management tool you use and the operating system that is running on the host you are administering. In addition, certain remote administration tools might transmit unencrypted data (plaintext) across the network. This makes your data vulnerable to network sniffers.

For more information about security and remote administration, see the Server Management Guide of the Windows Server 2003 Resource Kit (or see the Server Management Guide on the Web at http://www.microsoft.com/reskit).

Planning Baseline Security

The Windows 2000 Server Baseline Security Checklist provides instructions for configuring a baseline level of security on servers running Windows Server 2003. The checklist contains tasks such as using NTFS, using strong passwords, disabling unnecessary services, disabling unnecessary accounts, and more. For more information about the baseline security checklist, see the Windows 2000 Server Baseline Security Checklist link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Run the Microsoft Baseline Security Analyzer (Mbsa.exe for the graphical user interface version; Mbsacli.exe for the command-line version). For more information about the Microsoft Baseline Security Analyzer, see the MBSA link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

To further enhance security, review the Microsoft Windows Update Web site regularly for patches that fix vulnerabilities and provide security enhancements. For more information about Windows Update, see the Windows Update link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Planning Virus Protection for File Servers

To protect file servers from viruses, plan to take the following precautions:

Use Windows Server 2003-compatible antivirus software, and regularly update virus signature files.

Back up files regularly so that damage is minimized if a virus attack does occur.

With clustered file servers, you must use an antivirus program that is cluster aware. If it is not, failover might not occur correctly. If your organization does not have cluster-aware antivirus software, you can install antivirus software on a nonclustered server and use that server to periodically scan the drives that are mapped to the clustered file server. For more information about running antivirus software on server clusters, see article Q250355, "Antivirus Software May Cause Problems with Cluster Services," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

For FRS-replicated content, you must use antivirus programs that are FRS compatible and that do not change the security descriptor of files. For more information about FRS compatible antivirus programs, see article Q815263, "Antivirus, Backup and Disk Optimization Programs That Are Compatible with the File Replication Service." To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Planning Access to Shared Folders

When you plan access to shared folders, determine the type of permissions to use, who needs access to the folders, and the level of access that users require. You can also disable administrative shares and hide shared folders.

Determining the Type of Permissions to Use

Permissions define the type of access granted to a user or group for a file or folder. Windows Server 2003 offers two types of permissions:

NTFS permissions restrict local and remote access to files and folders on NTFS volumes. When you create a new folder, it inherits permissions from its parent folder. When you create a file in a folder, the file inherits permissions from the parent folder.

Share permissions restrict remote access to shared folders, but share permissions do not restrict access to users who log on to the server locally. Share permissions are available on both FAT and NTFS volumes.

To simplify administering and troubleshooting permissions, use NTFS permissions to control user and group access to file system resources.

Although NTFS is recommended as the primary method for securing folders, you must keep in mind that default share permissions are assigned when you share a folder, and the default share permissions have changed for Windows Server 2003. Windows 2000 and Windows XP grant the Everyone group the Full Control share permission, but Windows Server 2003 grants the Everyone group the Read share permission. This change increases the security of shared folders and helps prevent the spread of viruses.

Because the more restrictive permissions always apply when you use a combination of share and NTFS permissions, you might need to change the default share permissions if you want users to be able to add or change files in the folder. If you do not change the default share permissions, users will have the Read share permission even if you grant users NTFS permissions such as Write or Modify.

If you use a clustered file server, you must create share permissions by using the Cluster Administrator snap-in, not Windows Explorer. In addition, if you plan to use the Share Subdirectories option, you must use NTFS permissions to secure the subdirectories. For more information about these options, see "Planning Cluster Security" later in this chapter.

Determining Who Needs Access to the Folders

To increase security and prevent users from browsing through shared folders that are not relevant to their jobs, assign permissions only to groups that require access to the shared folders.

To reduce administrative overhead when assigning permissions, do the following:

Assign permissions to groups rather than to users.

Place users in global groups or universal groups, nest these groups within domain local groups, and then assign the domain local groups permissions to the folder.

You do not need to deny permissions for specific groups. When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if you allow the Marketing group, and only the Marketing group, permission to access a shared folder, users who are not members of the Marketing group are implicitly denied access. The operating system does not allow users who are not members of the Marketing group to access the folder.

Deny access to folders only in the following scenarios:

You want to exclude a subset of a group (for example, an individual user) that has permissions.

You want to exclude one or more special permissions when you have already granted Full Control to a user or group.

Determining the Level of Access That Users Require

Assign the most restrictive permissions that still allow users to perform required tasks. The following descriptions explain the permissions that are associated with folders on NTFS volumes.

Write Users can copy or paste new files and subfolders in the folder and change folder attributes. However, users cannot open or browse the folder unless you grant the Read permission. Assigning Write permission is useful for folders where users can file confidential reports, such as timesheets, that only the manager or shared folder administrator can read.

Read Users can see the names of files and subfolders in a folder and view folder attributes, ownership, and permissions. Users can open and view files, but they cannot change files or add new files. Assign the Read permission if users need only to read information in a folder and they do not need to delete, create, or change files.

List Folder Contents Users can see the names of files and subfolders in the folder. However, users cannot open files to view their contents.

Read & Execute Users have the same rights as those assigned through the Read permission, as well as the ability to traverse folders. Traverse folders rights allow a user to reach files and folders located in subdirectories, even if the user does not have permission to access portions of the directory path.

Modify Users can delete the folder and perform the actions permitted by the Write and Read & Execute permissions. Because Modify gives users the ability to delete the folder, use Modify permission only for administrators or for the group or department owner of the folder.

Full Control Users can change permissions, take ownership, delete subfolders and files, and perform the actions granted by all other permissions. Because Full Control gives users the ability to delete the folder, use Full Control permission only for administrators or for the group or department owner of the folder.

For more information about permissions and file servers, see "Permissions on a file server" in Help and Support Center for Windows Server 2003.

Determining Whether to Disable Administrative Shares

Windows Server 2003 creates shared folders, known as administrative shares, by default when you start a server or when you stop and then start the Server service. These folders are shared for administrative purposes, and they allow users and applications with the appropriate administrative rights to gain access to the system remotely. For example, some backup software applications use these shares to remotely connect to systems to back up data.

Administrative shares have default share permissions that restrict access to members of only a few security groups. Each share name is appended with a dollar sign ($), which hides the share from users who browse the server. One type of administrative share is the root folder of every volume (C$, D$, and so on).

You can disable these administrative shares temporarily or permanently. For more information about disabling administrative shares and an overview of remote administration, see the Server Management Guide of the Windows Server 2003 Resource Kit (or see the Server Management Guide on the Web at http://www.microsoft.com/reskit).

Determining Whether to Hide Shared Folders

You can hide a shared folder by appending a dollar sign ($) to the shared folder name. Hiding shared folders is useful when you want to make a shared folder available over the network while keeping it hidden from people browsing on the network.

Hiding shared folders does not necessarily make them more secure, because anyone who knows the name of the server and the shared folder can connect to it. Therefore, you must set the necessary NTFS permissions on the shared folder so that access is granted only to the appropriate groups.

Planning Encrypted File Storage

Windows 2000, Windows XP, and Windows Server 2003 support storing files that are encrypted using EFS. However, remote decryption is a potential security risk, because files are decrypted before transmission on the local server, and they are transmitted unencrypted over the network in plaintext. Therefore, before you allow encrypted files to be stored on file servers, decide whether the risk associated with transmitting unencrypted files over the network is acceptable.

You can greatly reduce or eliminate this risk by enabling Internet Protocol security (IPSec) policies, which encrypts data that is transmitted between servers, or by using Web Distributed Authoring and Versioning (WebDAV) folders. WebDAV folders have many advantages compared to shared folders, so you should use them whenever possible for remote storage of encrypted files. WebDAV folders require less administrative effort and provide greater security than shared folders. WebDAV folders can also securely store and deliver files that are encrypted with EFS over the Internet by means of Hypertext Transfer Protocol (HTTP).

Before users can encrypt files that reside on a remote file server, you must designate the file server as trusted for delegation. Doing so allows all users with files on that server to encrypt their files. For more information about enabling encryption on a file server, see "Enable a remote server for file encryption" in Help and Support Center for Windows Server 2003. Note that when encrypting files on a WebDAV server, the server does not need to be trusted for delegation.

If you allow users to store encrypted files on file servers, review the following issues:

Users can encrypt files on remote NTFS volumes only when both the user's computer and the file server are members of the same Windows Server 2003 forest. (This restriction does not apply to WebDAV folders.)

Users must have Write or Modify permissions to encrypt or decrypt a file.

Users cannot encrypt files that are compressed. If users encrypt a compressed file or folder, the file or folder is uncompressed.

For more information about EFS and using WebDAV folders to store encrypted files, see "Encrypting and decrypting data" and "Internet Information Services (IIS) 6.0 overview" in Help and Support Center for Windows Server 2003. For more information about configuring IPSec, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Planning DFS and FRS Security

When planning to secure DFS namespaces and content replicated by FRS, follow these guidelines:

Use NTFS permissions to secure DFS targets. If you are using FRS to replicate DFS link target information, any permission changes you make on one member of the replica set replicate to other members. If you are not using FRS for automatic replication, you must set the permissions on targets and manually propagate any changes that occur.

When setting NTFS permissions, always use the path of the physical folder (\\servername\sharename) instead of navigating through the DFS namespace to set permissions. This is especially important when you have multiple link targets for a given link. Setting permissions on a folder by using its DFS path can cause the folder to inherit permissions from its parent folder in the namespace. In addition, if there are multiple link targets, only one of them gets its permissions updated when you use the DFS path.

If you plan to use share permissions, note that FRS does not replicate share permissions; therefore, you must plan to implement identical share permissions for each shared folder in a replica set. If you do not, users might have inconsistent access to shared folders across the network.

To prevent the spread of viruses in read-only FRS-replicated content, give the appropriate groups the NTFS Read & Execute permission, create a group for administrators who update content, and assign that group the NTFS Modify permission. Do not grant permissions to the Everyone group. For additional recommendations, see "Permissions on a file server" in Help and Support Center for Windows Server 2003.

For FRS-replicated content, you must use antivirus programs that are FRS compatible and that do not change the security descriptor of files. For more information about FRS compatible antivirus programs, see article Q815263, "Antivirus, Backup and Disk Optimization Programs That Are Compatible with the File Replication Service." To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

You must have permissions on the DFS configuration object in Active Directory to add and delete roots to a domain-based DFS namespace.

You can create DFS link targets that point to shared folders containing data that is encrypted by using EFS. However, you cannot use FRS to replicate those files among multiple link targets.

Do not enable the RestrictAnonymous registry value on DFS root servers. Doing so restricts anonymous access and causes DFS referral failures. This registry value is also part of the HiSecWeb security template, which is designed to help secure Internet Information Services (IIS) at the operating system level. For more information about the RestrictAnonymous registry value, see article Q246261, "How to Use the RestrictAnonymous Registry Value in Windows 2000." For more information about the HiSecWeb template, see article Q316347, "IIS 5: HiSecWeb Potential Risks and the IIS Lockdown Tool," in the Microsoft Knowledge Base. To find these articles, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Planning Cluster Security

When planning to secure clustered file servers, follow these guidelines:

After you create a folder by using Windows Explorer, verify that the Cluster service account has the Read permission on the folder so that you can share the folder properly by using Cluster Administrator. (Do not share the folder by using Windows Explorer.)

Use Cluster Administrator to set share permissions. If you change file share permissions using Windows Explorer or My Computer, instead of using Permissions on the Parameters tab in Cluster Administrator, the permissions are lost when the resource is taken offline.

To secure File Share resources on the local server, use Windows Explorer to assign NTFS permissions on the physical folder, because share permissions apply only when users connect to the clustered file server across the network.

Do not assign NTFS permissions to local groups on clustered file servers. These permissions will have no meaning when the clustered disk resource is moved to another server. Therefore, always assign permissions to a domain local group.

By default, access to cluster file shares is disabled to anonymous users. To allow anonymous access to specific file shares, you can either enable Kerberos V5 authentication on the Network Name resource that is associated with the file share or you can change the local security policy setting. For more information about configuring these Kerberos properties, see "Enable Kerberos authentication for virtual servers" in Help and Support Center for Windows Server 2003.

When you create File Share resources by using the Share Subdirectories option, the subdirectories inherit the permissions of the parent. If you are using the subdirectories as user folders, and you want to allow only the user and administrator to access the folder, set NTFS permissions on each subfolder.

To enable EFS on a clustered file server, you must perform some steps to configure the environment correctly. These steps are described in "To create a cluster-managed encrypted file share" in Help and Support Center for Windows Server 2003.

For more information about server cluster security, see "Best practices for securing server clusters" in Help and Support Center for Windows Server 2003.