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

Software Restriction Policies

Imagine if you could prevent a new virus from running on your systems even before your anti-virus vendor had prepared and made public a signature. Imagine if you could prevent well-known but forbidden software such as games or administrative tools from being run by anyone on your system. Imagine if you could prevent as-yet-unknown malicious software from running at all. Would you buy the product that allowed you to do so?

You don't have to. If you have Windows Server 2003 or Windows XP Professional, you already have such a product. Software Restriction Policies is a component that was introduced with Windows XP Professional for the management of a single computer. You can use Windows Server 2003 to write group policies that impact a single server or desktop or thousands of XP Professional and Windows Server 2003 computers. Here's how.

Software Restriction Policy Limitations

If you do not fully understand Software Restriction Policy scopethat is, what it can and cannot do to various thingsyou may either configure it incorrectly or rely on it for a level of security that it cannot provide. In either case, policies may not work the way you think they do, or worse, you may develop a false sense of securityyou may believe you have protected computers from malicious software or prevented anything but authorized programs from running only to find out that this is not so. Properly designed Software Restriction Policies can provide improved security if you understand and work with Software Restriction Policy limitations. The following limitations should be understood.

Software Restriction Policies Have No Effect in Safe Mode

When a computer is booted in Safe Mode, Software Restriction Policies have no effect.

WARNING: Safe Mode

Software Restriction Policies have no effect in Safe Mode. If the user can boot to Safe Mode, she can get around any Software Restriction Policies.

Local Security Policy Affects Every User of the Computer

Software Restriction Policy created in the Local Security Policy will only affect that computer. Because it is a computer-wide policy, it affects every user unless its properties are set to exclude members of the Administrators group. If, however, you use a Group Policy-based Software Restriction Policy, you can create Software Restriction Policies in either the Computer or User Security settings of the GPO. You can determine whom the policy will impact by only applying it to OUs within which specific user or computer accounts lie, or you can filter the GPO's application by removing the Apply Group Policy permission for the desired user groups.

Some Software Is Not Affected by Software Restriction Policies

Software Restriction Policies do not apply to the following:

Drivers or other kernel mode software

Programs run by the SYSTEM account

Macros in Microsoft Office 2000 or Office XP documents (manage macros in Office with the Office Macro security settings)

Programs written for the common language runtime (these programs use Code Access Security Policy)

There Are Ways to Get Around Rules

Software restriction policies include individual rules that prohibit or allow the use of specific software. However, there are limitations to the effectiveness of each rule. This does not mean that you cannot create effective rules that prohibit use of software; it just means that you must understand each rule's limitations and use it appropriately. Examples of rule limitations are as follows:

If the code of an application changes, a hash rule no longer applies.

If the path of an application changes, a path rule no longer applies.

Internet zone rules apply only to applications created with the Windows Installer.

Certificate rules rely on the trust you place in the certificate.

For information about these rules, see the section "Creating and Using Software Restriction Policies."

Software Restriction Policy Basics

Restricting access to software doesn't seem like a difficult task. All you have to do is not install it and not allow others to do so either. The problem is that you may lack the ability to control exactly what software should be installed, to control who can install it, and to control who can run software that is already installed on the computer. Some Windows default rights assignments help. A user needs administrative rights to install software that installs a service. But many applications do not do this and therefore do not require administrative rights to be installed. If a user has the right to copy a file to the disk, that simple process may be all the application requires to be installed. Finally, many applications such as Administrative Tools must be present on systems, yet we should deny ordinary users the right to use them. Access to these programs is controlled by user rights assignments and permissions and those you impose. Ordinary users, for example, cannot create or edit Group Policy Objects (GPOs). Other system applications and their associated registry values are protected by default from some types of users. Group Policy, object ACLs, careful control over user rightsall these things can be used to control access to objects. However, because of poorly coded applications, you may have had to give users administrative rights on their computers.

If you limit user access to resources such as files and registry settings, you may be able to mitigate the harm that might be done by running unauthorized applications. If you provide users awareness training and strictly enforce security policies, you may also prevent applications from being installed. However, none of these techniques will totally prevent the installation and use of rogue or malicious software.

NOTE: Software Restriction Policy Design

An excellent paper that includes information on designing software restriction policies is "Using Software Restriction Policies to Protect Against Unauthorized Software," available at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx. The paper includes design scenarios for Terminal services, line-of-business PC, and the use of different policies for different users.

When you use Software Restriction policies, however, you supplement default settings and hardening steps and provide a solution for controlling things that defaults and other operations cannot control. With Software Restriction Policies, you can do the following:

Prevent any software from running and then authorize each piece of necessary software individually.

Allow all software to run and then restrict specific software from running.

These basic security levels determine initially whether software will run or not. After a security level has been chosen, software restriction policies can identify software via hash, path, URL, or code signing certificate and prevent or allow the software to run based on its identification. The software does not have to exist on the system before a policy can be written to prevent or allow its use.

WARNING: Automatic Path Rules

Automatic path rules are created as a protection against locking all users out of the system. These path rules are always visible in the Additional Rules folder and are as follows:

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\SystemRoot%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\SystemRoot%\*.exe
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\SystemRoot%\System32\*.exe
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current
Version\ProgramFilesDir%

As a general rule, you should not modify these rules unless you are very knowledgeable about the registry and the access that the System requires to itself.

Creating and Using Software Restriction Policies

To establish a Software Restriction Policy, you must first create the basic policy and then write rules. To establish the policy follow these steps:

Create a Software Restriction Policy

A Software Restriction Policy is created in the Software Restriction Policy container of a local policy or Group Policy Object (GPO) in the Active Directory. Local policies only affect the machine that they are developed on, while Active Directory-based policies can be linked to domains and organizational units and can impact a multitude of systems and users in a uniform manner. Deciding where to link a GPO requires much thought and will depend on your Active Directory design. More details are available in Chapter 7. Regardless of where a policy is created, you should test its implementation on a single test computer that is configured in the manner typical for its use. If the policy is to be deployed on many machines in a domain, careful testing in a test domain or OU is required. Remember: Software Restriction Policies are powerful. It is possible to develop a policy that prohibits the use of software on a computer. Imagine what that would do if introduced into thousands of computers in your organization. As usual, deployment issues are the most complicated ones of this task; creating a policy for a single machine is simple. To create a Software Restriction Policy in the Local policy:

Set the Security Level

The security level determines whether all software is allowed to run unfettered (in which case some software will be identified as not allowed) or no software is allowed to run (in which case some software will be identified as allowed). Sounds simple, doesn't it? It will take a bit of work, regardless of your decision. The interface may also be a bit confusing.

To allow all software to run and restrict some, the security level is "Unrestricted." Not "allowed," or "ok," or "let all software run unless otherwise identified"nope, the security level you must choose (it happens to be the default, so we're okay at first) is "Unrestricted." Well, you might say, perhaps that makes sense; after all, the policies are called "Software Restriction Policies," so we want to indicate that unless software is restricted, it's unrestricted. However, the alternative security level is not "restricted," it's "disallowed." If all software is restricted, then it's "disallowed."

You'll find this funkiness repeated when you build the rules. Each rule has its own security levelit's either disallowed or unrestricted. We'll talk more about this use when we discuss each rule type; just keep this official naming convention straight at the policy level so you don't freeze thousands of user machines, okay? Remember: Unrestricted means anything can run unless you somehow restrict it. Disallowed means nothing can run unless it's allowed. A good rule of thumb is that you should set the security level to "disallow" only if you know all of the applications that must be run. Otherwise, set the security level to "unrestricted" (the default). Paradoxically, setting the level to "disallow" and then only unrestricting the software that is allowed to run can create the more secure environment. This, however, is more difficult than it might sound at first.

To set the security level for the policy, do the following:

Determine Enforcement

Local Software Restriction Policies are computer-based, while Group Policy-based Software Restriction Policies can be computer- or user-based. You can prevent administrators from being affected by policies by using the All users except local administrators enforcement rule. Alternatively, select All users to make sure the policy applies to all usersincluding members of the Administrators group. If users must be members of the local Administrators group on their own machine, be sure not to set enforcement for All users except local administrators.

A second enforcement choice determines if software libraries are restricted. Software libraries are code files that are not executable but are used by executable files. In most cases, this means a file type of DLL. Set either All software files except libraries (such as DLLs) or All software files. Choosing All software files except libraries simplifies policy writing and prevents performance degradation. It assumes that if you want to allow software to execute, you want its libraries to be accessible. It also assumes that if you want to disallow software, its DLLs won't be executed. It doesn't manage the libraries. However, you may want or need tighter control. Remember, however, that DLL checking can reduce performance. Each program the user runs causes a software policy evaluation. If I run 10 programs, 10 checks are done. If each program uses 15 DLLs, and I am enforcing DLL checking, there are 160 checks done. Libraries contain code that could be accessed by other applications that we may not be managing. If harm, either accidental or malicious, might be possible using these libraries, you may want to control them by changing enforcement to All software files.

WARNING: The All Software Selection Means Extra Work Identifying DLLs and Writing Rules

Be aware that if you chose the software security level of "disallowed" and an enforcement level of "All software," then to allow a specific software application to run, you must explicitly identify all of its libraries and give them the level of "unrestricted." This could prove to be an onerous task.

To configure enforcement, do the following:

Establish Designated File Types

What constitutes an executable? What types of files will be restricted if you set the Security Level to "disallowed?" These questions can be answered by viewing the properties of the Designated File Types object within the policy, as shown in Figure 4-24.

On this page, you review, add, or remove the file types that you want to designate as software for purposes of this policy. By doing so, you can keep policies updated if new software introduces new executable file types. You should guard access to this configuration page, because a malicious user might get around software restriction policies by removing a file extension from the list.

To inspect or modify designated file types, follow these steps:

Set Trusted Publishers Options

Trusted publishers are those organizations that you trust to publish safe code. This option affects only ActiveX controls and other signed content. Trusted applications are identified to the system by their certificate, and they use their private key to sign code that they produce. By selecting approved, trusted publishers, you can control whether or not signed software can execute on the computer. Add trusted publishers by importing their certificate into the Trusted Publishers container of the computer certificate store.

You can use the Trusted Publisher options, as shown in Figure 4-25, to manage who can accept publisher certificates and what things should be checked before a certificate is considered valid.

You can select End users, Local administrators, or Enterprise administrators as authorized Trusted Publisher selectors. By default, only domain and enterprise administrators can determine Trusted Publishers for entire domains or groups of computers. However, local users and administrators can accept offered certificates as trusted certificates on local systems if policy is not controlled at a higher level. The value of restricting certificate acceptance to administrators is that users cannot simply click OK when offered a certificate while downloading or installing software. By setting this level, you prevent them, for example, from making decisions about trusting ActiveX controls that they may download from the Internet or receive as attachments in email. After all, no one has to pass an ethics test to purchase or obtain a code-signing certificate. The only thing the certificate can do is to authenticate the signer in some fashion. You can further extend the concept of using certificates to control software by writing certificate rules.

You can require that Publisher, Timestamp, or both characteristics be used to determine the validity of a certificate. Selecting Publisher requires that the certificate be checked for revocation. Checking the Timestamp requires that the certificate be checked for expiration.

Creating Software Restriction Policy Rules

Software restriction policy rules are applied to specific software (using hash rules, certificate rules, computer path, and URL rules), to its location (using path rules and URL rules), and by referring to a registry path that controls it. Each type of rule has its own advantages and disadvantages. Path rules, for example, can unrestrict or disallow a large group of software in one simple rule. However, if a user can copy the file(s) to another path, she can execute the code. Hash rules can be applied only to a single executable per rule but will prevent a user from running that software, no matter its source, path, or name. However, if the software changes (the virus mutates or a new version of the game is produced), then you must write another rule. The best approach is not to rely on one type of rule, and especially not to set rules and then believe you will never have to set them again. The best approach even includes using file ACLs to further control a user's access to the executable objects.

Four types of rules can be created:

Hash rules

Certificate rules

Path rules, including file path rules and registry path rules

Internet zone rules

To complete your Software Restriction Policy, you must create rules. To begin, determine which software must run and which must not. Next, determine the type of rule to use, and finally, write the rules. The task of determining which software should run and which shouldn't is not easy. You will need to review your security policy and the jobs held by users of the computers, and you will need to consult with management. The suggestions in Table 4-3 may help you decide which type of rule to use.

When multiple rules affect the same software file, the precedence rule determines which rule will win by examining the rules against the precedence order. The order of precedence from top to bottom is as follows:

Hash

Certificate

Path

Internet zone

For example, if the security level of the policy is unrestricted, and a path rule disallows (prevents from running) the software, but a hash rule allows it, the hash rule wins, and the software can run. In the case of multiple path rules, the most restrictive rule will take precedence. For example, if a path rule is set on the C:\mysoftware folder that prevents software from running (the security level of the path rule is "disallowed"), but another path rule names the C:\mysoftware\approved folder and sets the security level to "unrestricted," then software in the C:\mysoftware\approved folder can run.

NOTE: Virus Rules

Software Restriction Policies are not meant to take the place of anti-virus products. Remember that hash rules don't work when files change (and viruses often mutate). Recall that virus names also can change. Anti-virus programs work to recognize patterns or signatures that the viruses have and are more effective in preventing infection. However, a software restriction policy could be written that could add some protection when a new virus is identified but a signature pattern is not yet available from your anti-virus product vendor.

You should test each rule on test systems before putting them on production systems. After configuring rules but before testing, reboot the system to ensure the rule is in effect.

Hash Rules

Hash rules work by creating a hash of the executable file. A hash can take a variable amount of information and reduce it to a unique digest of a standard size. Ideally, no two software files hashed by the same algorithm will ever produce the same hash. Signed and unsigned programs can be restricted with hash rules. The signed program may have a hash produced by either the MD5 or SHA-1 algorithm. When a hash rule is created, it will use whichever hash is present. If a file is not signed, the MD5 hashing algorithm will be used. The hash rule contains the hash, the file length, and an ID that identifies the hash algorithm.

NOTE: Always Choose Collision-Resistant Hashing Algorithms

While the possibility of collision (the production of the same hash from different data) is always present, it is unlikely to occur. When choosing hashing algorithms, developers should choose those currently considered to be less prone to collision. When considering choices between applications, administrators also should consider this. For more information, read http://www.rsasecurity.com/rsalabs/node.asp?id=2738, in which the 2004 results of research on collisions in MD5 are examined.

When a user attempts to run a program and there is a policy in place, a new hash is made and compared with the hash available in the hash rules. If there is a match, and the related hash rule specifies "disallowed," then the software will not run, no matter where the attempt to execute it is made. For example, if a hash rule is made for the sol.exe program, then it will apply to the program, no matter where the executable is stored or run from, even if it has been renamed. Users cannot get around the rule by copying the file to another folder. However, if the executable file changes, the hash made at attempted execution will not match any stored in the rules, and the software will run. To create a hash rule, follow these steps:

NOTE: If the Executable Changes, the Hash Rule Is No Longer Valid

Remember: If the executable changes, the hash rule is no longer valid. It does not matter how significant the change is, and there are simple, freely available tools that can be used to make minor modifications. Reshack.exe is such a tool. It is often used to modify the resources (such as the icon) in a Windows executable file. A determined user may easily discover this tool and learn how to use it. This points out the need for security awareness education, not to teach users how to do such a modification, but rather for administrators to recognize that it is possible and to develop alternatives to technical controls. It also makes a better case for establishing the use of "disallow all" and then only allowing approved executables.

Certificate Rules

Certificate rules can restrict or allow software based on the digital signature applied to the file. A certificate rule specifies a code-signing software publisher certificate. The rule uses the signed hashes from the signature of the signed file to match files. The location of the file does not matter. If the software is signed by one of the certificates identified in a certificate rule, then the security level specified will be applied to the file. This type of rule might be used if a company's policy is to require that all ActiveX scripts are signed by a specific digital signature.

Certificate rules apply only to the file types identified in the Designated Files types folder. To write a certificate rule, you must have a copy of the certificate associated with the signed files. The use of certificate rules must also be enabled using Group Policy. For example, to use a certificate rule to allow only those VB scripts that are signed by your organization's code-signing certificate, you must do the following:

Enable Certificate Rules in Group Policy.

Sign your VB scripts.

Extract a copy of the certificate to an accessible file location.

Add a path rule that disallows all scripts of this type, such as *.VBS.

Create a certificate rule that identifies your certificate and set the security policy to "unrestricted."

To enable the use of certificates rules, do this:

To create a certificate rule, follow these steps:

Internet Zone Rules

Internet zone rules only apply to applications that use the Windows Installer packages to install. Internet zone rules determine if an application from a site in that zone can be installed. All zones can be selected, including Local Computer, Internet, Local Intranet, Restricted Sites, and Trusted Sites.

To create an Internet zone rule, do the following:

Path Rules and Registry Path Rules

Path rules set restriction policies for software that is stored in or below that path. There are file path rules and registry path rules. You may use wildcards, such as * and ?, and environmental variables, such as %program files% or %system root%, in defining your file system path. If the location in the file system may vary from computer to computer and you know the registry path that specifies its location, then write a registry path rule. Registry paths must be enclosed in percent "%" signs and must be of a REG_SZ or REG_EXPAND_SZ value. You may not use abbreviations such as HKLM or HKLU.

If you have programs that must run at startup and you use the Run registry key to make it happen, create a registry rule for the path HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Run and set it to "unrestricted."

Alternatively, if you do not want to have programs run at startup by using this path, you should create a registry rule for the path and set it to "disallowed."

To create a path rule follow these steps:

Troubleshooting Software Restriction Policies

Many problems with Software Restriction Policies are the result of administrators or users not understanding how and why policies are created. A number of common issues may occur, such as these:

Users complain they received the message Windows cannot open this program because it has been prevented by a software restriction policy. This may be the expected result, because they are not supposed to run the program. Before changing the policy, ask the question, "Why is there a software restriction policy in place?" If the user should be able to run the application, look for possible conflicts between policies (inspect the precedence rule) and identify whether the policy is being applied to the correct Organizational Unit or domain in Active Directory or to the correct computer if Local Security Policy is being used.

A user complains that he cannot run an application that he has permission to run, and has correct. There are numerous software restriction policies in the domain that may affect the user. You can find the policy that is the problem by inspecting the GUID assigned to the policy rule that is causing the problem. Each software restriction rule is assigned a unique GUID. An event in the user's log will contain the GUID. Running gpresult, a Windows resource kit tool, or Resultant Set of Policy (RSOP) identifies the GPO policy that contains this GUID, and thus this rule. Inspecting the Software Inspection Policy may reveal a mistake, which can then be corrected.

Administrators complain that when running a utility from the command line, they get the message, "The system cannot execute the specified program." This may be a software restriction policy, because this is the message given if a policy prevents a program from running, and it is executed from the command line. Determine the administrator's right to run the utility, and look for possible conflicts. If the administrator should be able to run the program, but users should not, you may be able to set enforcement on that machine to "All users but Administrators."

A Local Security Policy Software Restriction Policy is not taking effect. Software Restriction Policies created in Active Directory will take precedence over those created locally. Check to see if a policy exists in the AD.

A Local Security Policy is taking effect, even though a domain policy exists. Check to ensure that the AD policy has refreshed. Check to ensure that the local computer is downloading the policy from the domain controller.

A change to Software Restriction Policies is now preventing anyone from logging on at the computer. It is possible to create a rule that prevents some software necessary for successful boot, including logon. You can recover by booting in Safe Mode, logging on as the local administrator, and fixing the policy. Software Restriction Policies do not take effect in Safe Mode.

A rule created to restrict a specific application is not taking effect. It is possible that the file type for the application is not included in the Designated File Types container for Software Restriction Policies. You can add the file type to this list.

You will often be able to determine why a Software Restriction Policy is having a problem by exercising common sense, reviewing settings, and referring to the common problems listed previously. However, when these options do not help, enabling advanced logging will allow you to record every software restriction policy evaluation. Advanced logging is enabled by doing the following:

To disable logging, delete the key.

Best Practices for Software Restriction Policies

When developing Software Restriction Policies, you will want to ensure that you get the best result. These policies can be a powerful agent in controlling what software can run on a computer, or they can hinder productivity and prevent work from getting done. Microsoft recommends the following best practices for software restriction policies.

If used in a domain, never set software restriction policies in the domain policy. Always create a separate GPO for software restriction policies. Because no software restriction policies are set by default, you have the option of recovering from an incorrect software restriction policy by removing or disabling a created software restriction policy and allowing the domain policy to be reapplied.

Never link to a software restriction policy in another domain, because it will result in poor performance.

Use WMI filtering. You can create a filter that restricts the application of a GPO to, say, computers with a specific service pack. WMI filters are set in the property pages of the GPO.

Use Security Filtering. You can filter which groups of users the policy will apply to. This is done by adding the group to the Security tab of the GPO property pages and (if you want the group to be exempt from the Software Policy) making sure they do not have the "apply group policy" permissions. You can also improve performance by making sure they do not have the read policy permission. If they do not have the read policy policy permission, the GPO will not be downloaded to their computer.

If you have problems with software restriction policies, reboot into Safe Mode. Software restriction policies have no effect in Safe Mode, so you can log on as administrator, change the policy, refresh the policy using gpupdate, and reboot.

If you are going to change the default security level setting to "disallowed," change the Enforcement setting to "All users except administrators" at least until you can troubleshoot the system. Setting the security level setting to "disallowed" will mean you must write a policy to allow each bit of software to run.

Use access controls (file and registry access control lists) in concert with software restriction policies. Users will attempt to go around policies by moving files, overwriting files, or adding other copies to other locations. You can deny them the ability to do so.

Before implementing policies, test them in a test network. If policies are to be used in a domain, test them in a test domain.

Do not guess about the effects of setting restrictions on files. Disallowing some files to run can prevent the system from running or can make it unstable.

Filter software restriction policy application when applied in a domain policy by denying read and apply policy permissions on the GPO.

Manage the designate file types container. This defines what file types besides EXE and DLL are considered to be programs. If you use "disallow" rules, which disallow all programs, and the file type is not defined here, the software will run. Path rules are also affected by this policy.

Change the default on the trusted publishers from "user" to local computer administrators for standalone servers and either the local administrator or enterprise administrators if the server is in a domain.

Ensure that users must periodically log off and log back on to systems. (When a new software restriction policy is implemented or there are changes to an existing software restriction policy, the user must log off and log back on again before the policy will take effect.)

If users are members of the local administrator group on their computer, change enforcement settings so that the policy applies to administrators.

Write a path rule for the attachment folder of email programs (the folder where attachments are temporarily placed and from which they can be run). If the path is disallowed, attachments cannot accidentally be run, and perhaps you will avoid the next attachment virus. If the attachment is a program that is okay and desired by the recipient, he must save it to another folder, one from which software is allowed to run.