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

Rights, Privileges, and Permissions

As you read about Windows access controls, you may find that the words "rights," "privileges," and "permissions" are used interchangeably. Don't get confused. One author often uses the term "privilege" when another will use the word "rights." Some discussions, especially those talking about Windows NT access controls, make the distinction that privileges are divided into Logon Rights and user privileges. The Windows 2000 and Windows Server 2003 interface, however, includes privileges and logon rights in the section of Local Policy called User Rights. Permissions are sometimes called "object permissions" and sometimes just "permissions." The real distinction is that rights and privileges are something that you can do system-wide, such as create users or shut down the server, and permissions are things you can do to an individual object, such as read a file.

In this book, user rights are those defined in the User Rights section of Local Policy and the implicit rights that default accounts are given. User rights are granted to users, groups, and computers. Permissions are the access controls defined on a specific object, whether it is a file, folder, printer, registry key, or Active Directory object. Rather than introduce a long list of rights and detail all of the object permissions that are available in Windows Server 2003, rights and permissions are defined as appropriate to the discussion. In this chapter, those rights that impact the ability of a user to log on and those that broadly restrict access will be detailed. Whenever implementing modifications to user rights, best practices advise doing so by using security groups, not individual user accounts.

Implicit Rights

The built-in accounts, which are created during Windows Server 2003 installation, and accounts created when an application or service is installed are granted a set of rights on the system. Some of these rights are defined in the User Rights Assignment section of Group Policy, and some of them can be removed. (Reducing the rights of a default account will reduce the ability of the account to function on the system.)

However, other user rights, such as the right of a member of the Administrators group to take ownership of any object, cannot be removed. Such rights are implicit rights.

Logon Rights

Even though logon rights are included in the broader category of user rights, it is convenient to group them for purposes of discussion. Logon rights are those rights that define a user's right to log on. A user may present valid credentials such as a user account name and password and therefore be authenticated but still be denied access to a specific system because the user has or doesn't have one of these logon rights. Ordinary users, for example, do not have authority to log on to a Windows Server 2003 domain controller from the console, while members of the Administrators group, members of other administrative groups, and those explicitly assigned this right do.

Allow Logon Locally

The Log on Locally right allows the user to start an interactive session. An interactive session is initiated by entering credentials at the console, remotely by using Terminal Services, or possibly by using web-based applications. Terminal Services interactive sessions, however, should be controlled through the two logon rights: Allow Logon Through Terminal Services and Deny Logon Through Terminal Services. If you use those two rights, you do not need to assign the terminal services users the Allow Logon Locally right. If you give terminal services users the Allow Logon Locally right, you also allow them to use the console of the terminal services computer, which presents a security risk.

On a domain controller (DC) and servers, you should restrict this right to Administrators, Backup Operators, and Server Operators. Alternatively, in areas of high risk or in large enterprise environments, you may want to consider limiting this right to a subset of administrators, or limiting this right on specific servers or groups of servers to different subsets of administrators.

If users are denied logon using one of the Deny logon rights, those rights supersede the Allow logon rightsthe user will not be able to log on.

Allow Logon Through Terminal Services

The Terminal Services logon right allows the user to use a Remote Desktop connection to log on. Users in the Remote Desktop Users group will also be able to log on using a Remote Desktop connection; it is not necessary to explicitly give them this right. On a domain controller, you should only grant this right to Administrators. If a computer is not running Terminal Services in application mode, do not assign this right, and do not assign membership in the Remote Desktop Users group to anyone who does not need it to perform remote administration. If a server is providing application mode terminal services, only provide membership in the Remote Desktop Users group to those who should have it.

Deny Logon as a Batch Job

The Logon as a Batch Job right is needed to schedule jobs run by the Task Scheduler, a batch-queue facility. This right might be used to launch denial of service (DoS) attacks or to run malicious programs. Best practices are to at least deny this right to the local Guest account. Only administrators tasked with scheduling jobs to run should have the right to log on as a batch job.

Deny Logon as a Service

An account used to run a service requires the Logon as a Service right. Accounts given this right could be used to launch Trojans and other malicious programs as services. Use this right to prevent accounts from logging on as a service.

Deny Log on Locally

Users will not be allowed to log on using an interactive session.

Deny Logon Through Terminal Services

Users are not permitted to establish an inbound terminal server connection. This includes denying the ability to make a Remote Desktop connection.

Log On as a Batch Job

The user can log on using a batch-queue facility such as Task Scheduler. This right is required for accounts used as the identity of DCOM servers and COM+ applications. By default, the system manages this right. If an administrator schedules a job to run under another account or uses DCOM configuration or the Component Services management console for assigning user account as identity of DCOM server/COM + applications, that account is given this right automatically by the system. If you give this right to accounts (manage this right via domain-based group policies, for example), you will not be able to allow the system to manage it, and you should ensure that the right is given to the Local Service account. On an IIS 6.0 server, the IUSR_computername and IWAM_computername accounts should have this right. (If they do not, they will not be able to run some necessary COM objects.)

Log On as a Service

The account can log on as a service. The Local System, Local Service, and Network Service accounts have this right. If user accounts are used as service accounts, they must be given this right.

User Rights

Additional rights define specific access to the system. Rights that only make sense in the context of a domain controller are discussed in Chapter 7, "Active Directory's Role in Domain Security."

Access This Computer from the Network

This right allows connections to a computer from the network. Connections made using protocols such as SMB, CIFS, NetBIOS, and COM+ require this right. Although it is possible to remove this right by changing its status to Not Defined, doing so prevents necessary connections and malicious ones. For example, removing this right on a domain controller will prevent the DC from being used for logon and will therefore hamper access to network resources. You can, however, change the defaults and restrict access to administrators and users for Domain Controllers, and you can restrict access to specific groups on servers. For example, if a file server should only be used by members of the Human Resources department, you could create a custom group that has as members all Human Resources department members. Then you could remove authenticated users from this right and add administrators and Human Resource groups.

NOTE: Lock Down Versus Lock Out

In their eagerness to lock down systems, administrators new to Windows may attempt to restrict the Access this computer from the network right. They may define it too narrowly. This was the case at a junior college I visited recently. They had removed all groups except the Administrators group from this right, and then they wondered why users could not remotely access resources. When they gave the right back to the groups, the problem was solved.

Act as Part of the Operating System

The operating system has access to every user's information and can perform any task that an individual user can. Assigning this right to a user allows the user to do anything the operating system can. He will be able to impersonate any user without explicit permission or to ask that additional explicit rights be added to the access token used by some process they are running. It is also possible that the user might create a token to which no identity is attachedthus effectively hampering any auditing or forensics. You might, for example, be able to tell that something did take place but not be able to determine who performed the action. In essence, a user who has this right can take over the system and leave no evidence of what he has done with it. This is not a situation that you want to have. The LocalSystem account has this right by default, and it is recommended best practice that if the right is required by a service account, you assign the Local System account to that service for logon instead of creating a new account and granting it that right.

Adjust Memory Quotas for a Process

This right determines who can change the maximum memory that a process can consume. This right can be used in application tuning, but if misused, it can result in a Denial of Service (DoS) attack. If a user reduces the amount of memory available to business-critical applications, he might cause them to cease responding. On the other hand, increasing the memory available to other operations might also have a similar impact. This right may be required by some service accounts, such as the service account used by the cluster service. By default, only administrators and the Network and Local Service group have this right. You may want to further restrict this right only to administrators who may need it to perform their job, such as those in charge of the Active Directory and its infrastructure, and those managing database management systems.

Backup Files and Directories

This right determines which users can bypass file, directory, registry, and other object permissions for the purpose of backing up the system. This right is only usable by applications, such as the native NTBACKUP.exe program, that use the NTFS backup application programming interface (API). It does not allow the user to read the file by using an application such as Word or a program that does not use the backup API, in this case. When the user uses these other techniques to access the file, normal permission settings apply. If the user has permission to read the file, he will be able to read it. If he does not, then he will not be able to. There is no way, however, to know if an authorized user is using this right to obtain a copy of files or is just making an authorized backup. This right does provide the bypass traverse checking right; however, this is the default access control status for all users. If the bypass traverse checking right is removed but is given to some users, administrators should understand that this right also grants bypass traverse. By default, Administrators and Backup Operators groups have this right.

Bypass Traverse Checking

Bypass traverse checking allows a user to traverse directory trees even if the user does not have permissions on the directory. The user cannot list the contents of the directory, but if he has permissions to access a file within a directory, he may programmatically access the file, even if he has no permission on the folder that the file lies within. In Figure 3-3, user Joe has read access to the file Document 1 but does not have permission to the Folder1 folder within which the file resides. Joe cannot use Windows Explorer to browse to the file and open it; however, he can use a program that identifies the path of the file. By default, all users of Windows systems have this right. If you remove this right, you may break applications. (Many Windows applications, including the operating system, are designed on the premise that everyone has this right.)

Change the System Time

This right determines which users and groups can change the time and date on the internal clock of the computer. If a user can change the time, he can make the time on events in the event log appear to be different from what they really are and then can create and modify timestamps on files and folders. Users may also be unable to authenticate because Kerberos is time-sensitive. However, automatic time synchronization in a domain may mitigate this effect. Nevertheless, event time is critical to auditing, and being able to demonstrate that a user might have modified it may be sufficient to establish doubt that your audit trail is accuratean accused perpetrator may be proven innocent. It's also important to think of the impact here if the Time service itself were manipulated, either by turning it off or by pointing it to an inaccurate timeserver.

Create a Page File

This right determines who can create and change the size of a page file. The page file is used to temporarily store system and user data. Even a system with a very large memory requires a page file. The operating system will create a page file at boot if one does not exist. With this right, however, a user can change the location and size of the page file and can create additional page files on different drives. User management of page files can be done from the Systems applet in the Control Panel. A user might maliciously or accidentally use this right to create a too-small page file that might result in system instability. By default, only administrators have this right.

Create a Token Object

This right determines an account that a process can use to create a token. Tokens are used to obtain access to local resources. A user's rights are determined by inspecting the access token attached to processes she is running on the system. The token is created by the operating system when the user logs on to a Windows computer or accesses it over the network. A user with this right could change another user's rights or grant him access to resources on the computer by making it appear as if he had membership in a group given that access. By default, this user right is not assigned, and it should not be. If a process requires this right, have the service log on using the local system account.

Create Global Objects

Global objects are those that are available to all sessions running on the system. If a user can create a global object, he may impact other processing, including causing processes to fail or causing data corruption. Users do not need this right to create objects for use in their own sessions.

Create Permanent Shared Objects

Permanent shared objects are things like shared printers, folders, and other objects in the directory. This right is not assigned by default and should not be assigned. The local system account has this right. Administrators will be able to create, modify, and delete shared folders and printers.

Debug Programs

This right gives the user the right to attach a debugger to a process and therefore debug programs. If a user with this right uses specific attack code, she can obtain password hashes and other security information. By default, only administrators have this right. You can further restrict this right by removing the Administrators group. Debugging should be done on test systems, not production systems. However, should the need arise, an administrator can temporarily be granted this right. Be aware, however, that some software usage requires this right, such as the implementation of some Microsoft patches.

Deny Access to This Computer from the Network

If an account can access a computer over the network, it may be able to obtain information, such as user account lists, or connect to shares that are not restricted. Denying that right by using this user right can provide another layer of protection. Deny this right to the ANONYMOUS LOGON, the built-in local Administrator account, the local Guest account, and those service accounts that do not require access over the network to this computer.

Force Shutdown from a Remote System

This right allows a user to remotely shut down a system. This right should be restricted to the Administrators group.

Generate Security Audits

This right gives a process the right to put records in the audit log. An attacker could use this right to write to the log events that did not happen. Depending on the settings in the audit log, an attacker with this right could fill the log and create a DoS condition. The LocalService and NetworkService groups should have this right assigned.

Increase Scheduling Priority

This right allows a user to increase the base scheduling priority of a process. This right is not ordinarily required, but some programming tools may require it. A user with this right could elevate the scheduling priority of a process to real time and therefore prevent other processes from functioning normally, thereby causing a DoS attack.

Load and Unload Device Drivers

This right determines who can dynamically load and unload device drivers. Because device drivers run as privileged code (they run in the kernel), a user with this right can inadvertently or maliciously load a Trojan or other malicious code that is purported to be a device driver. This right, plus membership in the Administrators or Power Users group, is required before you can load a new driver for local printers or manage a printer. (This requirement for both membership and user right is new to XP and Windows Server 2003.)

Lock Pages in Memory

Most system and user data is paged in and out of memory as necessary. However, some system data is never paged. Use of this right allows a user to lock other pages in memory and thus may restrict the ability of the system to manage memory appropriately, resulting in performance problems or DoS attacks.

Manage Auditing and Security Log

This right allows a user to assign object access auditing for files, AD objects, and registry keys. The user can also view and clear the security log from the Event Viewer.

Modify Firmware Environmental Values

This right allows a user to configure firmware environmental variables either through a process or through System Properties. Abuse of this right could cause the system to fail, resulting in a DoS attack.

Perform Volume Maintenance Tasks

This right allows a non-administrator to manage disks. Abuse of this right might mean the user could delete a volume, resulting in loss of data or a DoS attack.

Profile Single Process

This right allows a user to observe the performance data of an application. An attacker might use this information to determine which processes are running on the system and therefore choose specific attack methods. A user might also identify countermeasures, such as intrusion detection systems or anti-virus products, that might be running and use this information to avoid detection by attempting to disable these systems or performing attacks that cannot be detected by them. This right is not necessary to run the Performance Monitor snap-in. It is required if the System Monitor is managed by Windows Management Instrumentation (WMI).

Profile System Performance

This right allows a user to sample system performance. The attacker might learn information that would assist him in an attack. This right is not needed to run the Performance Monitor snap. It is required if the System Monitor is managed by WMI.

Remove Computer from Docking Station

This right is only required to remove a computer from the docking station by selecting the Eject PC choice from the Start menu. The computer can be removed without this right if the system is shut off or if the Windows system has not booted. Also, there is nothing to prevent a thief from also stealing the docking station. Users of portable systems with docking stations should have this right so they do not have to shut systems down to remove them from the docking station. This right is, in most cases, irrelevant to Windows Server 2003 because servers are not run on portable laptop computers.

Replace a Process Level Token

This right allows a parent process to replace the token used by a child process. An attacker with this right and the Change Memory Quota Process right could launch processes as other users and even hide what he is doing on the system. Only the Local Service and the Network Service groups need to have this right.

Restore Files and Directories

A user with this right can restore files and set any valid users as owners of objects. An attacker could use this to overwrite current data with old data. The current data would therefore be lost.

Shut Down the System

This right allows a user to shut down the local system. Restrict this right on servers and especially on domain controllers. Shutting down critical systems can mean a DoS attack.

Synchronize Directory Service Data

This right allows a process to read all objects and properties in the directory, regardless of protection on the objects and properties. It is required to use LDAP directory synchronization services. Only domain controllers should be able to synchronize directory service data. The synchronization process runs in the context of the Systems account, and it has this right. An attacker with this right could view sensitive data, such as employee phone numbers or addresses, or information that might allow him to mount a successful attack.

Take Ownership of Files or Directories

This right allows a user to take ownership of any securable object in the system, regardless of the permissions on that object. He could then give himself the necessary rights to view, change, or delete the objects.

WARNING: Protect Systems from Power Users Group Elevation of Privilege Attack

Membership in the Power Users group is often granted to users who need privileges beyond ordinary users but who do not require full administrative privileges. However, because of the rights granted to power users, a malicious user with membership in this group might be able to elevate their privileges to that of administrator. Power users can install programs and dlls that might elevate their privileges or add them to the Administrators group. Although the Power Users group does not have the right to run such a program, if they could trick an administrator to run the program, the power users would receive the rights or membership granted by the program. The only way to prevent this possible elevation of privilege is not to assign membership in the Power Users group.

Adding and Removing Predefined User Rights

User rights determine what a user can do on an entire system. Object permissions define what a user can do with a specific object or a collection of objects; rights operate at a broader level. Rights are assigned by adding a user account or a group account to the User Rights section of the Local Security Policy of a standalone server. If the server is joined to a domain, then user rights can be defined through the use of Group Policy.

Complete the following steps to add local user rights. You can also remove a user or group by following this procedure:

Many operations require the use of the object picker to select users or groups. To do so, use one of the following techniques:

Type the name in the Enter the Object Name to Select text box and then click Check Names to verify that the name exists as an object.

Click Advanced and then click Find Now if you are unsure of the name. As illustrated in Figure 3-5, this action displays a list of users and groups on this computer. Select the accounts to be added.

Recommendations for Lockdown

The default settings for user rights are reasonable. However, Microsoft recommends several modifications to user rights in the document "Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP." Table 3-2 lists these changes, including an abuse potential rating and the impact of making the recommended change. The impact of making a change should always be considered. The operating system manufacturer should not be allowed to determine security settings. Instead, organizations should do a risk assessment and modify security settings to mitigate that risk. However, even if a change would have a severe impact, you may want to consider it if the security risk is large enough.

Table 3-3 lists Microsoft recommendations that are implemented by default.

Best Practices for Assigning User Rights

Those new to Windows or new to thinking about Windows security often jump in and begin restricting user rights or granting user rights that sound as if they should be available to groups such as administrators. Do not follow that practice. Instead, make sure you understand the impact of user rights, especially how they may be combined either to deny access to those who require it or to allow access to those who should not require it. Review the default rights assigned to default groups and don't attempt to remove them until you know why it may or may not be a good idea. In addition, do the following:

Assign user rights to groups, not to individual users.

Leave rights at default assignments, or restrict them cautiously. A number of rights can prevent further administration of the domain.

Test modifications on a test system.

Use Deny rights to apply to subsets of groups already given Allow rights. Hence, deny specific accounts or groups where the Users group has the Allow rights.

Do not deny the Everyone group a right. If you do, you have denied all users the right. You cannot deny Everyone and then "allow" some. You can, however, allow the group Everyone and then deny some.

Use caution when removing rights on well-established domains. A number of rights may provide necessary administrative rights to legitimate valid users. Rashly removing them can result in the inability of administrative staff to perform their duty. Also don't rashly add rights to user groups. Do not provide rights to a larger number of individuals without good reason, and don't give too many rights to users who do not need them.