Team LiB
Previous Section Next Section

Secure File Access

The NTFS file system is superior to many other file systems due to its security concepts. For this reason, it is extremely important that a terminal server’s essential hard drive partitions be formatted with NTFS. However, after installation of the terminal server and its applications, it is possible that not all relevant settings are adjusted for secure operation. This is why an administrator should know as much as possible about file system options if the environment requires advanced security.

An important precondition for securing the file system (and the registry database) is the selection of the Full Security permission compatibility setting in the Terminal Services Configuration Server Settings. Only if this option is selected do the terminal server users have the same limited permissions as the Users group members. This precludes access to certain registry areas and sensitive system files, even after a simple standard installation without any additional security configuration.

Note 

Encrypting a terminal server’s file system using Encrypted File System is possible, but not common practice. This is because user data is usually saved in special file servers rather than on the terminal server. Furthermore, the existing processors require significant amounts of additional system resources for ongoing encryption and deciphering of local data.

File and Folder Properties

When using the NTFS file system, a file’s properties include size, owner, and access permissions. The same is true for directories, where the basic permission is determined by a number of attributes.

The following file permissions exist: Full Control, Modify, Read & Execute, Read, and Write. The individual permissions each include one logical group of restricting permissions. The following table lists file permissions and the corresponding restrictions.

Table 8.1: Permission Groups and Corresponding Restricting Permissions

Restricting Permissions

Full Control

Modify

Read & Execute

Read

Write

Traverse Folder/Execute File

Yes

Yes

Yes

No

No

List Folder/Read Data

Yes

Yes

Yes

Yes

No

Read Attributes

Yes

Yes

Yes

Yes

No

Read Extended Attributes

Yes

Yes

Yes

Yes

No

Create Files/Write Data

Yes

Yes

No

No

Yes

Create Folders/Append Data

Yes

Yes

No

No

Yes

Write Attributes

Yes

Yes

No

No

Yes

Write Extended Attributes

Yes

Yes

No

No

Yes

Delete Subfolders and Files

Yes

No

No

No

No

Delete Folders

Yes

Yes

No

No

No

Read Permissions

Yes

Yes

Yes

Yes

Yes

Change Permissions

Yes

No

No

No

No

Take Ownership

Yes

No

No

No

No

Note 

Groups and users with full access can delete all files in a folder, regardless of the individual file permissions.

The directories have the following permission options: Full Access, Modify, Read & Execute, List Folder Contents, Read, and Write. The individual permissions each include one logical group of restricted permissions. The only difference between the directories and files is the additional List Folder Contents group.

Note 

When analyzing the options List Folder Contents and Read and Execute in detail, it seems that they have the same restricted permissions. However, these permissions are handled differently. The List Folder Contents permissions apply only to folders, not to files. This option should occur only when displaying folder permissions. On the other hand, with Read and Execute, the permissions apply to both files and folders. This option is available when displaying file or folder permissions.

Click To expand
Figure 8-19: Permissions at the file level. The grayed attributes point to the fact that they were inherited by a parent object.

It is, of course, possible to assign different combinations of basic permission attributes to directories and files. However, this is common practice for system files only and requires in-depth understanding of the NTFS file system security concept.

The Change Permissions and Take Ownership attributes are of particular importance for a file system’s security administration. Only users owning the attribute for changing directory or file permissions can actively modify the security settings. Only users owning the attribute for taking the ownership can assume ownership of a directory or file. The owner of a directory or file can always assign himself or herself the attribute for taking ownership and therefore change all other attributes, too. An administrator always has the right to become the owner of a directory or file. An administrator who owns a file or directory can assign himself or herself the attribute for changing permissions and therefore actively modify all other attributes as well. Administrators or users who own the attribute for taking ownership of a file or directory can assume ownership of this object, but they cannot actively return ownership to its original owner.

Note 

On Windows Server 2003, a user or administrator can only assume ownership of a directory or file actively. No one can transfer ownership to another person using standard methods.

To improve terminal server security, it is recommended that critical system files be protected as thoroughly as possible. This applies to the following file system areas in particular:

  • Start files in the system drive: Boot.ini, Ntdetect.com, or Ntloader

  • The different operating system directories (\WINDOWS)

  • User profile directories (\Documents and Settings)

  • Application-specific directories

Because of the improved default settings of Windows Server 2003 in comparison to its predecessors, the security of start files, system directories, and user data is ensured. However, installing applications that might change standard security settings can leave the security system vulnerable.

Important 

Whenever a new application is installed on a terminal server, it is recommended that all possible impacts on system security be checked. The default security settings of the new application can allow previously unauthorized users free access to the installation directory! Furthermore, many applications allow other programs to be launched indirectly, which might enable access to system-relevant settings.

Increasing system security after required applications are installed usually involves restricting permissions for standard groups, user groups, or even individual users within one administrator session. Subsequently, a test user logs on and the runtime system is monitored—for example, using file system access monitoring tools.

Windows Explorer or the Cacls.exe command-line program are recommended tools for modifying the security attributes of a directory or a file.

File Monitor

File Monitor is another tool developed by Mark Russinovich and Bryce Cogswell. It can be downloaded for free from the SysInternals Web site at http://www.sysinternals.com. File Monitor is a combination of graphical application and special device driver. It can record and display all file activities occurring on a Windows system. With its integrated filter and search functions, File Monitor is a powerful tool for examining a terminal server’s file activities. It is particularly practical for tracing how applications use files and DLLs. This information can be used for delimiting and solving system- and application-related problems.

File Monitor’s graphical user interface indicates each file access in an individual line. The line is divided into fields that include a sequence number, time, process name, access type, the file (including its path), access result, and additional information. The Result field is the most important means of analyzing errors that occur during file access. The Other field shows the relative position of read and write activity in the file. All file accesses logged can be easily viewed using the scroll bar.

Click To expand
Figure 8-20: File Monitor by SysInternals on a terminal server.

The File Monitor filter functions can be set to display the logs for selected processes or files only. The DASD (direct access storage device) path name is especially interesting because it indicates direct hard drive accesses that bypassed the file system.

Analyzing or securing a terminal server using the File Monitor is relatively simple. An administrator logs on, configures an application for maximum security for the file system, and starts File Monitor (if necessary, with a filter preset to reduce the resulting amount of data).

If the administrator now logs on with a second session, using a standard user account without administrator privileges, the administrator can verify if the application starts up as desired. Normally, this should not be possible with very strict security settings, and error messages will be displayed on the desktop.

Using the first session, the administrator now takes File Monitor to see which access errors were logged. The administrator can then view all files with access permissions that need to be changed. Entire files might be missing (such as DLLs or .ini files), which at that point becomes clearly evident.

Note 

Only administrators can launch File Monitor because other users do not have the necessary permissions. If you want to examine accesses within user context, you need to start an RDP user session on a desktop that belongs to an administrator. By running File Monitor from this administrator session you will see system-wide activity including that of unprivileged sessions.

Securing Network Shares

Under Windows Server 2003, all drives are automatically shared through their logical name, that is, driveletter$, for example, C$ or D$. However, access permissions for these administrative shares are very restricted. Only if a user is a member of the Administrators or Backup Operators group is it possible for the user to access the administrative shares via the network. If the NTFS permissions for all objects of the administrative share are set accordingly, administrative access to their directories and files is unrestricted.

Important 

Windows Server 2003 no longer supports access to an administrative share through an administrator account with a blank password. This significantly improves system security because it eliminates accidental loopholes due to incorrectly configured administrator accounts.

The following steps further improve the security of administrative shares:

  • Strong administrator password Assigning a strong password to the administrator account that is hard to guess. Windows Server 2003 security settings also allow settings that require increased password complexity (special characters, capitals, numbers) or minimum password length.

If the administrator password must remain weak, sharing can be blocked with these steps:

  • Disable server service If this service is disabled, directories can no longer be shared. This means that users can no longer connect to a drive or directory on this computer. Users working with this computer can still access shared directories on other computers. If server service is to be disabled permanently, the start type must be set to Manual or Disabled. Otherwise, the service relaunches automatically when the computer reboots.

  • Uninstall file and printer sharing for Microsoft Networks This option is located under the network and dial-up connection properties. Use the Uninstall button to remove this component (but not the check box File and Printer Sharing for Microsoft Networks).

    Note 

    To temporarily block a drive from being shared, the context menu of the relevant drive must be opened. Under the Sharing and Security... menu item you will find the Do not share this folder option. However, you need to keep in mind that under Windows Server 2003, the drive will automatically be shared again after a reboot.


Team LiB
Previous Section Next Section