Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Practical Deployment Issues

Setting object permissions using the object picker is not the only way to secure objects. A sound understanding of object permissions and inheritance is critical; however, there are a number of processes that also affect data security and tools that can be used to further secure data. Object permissions cannot always be locked down to the requirements defined by data owners, and the operating system cannot be hardened as well as could be. These processes and tools are issues having to do with the following:

Legacy applications

Data streams

Recovery and fault tolerance

Native tools for permission application

Clustering

Distributed File System (DFS)

Data security options in Group Policy and security templates

Event log access security

Legacy Application Permission Issues

Each new Windows version has made improvements in security and stability. However, these changes have often meant application compatibility issues. Applications designed to run on less secure versions of Windows may not be able to run on newer versions without significantly weakening security settings. Unfortunately, these issues are most frequently resolved by giving users administrative rights on their own desktop systems. This is not a good solution to the problem, though. It does work, however, because many of the compatibility issues have to do with file system and registry permissions. Older versions of Windows had little or no restrictions on file access. Newer versions of the operating system often give users little or no permissions to sensitive folders, files, and registry keys. The Administrators group, however, is given full access. By giving users Administrative group membership, the applications then work as expected. An alternative approach would be to determine exactly which files and folders the applications require access to and to provide users access to those files. This would allow the applications to run but would not provide users with elevated privileges on their systems. Many attacks attempted by viruses and worms will not work if the user running the infected file does not have administrative privileges. If applications disregard the permission requirements of newer operating system versions, and administrators cannot or do not want to create workarounds and thus provide users with administrative privileges, this weakens security.

To determine exact permission requirements, other options are as follows:

Replacing older applications with applications that are built to conform to the new operating system.

Using the pre-Windows 2000 compatible access group. This group can be used to provide backward compatibility access to domain resources for computers running Windows NT 4.0 or earlier that must be part of a Windows Server 2003 domain. For example, a Windows NT 4.0-based RRAS server that is a member of a Windows Server 2003-based domain must be able to access the remote access credentials of domain accounts. Adding the Everyone group to the pre-Windows compatible access group permits the RAS caller to be authenticated by the Windows NT 4.0 server.

Determining the required permissions and replacing default permissions with these permissions.

Alternative Data Streams

Data streams are locations assigned to files created in the NTFS file system. NTFS allows multiple data streams for each file. The first data stream is visible in Windows Explorer and is accessed by using the filename. Additional file streams can be created under the same filename but are not visible in Explorer. These alternative data streams (ADSs) are used for many things, including accommodation of dual-forked Macintosh files (which can be stored on Windows NT-based systems when Services for Macintosh (SFM) is installed), the Summary information property tab of a text file as displayed in Figure 5-29, and the web sharing property page of IIS folders. More information can be found in the Microsoft document "Multiple Data Streams" at http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_xurt.asp.

Although ADSs perform useful functions, they are hard to detect without specialized non-native software and may be difficult to remove. Furthermore, an ADSs could pack a malicious payload. A proof-of-concept virus, the W32.stream virus, developed in 2000, attached itself to a harmless file as an ADSs.

Creating and Manipulating ADS

Alternative data files can easily be created at the command prompt. An ADSs can be created using the following commands:

Echo "this is a text file" >C:\test.txt

Echo "stuff in a data stream" > C:test.txt:mydatastream.txt

The ADS is not displayed in Explorer or by using the dir command, as shown in Figure 5-30.

To read the ADSs, use Notepad with the following command:

Notepad file.txt:mydatastream.txt

The file contents will be displayed in Notepad, as shown in Figure 5-31.

Reading a single data stream when you know it's there is not hard, but how do you discover the data streams that you don't know about? Data streams used by legitimate Windows systems are of little interest, but rogue data streams that contain malicious or undesirable data might be stored on a computer's hard drive. ADSs have been found on computer disks that contain pornographic material. At the least, unauthorized data streams use disk resources. If you don't know if any are present, how can you determine if any of them hide malicious code or data that should not be on the computer? This is one of several security issues engendered by ADSs. Issue include these:

Few administrators or security officers understand them; therefore, few administrators or security officers look for them. Data streams that harbor malicious code might be saved as the data stream of an innocent file. Two known viruses, Dumaru.y and W2K.Stream, take advantage of ADSs.

Some anti-virus products may not scan data streams.

Products that wipe disks (that replace data on the disk with zeros to ensure that no one can obtain the data that was once resident on the disk) may not replace the content of ADSs.

Tools That Make Detection Easier

There are third-party tools that check for ADSs. A few of the available tools are as follows:

LADS (list alternative data streams) scan through directories and find ADS files. Available from http://www.heysoft.de/nt/ep-lads.

Streams is freeware available from Sysinternals (http://www.sysinternals.com/ntw2k/source/misc.shtml#streams).

Crucial ADS is available from http://www.crucialsecurity.com/downloadsl.

TDS-3 commercial can scan specific directories. A demo copy is available for download at http://tds.diamondcs.com.au/.

Deleting ADSs is difficult. To delete an ADS, you must either delete the file it is linked to, or delete the folder it resides in. You can also copy the file to a FAT file system (data streams cannot be preserved) and then copy the file back to the NTFS location. You cannot delete ADSs attached to the root directory. If the ADS is large, you can, however, create small ADSs and use them to overwrite the ADSs attached to the root.

Executable files can be attached as ADSs. Running them requires use of the Start command.

At one time, anti-virus programs and disk-wiping programs had problems processing ADSs, but today most products are ADS-aware.

Setting Permissions Using Security Templates

File, folder, and registry permissions can be set in Security Templates and then applied to a single system or imported into a Group Policy. Permission settings can also be made directly in the GPO. The default security template, defltsv.inf, is used during Windows Server 2003 installation to set system, volume root, and registry permissions. If and when the server is dcpromoed (made into a domain controller), defltdc.inf is used to apply additional domain controller-specific permission sets. If you have additional security permissions for files, folders, and registry keys that are placed on every server, you can create your own default templates, save them using these names, and use them during your installs instead of using the ones provided on the installation CD-ROM. (You can find a copy of these templates in the <system root>\inf folder). Security templates can also be used to set permissions, test that permissions have not been altered, and reapply permissions as necessary.Chapter 11, "Securing Infrastructure Roles."

WARNING: Beware of Using Group Policy to Set Permissions

The Security Setting portion of Group Policy is refreshed every 16 hours, even if nothing has changed. If a large number of permissions is changed via Group Policy, this can become a performance issue, as can replication of large GPOs.

Recovery and Fault Tolerance

Several services that impact data security are as follows:

The Windows File Protection (WFP) service protects the integrity of system files by preventing their replacement. WFP can help protect against accidental deletion or replacement and can prevent malicious replacement of system files.

The System File Checker application can be used to check the status of system files on a specific computer.

Volume Shadow Copy allows end users to recover previous versions of their files. This helps reduce help desk efforts required to recover files from backup when the user accidentally deletes them.

These items will be discussed, along with other recovery and fault- tolerant services and practices, in Chapter 16, "Maintenance Strategies and Administrative Practices."

Clustering

Clustering technology in Windows Server 2003 consists of two distinct technologies:

Network load-balancing balances the network load between multiple (up to 32) identical computers. NLB is available on Windows Server 2003 Standard Edition and Web Edition. An example of such a cluster would be a group of ISA Server firewalls or a group of IIS web servers.

Server clusters provide up to 8-way failover for network resources. Server clusters are available on Windows Server 2003 Enterprise and Datacenter Editions. This may be used to provide redundancy and fault tolerance for databases and other large collections of files.

Clusters present a challenging data security issue. They are often used to ensure data availability, which is usually considered to be part of security. However, they can cause a security issue. Permission sets must be kept consistent across multiple computers in the cluster. The following are best practices for permissions on clusters:

Configure file share access by using permissions on the Parameter tab in Cluster Administrator, not the local computer file system share security. If permissions are changed using Windows Explorer instead, permission settings are lost when the resource is taken offline.

Do not give permissions to local groups and user accounts, with the exception of the local Administrators group. All other local groups and user accounts only have meaning on the local system, not on other nodes in the cluster. In the case of node failure, any permission set for local groups or users is meaningless; it will have no impact on the other node.

Set auditing for files and folders based on local user and group accounts using Windows Explorer. Audit events are by nature recorded only on the computer where they occur. If, however, you want to monitor usage by auditing, you will have to set consistent audit settings on resources of all nodes in the cluster.

Protect the folder on the quorum disk that stores the quorum log. This log stores all the changes to the cluster state and configuration changes that cannot be committed to other nodes.

Because clustering hardware can be more proprietary than the average server, it is important to pay close attention to the manufacturer's recommendations. You'll find that many of the security issues pertaining to clusters will be unique to that manufacturer.

DFS

To the ordinary computer user, file location on the network is a mystery. In fact, many users do not even recognize that the files they access every day are not stored on their local disks. If users are allowed to make their own connections to file shares to access network resources, it may be a daunting task for them. Even administrators, who must set up drive mappings for users, can have difficulty locating just the right mapping when there are many and the organization of shares is volatile or non-existent. Browsing, the de facto way of locating resources, does not work well in large distributed environments. The distributed file system (Dfs) was created to alleviate this situation. Dfs enables an organized architecture to be created. Once connected to the appropriate Dfs root, the user can expand the root to reveal resources named for their content. Just as resource location is unimportant to users, resource location is not important to Dfs, and multiple locations for the same resource can be listed. The selection of which specific resource to visit is made by the system, and if a server that maintains a copy of the resource is not available, another may be.

Dfs network resources do not have to be located on Windows systems. Dfs can be configured to point to targets on Novell servers and Unix systems in addition to Windows systems.

This great network resource management system does introduce new security issues. First, Dfs adds no additional security. Security must be configured at the network resource location. Second, although data can be in diverse locations, when planning the location of network file resources, consider how they will be secured. It is not a good idea, for example, to place network resources where no file permissions can be applied, or where the ability to set file permissions may weaken access controls. Finally, if multiple copies of the same data exist, care must be taken to ensure that the security permissions are consistently kept.

Effective Security Options and User Rights Management

In addition to explicit permissions on file, share, and registry objects, the Security Options and user rights portions of Group Policy affect data security. The following elements should be considered when creating a secure data access architecture.

Restriction on Anonymous Access

Chapter 2, "Authentication: Proof of Identity," described the need for controlling anonymous access. If anonymous access is granted to shares, the permissions created for shares will only restrict authorized users.

Do Not Make Anonymous Members of the Everyone Group

Some anonymous access may be required. For example, users must be able to connect to domain controllers to authenticate. Nonetheless, take care to restrict anonymous access to data. In addition to preventing direct application of permissions for the Anonymous group, the Anonymous group should not be added back into the Everyone group. The Everyone group is granted broad access to files, folders, and registry keys.

The Bypass Traverse Checking User Right

This user right allows the user to programmatically access files he has permission to access, even if he does not have access permission to the parent folders.User Rights " in Chapter 3.

Format and Eject Removable Media

The Security Option Devices: Allowed to format and eject removable media controls permission to format removable disks and remove them. Although most removable disks, such as USB and Firewire-based drives, can simply be unplugged, there is some danger that data will be damaged. Managing the ability to format may be more important because accidental or malicious formatting of these drives could be a problem.

Restricting Remote Access to CD-ROMs and Floppies

If a user is logged on, the Security Option Devices: Restrict CD-ROM Access to Locally Logged on User prevents remote access to the CD-ROM. However, if no user is logged on locally, this setting will not prevent remote access to the CD-ROM drive.

Devices: Restrict floppy Access to Locally Logged on User
If a user is logged on, this setting prevents remote access to the floppy. However, if no user is logged on locally, this setting will not prevent remote access to the floppy drive.

Network Access: Remotely Accessible Registry Paths
Allows controlled access to registry paths.

Network Access: Remotely Accessible Registry Paths and Subpaths
Allows controlled access to registry paths and their subpaths.

Network Access: Shares that can be accessed anonymously
Only these shares allow anonymous access if other anonymous restrictions are set.

Shutdown: Clear Virtual Memory Pagefile
On shutdown, clears the pagefile. Any type of data may be paged to the pagefile while the system is running. The pagefile is protected while the system is operational; however, when the system is shut down, it is just an ordinary file and might be accessed from a boot to another OS. To ensure that sensitive data cannot be accessed in this manner, use this setting.

Controlling Access to Event Logs

The operating system, services, and some applications automatically record information in the Windows event logs. Additional events are recorded when applications are configured to do so. These events may include useful information for troubleshooting, warnings that something needs attention, alerts of potential attacks, and historical documentation that may be necessary to compose an audit trail for criminal prosecution.

Processes within applications can be coded to post records, to read records, and to archive or clear the event logs. To perform these actions, the application must be running in the security context of an account with the privileges to do so, either because an individual with those privileges runs the application, or because the service account used to run the application is given those privileges. For example, Microsoft Exchange Server posts records to the logs under the authority of its services accounts. Logon audit records are posed by the SYSTEM account. On the other hand, only an administrator can use the Event Viewer application to delete the content of an event log.

By default, each log has its own permission settings. Default permissions on Windows Server 2003 event logs are displayed in Table 5-9.

Prior to Windows Server 2003, event log access could be granted to members of the Guest account by modifying the registry key RestrictGuestAccess at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\EventLog\Application. In Windows Server 2003, RestrictGuestAccess is ignored, and two new registry values can be used to determine access: one for access to the Application log and the other for the System log. Both values are part of subkeys of the EventLog key above. To manage access to the Application log, use the CustomSD key under the EventLog\Application key; to manage access to the System log, use the CustomSD key under the EventLog\System key. Acceptable values are as follows:

0x0001
Permission to read the log file.

0x0002
Permission to write to the log file.

0x0004
Permission to clear the log file.

These permissions have no value for the security log file. Regardless, only the Local Security Authority has write permission for the security log files. Likewise, if a user has the SE_Security privilege, he can read and clear the security log regardless of how CustomSD keys are configured.

WARNING: Do Not Weaken Security on the Security Event Log

Access to the security log is limited to prevent tampering with audit records. Rather than broadening access to this log, consider restricting it to a subset of administrators. The integrity of the records in this log is critical to proving an audit trail of activity on the system. This may be important for discovering security breaches and holding accountable system users and attackers.