Methods of Restricting Registry Access

As was already mentioned, Windows GUI was always oriented towards beginners who may need protection from human errors. Starting with Windows 2000, Microsoft began to introduce additional protective measures, practically each of these are also present in Windows XP and products of the Windows Server 2003 family. One such feature is known as "protected operating system files"(which shouldn't be edited, or even seen, by an ordinary user). These files are sometimes called "super hidden". Actually, there's no such attribute. The files simply have a combination of Hidden and System attributes. By default, Windows Explorer doesn't display these files. You may set Hidden and System attributes for the tools that ordinary users should not run, including networking tools, resource kit utilities and, of course, registry editors. Thus, you'll "hide" them from beginners, who may be afraid of command lines such as dir /a.

Note 

Did you place the Regedit shortcut on the desktop or on the Start menu (just for convenience)? Well, don't forget to remove all such shortcuts, otherwise users will be able to find them with the Search command. Also, don't forget that the Start menu contains the Run command, and setting the Hidden and System attributes won't prevent the user from starting Regedit.exe using this command.

Some other methods of preventing users from running potentially dangerous programs include the following approaches:

  • Removing executable files from users' workstations

  • Using Software Restriction Policies

  • Protecting executable files by using file system permissions

  • Editing access rights to registry keys

Removing Executables

One of the most common ways to prevent users from running undesirable tools is to remove the executables that you don't want them to run. For example, some authors recommend that one "delete Regedit.exe from all workstations". This, of course, will prevent beginners from running it. But what about convenience? A better solution would be to rename the file and move it to another directory. Of course, if you decide to do so, don't forget where you moved the file and what you named it. Besides this, there are other problems associated with this approach:

  • First, Windows File Protection (WFP) might make it difficult to remove tools that are considered part of the OS and thus protected. Furthermore, patches, system updates, and additional Windows components might reinstall the removed executable without warning.

  • Second, savvy users and skilled attackers can still provide their own copies of a tool that you want to restrict, not to mention other unauthorized programs, including software pranks, spyware, and keystroke loggers that could enable them to capture passwords or other sensitive information. This has become a primary concern with the arrival of pocket-sized ultra-portable storage media, such as USB Flash drives, which can hold 8 Mb - 1 GB of data that can be instantly accessed from any PC with a USB port. As was outlined in Chapter 2, the introduction of these devices into corporate networks offers users a convenient alternative to floppy disks and ZIP drives. At the same time, however, these devices present several security challenges to network administrators. Besides the introduction of harmful software, the threat of data theft is also a possibility. Note that any unattended and unlocked PC with a USB port can become an ideal target for attackers or disgruntled employees.

Note 

In order to protect one's computer against the risks posed by ultra-portable USB media, several steps can be taken. First of all, you must educate your users and establish a corporate policy for taking data out of the office and bringing files from home. In order to foil attempts at data theft, it is recommended that you configure all workstations to lock automatically when left unattended for a few minutes. Usually this interval is set from 10 to 20 minutes, but for those desktops holding sensitive data the recommended value is 5 minutes or less. Also notice that recently USB Flash drives with built-in security features have become available. Thus, if you don't want to completely eliminate such a device from being used, consider using only secure devices. Finally, you might wish to restrict USB ports on all desktops. Although USB devices can't be managed using Group Policy, you can use third-party tools such as SecureNT (which can be downloaded from http://www.securewave.com/products/securent/secure_nt.html). This software can control access to all I/O devices such as floppy drives, PDAs, USB external storage, CD-ROM, and many other PnP devices.

Using Software Restriction Policies

The ability to use Software Restriction Policies is a new feature of Windows XP and Windows Server 2003. Software Restriction Policies provide a completely new method of preventing unauthorized usage of system tools and other potentially dangerous software. It also helps you to restrict users by allowing them to run only approved software, and prevents attackers from using system tools in an attack on the system.

When using Software Restriction Policies, the system administrator can choose one of the following two approaches:

  • Create a policy that prohibits all software, then create unrestricted rules, which allow only approved software to run.

  • Create a policy that allows all software to run, then create a set of rules which prevents specific programs from running.

Software Restriction Policies are based on the following types of rules:

  • Path - Rules of this type explicitly identify a program path; can be bypassed if the user places a copy of the restricted program in a different location.

  • Hash - When a program is selected, a cryptographic hash is built. Any attempt to run the program will result in a check of the hash, and the program will be allowed to run or prohibited from doing so according to the policy type. In contrast to the previous type, rules of this type are not so easy to bypass, since the program can reside anywhere, and the action taken will be the same.

  • Certificate - Rules of this type are built based on the presence of a code publishers' software-signing certificate. Certificate rules apply to scripts and MSI files only. To use them, a code-signing certificate is used to sign the files. Certificate rules are used to identify the code-signing certificates that are valid on this computer or on the computers within the Group Policy Container (GPC) of this GPO.

  • Internet zone - This option enables the administrator to prevent users from running software from a particular Internet Explorer (IE) zone. However, this type of rule cannot prevent users from running software that has already been downloaded from that zone.

To create, examine, or manage local Software Restriction Policies, proceed as follows:

  1. Click Start, select Run, and type secpol.msc in the Open field, then click OK, or, alternately, open the Control Panel window, and select Administrative Tools | Local Security Policy.

  2. Select the Software Restriction Policies container. If no policy exists, right-click the container, and select the Create New Policies command (Fig. 9.1).

    click to expand
    Figure 9.1: Creating a new Software Restriction Policy

    Note 

    To create or manage Software Restriction Polices for a site, domain, or organizational unit (OU), open the Group Policy Object (GPO) for the appropriate container. The Software Restriction Policy container is located under Computer Settings | Security Settings.

  3. After you create a new Software Restriction policy, the console window will look as shown in Fig. 9.2. Enforcement properties include or exclude DLLs and identify whether the policy applies to members of the Administrators group (Fig. 9.3). By default, policies apply to all users and program files except library files such as DLLs. Additional settings include the Designated File Types option (Fig. 9.4) that allows you to edit the list of so-called designated file types, which includes files that by default are considered to be in executable code. Using this option, you can add new file types to that list as well as delete specific files from the list of executables. Finally, the Trusted Publishers option opens the Trusted Publishers Properties window (Fig. 9.5), where you can determine whether users, computer administrators, or enterprise administrators can select the trusted publishers of the software.

    click to expand
    Figure 9.2: Newly created Software Restriction Policies

    click to expand
    Figure 9.3: The Enforcement Properties window

    click to expand
    Figure 9.4: The Designated File Types Properties window

    click to expand
    Figure 9.5: The Trusted Publishers Properties window

  4. Using the Software Restriction Policies, you can easily create a policy restricting the use of specific software tools. To do so, you have to determine the list of tools that need to be restricted and the type of rule that will be used. Notice that it is up to you to compose the list of restricted tools (as was already mentioned, this list would normally include various networking tools, resource kit utilities, registry editors, and other potentially dangerous tools).

    Note 

    Notice that Software Restriction Policy is itself a potentially dangerous tool that can easily allow you to create such a policy that can wreak havoc on your organization by prohibiting users from running applications they really need or even preventing client systems from running. As a result, it is advisable that you first create a test policy using the Local Security Policy MMC snap-in on a standalone workstation running Windows XP, and then test it on a single machine first. Having created the policy, test it by applying it to a single OU that represents a test computer or computers to make sure that the test policy satisfies your requirements without having a negative impact on other software. After that, you can enforce the policy in multiple systems in your production environment.

  5. The best way of creating your first software restriction policy is by starting up with all software allowed to run and then creating rules that prevent individual programs from running. To illustrate this approach, let us create a simple Software Restriction Policy that will prevent the following tools from running:

    • All software located in the D:\Program Files\Resource Kit and E:\Olga\TOOLZ folders

    • Regedt32.exe and Regedit.exe tools (no matter where registry editors are located)

    • LC3.exe password-auditing tool (no matter where it is located)

    • Software on sites included in the IE Restricted Sites security zone

    • Solitaire game (sol.exe - no matter where it is located)

      The completed software restriction policy is shown in Fig. 9.6.

      click to expand
      Figure 9.6: The completed software restriction policy, which lists the policy type and basic information

  6. Since this policy should not restrict administrators, the first step to take is to set the policy so that it will only affect ordinary users. To do so, double-click the Enforcement object at the root of the Software Restriction Policy container. In the resulting window (see Fig. 9.3), set the All users except local administrators option, then click OK.

  7. Next, create a new rule for each tool that should be restricted. For example, in order to create a new path rule, right-click the Additional Rules container, and select the Create new path rule command from the context menu. The New Path Rule window will open (Fig. 9.7). Enter the path (for example, E:\OLGA\TOOLZ), leave the Security level option at Disallowed and click OK. Proceed the same way to create path rules for all the software that you want to restrict using path rules.

    click to expand
    Figure 9.7: The New Path Rule window

  8. To create a new Internet Zone rule, proceed in a similar way, but select the New Internet Zone Rule command from the right-click menu. Select the Restricted Sites option, leave the security level at Disallowed, then click OK.

  9. To create a Hash rule, right-click the Additional Rules container, select New Hash Rule command from the context menu, and, when the New Hash Rule window appears (Fig. 9.8), click the Browse button to locate a copy of the file that you want to prevent from running. The hash appears in the File Hash field, and information about the file will appear in the File Information box. Now, any attempt to run the specified program will result in a check of the cryptographic hash, and based on the results of this check, the program will be allowed or disallowed to run depending on the policy type. Leave the security level at Disallowed, and click OK.

    click to expand
    Figure 9.8: The New Hash Rule window

  10. The first time you create a rule of a particular type, test it. You can do so by logging off and logging on as an ordinary user, then by attempting to run the tool. You should be refused and receive the message shown in Fig. 9.9. Next, log on as Administrator and attempt to run the tool. You should be able to do so. Test all rules to ensure that they operate as you expect. Any changes to the rules should require a retest.

    click to expand
    Figure 9.9: Error message displayed to the user when attempting to run restricted software

After creating and testing software restriction policies, take some time to investigate them for possible holes. For example, when you create path rules, if a program file type is not covered by the Designated file types list (see Fig. 9.4), the program will be allowed to run. Path rules are the simplest to understand and create. However, they have their drawbacks. For example, they will only prevent the user from running restricted tools from within the specified folder and its subfolders. If the user can copy a tool from that folder to another location, that user will be able to run the tool. Furthermore, if the user can obtain a copy of the tool from another source (typically, download it from the Internet or bring it to the office using one of the ultra-portable media discussed above), the user will also be able to run it.

Note 

Finally, if you are creating path rules to prevent system utilities from running, don't forget to make a path rule that includes %windir%\system32\dllcache. A copy of the disallowed program might be available at this location, and if a path rule does not cover it, the program will be able to run.

Thus, if the aim of your policy is to absolutely prevent users from running certain tools, you should create hash rules for each one.

Note 

Hash rules, however, also do not provide absolute protection against undesirable software. For example, later versions of a restricted program will not be restricted by the hash rules that you have written.

Finally, consider what happens if a program calls another program that calls yet another one - you must carefully investigate what happens in each particular case. Of course, if the program is disallowed, it cannot run, and, therefore, cannot call other programs. On the other hand, if a program is not restricted, it can both run on its own or be called from within another allowed application. The situation is possible, however, when an unrestricted program calls a disallowed one. The disallowed program will not run, of course, but this might result in the failure of some unrestricted programs, which might be required for users to do their jobs. Another important point that you need to consider is situations in which there are multiple policies applied to the same program. In this case, you must be aware of the following order of precedence that exists when processing software restriction policies (the first item in the list has the highest precedence):

  • Hash rule

  • Certificate rule

  • Path rule (if path rules conflict, the most restrictive will take precedence)

  • Internet zone rule

To conclude our discussion of software restriction policies, it is necessary to emphasize several other points, briefly listed below:

  • Before designing and implementing domain-wide software restriction policies, you will have to migrate to Windows Server 2003 domains and upgrade all clients to Windows XP. Remember that Windows 2000 and earlier versions are unable to process software restriction policies.

  • Be aware that this technology is rather new, and it will take time before it becomes mature and reliable. At the moment of this writing, it was not totally bug-free, and even the simplest local software restriction policies required careful testing before they could be implemented in a Windows Server 2003 domain. Still, this new technology is very promising, and as you migrate to Windows Server 2003 domain controllers, will prove to be rather useful.

Setting Restrictive File Permissions

The easiest way to avoid problems caused by unskilled users who damage the registry is to simply prevent their access to the registry. Setting restrictive file permissions is the best-known and time-honored way of preventing undesirable access to critically important files, including system utilities such as registry editors, registry hives, and user profiles. Unfortunately, this approach is not totally free from drawbacks and limitations, the most important of which are briefly outlined below:

  • This method of protection can only be used when, according to the recommended security practices, all drives on all Windows NT, Windows 2000, Windows XP, and Windows Server 2003 computers are NTFS-formatted. Unfortunately, using NTFS isn't always possible. Sometimes it's necessary to use the FAT file system in multi-boot systems or because of legacy applications (this reason is the most common one). Thus, if it's necessary to use FAT, you'll need to develop alternative measures of protecting the registry.

  • Although standard file permission settings on system files and folders are fairly secure when the Windows NT-based system is installed on NTFS drives, and the system administrator might further harden security on network servers and user workstations, there is still no guarantee that for every machine, every permission setting is correct.

Note 

More detailed information on the default file and registry key permissions in Windows Server 2003 will be provided later in this chapter.

  • Finally, this method doesn't prevent savvy users or attackers from placing their own copies of restricted tools in a folder where they have the right to run the program.

Editing Access Rights to the Registry Keys

If you have some previous experience working with Windows NT/2000, you'll certainly notice that many of the security features in Windows XP and Windows Server 2003 will be quite familiar to you.

For example, similar to Windows NT/2000, Windows XP and products of the Windows Server 2003 family identify users and groups using security identifiers (Security Ids, SIDs). Security identifiers are quite long, and are unique for each user (even for user accounts in different systems). If you first delete the user account on the local computer or in the domain, and then create a new user account with the same login name, the system will generate a new security ID for that account. There's no way to have two identical security Ids. SIDs have the following format: S-1-XXXXX1-YYYYY2-....-RID, where: S-1 - security ID, version 1; XXXXX - authority number, YYYYYn - subauthority numbers, RID - relative identifier (Relative ID). Notice that the Relative ID (RID) won't be unique for each computer.

Note 

Also notice that many users, even experienced ones, often think that the system identifies each user by his or her credentials - username (or login name) and the password. This isn't so; it's the SID that uniquely identifies the user to the system. User profiles, which will be discussed in detail in Chapter 10, are also identified by their associated SIDs.

As aforementioned, most of the user SIDs are unique. However, there are so-called well-known SIDs, whose values are constant for all systems. For example, such SIDs include the following users and groups:

  • Everyone (S-1-1-0). The Everyone group will be discussed later in this chapter. For now, let us take notice of the fact that on computers running Windows Server 2003, the Everyone group includes Authenticated Users (S-1-5-11) and Guest (S-1-5-domain-501). On computers running earlier versions of the operating system, Everyone includes Authenticated Users and Guest plus Anonymous Logon (S-1-5-7). The identifier authority value for this SID is 1 (World Authority), while its subauthority value is 0 (Null RID).

  • Creator Owner (S-1-3-0). This is the Creator Owner user, serving as a placeholder in an inheritable Access Control Entry (ACE). When the ACE is inherited, the system replaces the SID for Creator Owner with the SID for the object's current owner. The identifier authority value for this SID is 3 (Creator Authority). It has only one subauthority value, 0 (Null RID).

Note 

A complete list of well-known SIDs in Windows 2000 is provided in the Microsoft Knowledge Base article Q243330 - "Well-Known Security Identifiers in Windows 2000". One of the significant security enhancements in Windows XP and Windows Server 2003 is the introduction of two new built-in accounts - NetworkService (S-1-5-20) and LocalService (S-1-5-19) that are suitable for use by many services. This was done to eliminate the common weakness of Windows 2000 and its predecessors, where most services run under the SYSTEM account (S-1-5-18) and can therefore do anything, whether they need to have such broad privileges or not or not. Thus, if an attacker can break the service, he or she might be able to run code under the security context of the operating system (OS), and fully own that system. By providing two built-in less privileged accounts, Microsoft has significantly improved this situation.

On all computers running Windows NT-based operating systems, including Windows 2000, Windows XP, and products of the Windows Server 2003 family, access to resources is controlled by Access Control Lists (ACLs) and SIDs. Like Windows NT/2000, Windows XP and Windows Server 2003 support Access Control Lists (ACL) for the registry. You can use ACL to protect registry keys. Actually, ACL represents the database supporting information on access rights to individual operating system objects (in our case, the objects are registry keys).

Note 

Notice that in Windows NT/2000, only Regedt32.exe provided access to the ACL for the registry keys. The Regedit.exe version supplied with Windows NT/2000 didn't provide this capability. As compared to Windows NT/2000, Windows XP and Windows Server 2003 also provide an improvement in this area. The Regedit.exe version included with this new release now integrates its traditional strong points with the functionality that was available earlier only in Regedt32.exe, including, of course, access to the ACLs and auditing registry key access. Detailed, step-by-step instructions on setting access rights to the registry keys were provided in Chapter 3. In this chapter, we'll concentrate on practical tips rather than on routine administrative operations.

First of all, we'll specify the registry keys to be secured in order to secure and protect the whole registry.

Standard Access Rights in Windows XP and Windows Server 2003

Standard security settings in Windows Server 2003 are defined by default access rights that are set for the following built-in local security groups (Fig. 9.10):

  • Account Operators (S-1-5-32-548). This is a built-in local group that exists only on domain controllers and, by default, has no members. Account Operators can create, modify, and delete accounts for users, groups, and computers in all containers and organizational units (OUs) of Active Directory, except the Builtin container and the Domain Controllers OU. Account Operators can modify neither the Administrators and Domain Admins groups, nor the accounts for members of those groups.

  • Administrators (S-1-5-32-544). Similar to Windows 2000, members of the Administrators group have full control of the local computer. They can create or delete user accounts and modify permissions for users and resources. Notice that by default, this group will contain two members - the local Administrator Account (S-1-5-domain-500) and System (S-1-5-18) - an identity that is used locally by the operating system and by services configured to log on as LocalSystem. SYSTEM is a hidden member of the Administrators group, which means that most tools do not list SYSTEM as a member of the group. However, the Administrators SID is present in System's access token. If you are performing an upgrade from an earlier Windows NT/2000 version, this group will include existing members of the Administrators group. If your computer joins a domain, this group will also include the members of the Domain Admins group (S-1-5-root_domain-518) to local Administrators. When a server is promoted to domain controller, the operating system adds the Enterprise Admins group (S-1-5-root_domain-519) as well. Notice that, if desired, you can remove either Domain Admins or Enterprise Admins groups from the local Administrators group. However, it is impossible to remove either SYSTEM or the local Administrator account (still, the local Administrator account can be renamed).

    Note 

    It is strongly recommended that you limit the number of users who belong to the Administrators group, no matter what system you are running - Windows NT/2000, Windows XP, or Windows Server 2003. The reason for this tip is straightforward - the greater the number of members in the Administrators group, the more vulnerable your system will be, because all these accounts (especially if they aren't properly protected with strong passwords) can potentially be used to gain unauthorized access to a computer.

  • Backup Operators (S-1-5-32-551). By default, this built-in local group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators can also log on to the computer and shut it down, but they cannot change security settings.

  • Guests (S-1-5-32-546). By default, this built-in local group has only one member - the local Guest account (S-1-5-domain-501) - an account for people who do not have individual accounts. Guest is a real account, which can be used to log on interactively (by default, however, it is disabled). It does not require a password, but can have one. When a server becomes a domain controller, the Domain Guests group (S-1-5-domain-514) becomes a member of the local Guests group. Default security settings in Windows XP and Windows Server 2003 deny access to the application and system event logs for the members of the Guests group. In all other aspects, members of the Guests group have the same access rights as members of the Users group. This allows occasional or one-time users to log on to a computer's built-in Guest account and be granted limited abilities.

  • Network Configuration Operators (S-1-5-32-556). Members of this group have limited administrative privileges that allow them to configure networking features, such as IP address assignment, without having other administrative rights on the computer. By default, the group has no members.

  • Power Users (S-1-5-32-547). This built-in local security group was first introduced with Windows 2000. Similar to Windows 2000, this group has fewer rights than Administrators; but at the same time, they have wider access rights and permissions than the Users group. In contrast to Users, Power Users have Read/Write permissions to other parts of the operating system in addition to their own user profiles. Power Users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power Users can also install most applications; create, manage, and delete local printers; create and delete file shares; and start (but not stop) services. After a fresh installation, this group has no members. On computers upgraded from Windows NT 4.0, it has one member, Interactive (S-1-5-4)-a group that includes all users who have logged on interactively, either locally or through a Remote Desktop connection. The Power Users group does not exist on domain controllers.

  • Pre-Windows 2000 Compatible Access (S-1-5-32-554). This built-in local group exists only on domain controllers running Windows 2000 or Windows Server 2003. By default, its members have read access to user and group objects in Active Directory. This group is intended to facilitate anonymous queries of Active Directory, which might be needed by some pre-Windows 2000 services, such as the Windows NT Remote Access Service. To enable anonymous access to Active Directory, add Everyone (S-1-1-0) and Anonymous Logon (S-1-5-7) to the Pre-Windows 2000 Compatible Access group. To disable anonymous access to Active Directory, do not add any members to the group.

  • Print Operators (S-1-5-32-550). This built-in local group exists only on domain controllers. By default, it has no members. Print Operators can manage printers and document queues.

  • Remote Desktop Users (S-1-5-32-555). Members of this built-in local group can log on to the computer through the Remote Desktop (also known as Terminal Services in Remote Administration mode). By default, the group has no members.

  • Replicator (S-1-5-32-552). This built-in local group only exists on domain controllers. In Windows NT domains, it is used by the File Replication service. Members of this group are allowed to replicate files across a domain. Although this group is present in Windows 2000 and later versions of the operating system, it is not used.

  • Server Operators (S-1-5-32-549). By default, this built-in local group is empty. Server Operators have no default rights on a member server. On a domain controller, Server Operators can log on interactively, access administrative shares, create and delete shared folders, start and stop services, back up and restore files, manage disks and volumes, and shut down the computer.

  • Users (S-1-5-32-545). By default, this built-in local group includes only Authenticated Users (S-1-5-11)-a group that includes all users and computers whose identities have been authenticated, and Interactive (S-1-5-4). Local user accounts are added to the Users group automatically when the accounts are created. When you install a new copy of the operating system on the NTFS partition, the standard settings of the security subsystem are configured so that the members of this group can't break the integrity of the OS and installed applications. Users can run applications, access local and network printers, shut down or lock the computer, and install applications that only they are allowed to use if the installation program of the application supports per-user installation. Members of the Users group can't modify registry settings that influence the whole configuration or change the operating system files. They have no rights to install applications that can be used by others (this is one of the precautions taken to protect against worms and Trojans), and they also can't install most legacy applications. Microsoft also recommends that you include all end users into the Users group to protect your system integrity.

click to expand
Figure 9.10: Windows Server 2003 built-in local security groups (the screenshot is taken on the domain controller)

Standard security settings are applied by Security Configuration Manager during the operating system installation, when the GUI setup starts. For this purpose, the Security Configuration Manager uses security templates located in the %SystemRoot%\inf folder.

Naturally, the template used for applying default security settings depends on the OS being installed and the computer's role in your network environment. When you perform a clean installation of workstations running Windows XP Professional, the %SystemRoot%\inf\defltwk.inf security template will be used (notice that upgrades from Windows 9x platforms are treated as clean installs). If you are upgrading to Windows XP from Windows NT/2000, Security Configuration Manager will use the %SystemRoot%\inf\DWUp.inf security template. When you perform a clean installation of Windows Server 2003 member server, default security settings are taken from the %SystemRoot%\inf\defltsw.inf security template, while for upgrades-from the %SystemRoot%\inf\dsup.inf template. For domain controllers, the %SystemRoot%\inf\defltdc.inf template is used. When you upgrade domain controllers from Windows NT 4.0, the Security Configuration Manager will use the %SystemRoot%\inf\dcup.inf template.

Note 

If you want to affect the security settings that are applied by default during installation, you can modify the above-mentioned security templates in the installation files folder.

As was already discussed, for standalone computers or computers participating in a workgroup, users belonging to the Administrators group have unlimited access to all file system and registry objects. Users and Power Users have a more restricted set of access rights.

Note 

Windows XP and Windows Server 2003 include a new root ACL, which is also implemented by Format and Convert commands. In addition to previous releases, the Security Configuration Manager now secures the root directory during setup, if the current root security descriptor grants the Everyone group Full Control permission. This provides increased security for non-Windows directories. The new root ACL is as follows:

  • Administrators, System: Full Control (Container Inherit, Object Inherit)

  • Creator Owner: Full Control (Container Inherit, Object Inherit, Inherit Only)

  • Everyone: Read\Execute (No Inheritance)

  • Users: Read\Execute (Container Inherit, Object Inherit)

  • Users: Create Directory (Container Inherit)

  • Users: Add File (Container Inherit, Inherit Only)

Power Users can write new files into directories (the list is provided below), but can't modify files that were written to these directories during installation. All members of the Power Users group inherit Modify access to all the files created in these directories by a member of their group.

      %SystemRoot%            %SystemRoot%\inf      %SystemRoot%\Config     %SystemRoot%\media      %SystemRoot%\cursors    %SystemRoot%\system      %SystemRoot%\fonts      %SystemDir%      %SystemRoot%\help       %SystemDir%\RAS 

Maintaining Proper System File and Registry Permissions across All Windows Server 2003 Computers within a Domain

Although standard system file and registry permissions for Windows Server 2003 seem fairly secure, a wise administrator doesn't assume that the default permissions on system folders, files, and registry keys are always going to be the best possible settings. For example, the installation of new software always adds folders and files, and sometimes services, for which you'll also need to consider permissions set automatically, as well as changes to the inherited permissions.

Note 

When a Windows Server 2003 computer is promoted to a domain controller, an additional set of permissions is applied.

If you need to return to the settings applied at install time after having changed the default permissions, proceed as follows:

  1. From the Start menu, select Run, and type mmc into the Open field. When the MMC console window opens, select the Add/Remove snap-in command from the File menu. The Add/Remove Snap-in window opened at the Standalone tab will open. Click the Add button, and select the Security Configuration and Analysis option from the list of available snap-ins (Fig. 9.11). Click Add, then Close, then OK.

    click to expand
    Figure 9.11: Adding the Security Configuration and Analysis standalone snap-in

  2. Right-click the Security Configuration and Analysis item and select the Open Database command from the context menu (Fig. 9.12). The Open Database dialog will appear (Fig. 9.13), where you will be prompted to select a database, and then click Open. By default, security templates are stored at %SystemRoot%\security\templates. Navigate to this folder and select the required template. To reapply the default server security settings, select the setup security.inf file. To reapply the settings applied when a server is promoted to a domain controller, use the DC security.inf security template. If you only want to reapply the system drive root security settings, select the rootsec.inf security template, which implements the above-mentioned new Windows Server 2003 root ACL. Notice that this template can also be used to apply similar settings to the root of other disks.

    click to expand
    Figure 9.12: Opening the Security Configuration Database

    click to expand
    Figure 9.13: The Open database dialog

Note 

You must realize that after you reapply the default permissions using these security templates, any configuration settings that you may have applied either manually or using Group Policy will be overwritten by the default settings. Therefore, if you need to preserve your changes, create a copy of the default template(s), introduce officially approved changes into it, and maintain these copies as well as default security templates. Proceeding in such a way, you'll have a backup of your current security settings as well as the original default template.

Using Group Policy to Maintain File and Registry Permission Settings

Similar to Group Policy in Windows 2000, Group Policy in Windows Server 2003 allows administrators to centrally manage, configure, and push security policy and other administrative settings to an entire site, domain, or organizational unit. Policies, officially named Group Policy Objects (GPOs), are linked to these containers.

Note 

Most policies are implemented at the domain or OU level, since it is not practical to implement site policies. In addition to domain policies, a local Group Policy is configured and can be adjusted on individual workstations or servers. More detailed information on Group Policies will be provided in Chapters 10 and 11.

File and registry permission settings can only be configured within the Computer Settings portion of the Group Policy (Fig. 9.14). To add registry path to the policy, expand the console tree as shown in this screenshot, right-click the Registry item, and select the Add Key command from the context menu. After you add new registry keys to the policy, the Discretionary Access Control Lists (DACLs) applied to them propagate to the objects on the computer when the policy is applied.

click to expand
Figure 9.14: Configuring registry permission settings within the Computer Settings portion of the Group Policy

Using Secedit to Maintain File and Registry Permission Settings

Besides Group Policy, you can use the Secedit.exe command-line tool to maintain file and registry permission settings. The Secedit.exe is the command-line version of the Security and Analysis Configuration tool.

The secedit.exe tool uses the following command-line syntax:

    secedit  [/configure  |  /analyze  |  /import  |  /export  |  /validate  |    /generaterollback]

where:

Secedit /configure-this command configures a system with security settings stored in a database. The syntax used by this command option is as follows:

    secedit    /configure    /db    db_filename    [/cfg    cfg_filename]    [/overwrite][/areas area1 area2 ...]  [/log log_filename] [/quiet]

  • /db db_filename-specifies the db_filename database used to perform the security configuration.

  • /cfg cfg_filename-specifies the cfg_filename security template that needs to be imported into the database prior to configuring the computer. Security templates are created using the Security Templates MMC snap-in.

  • /overwrite-this option instructs the secedit tool to empty the database before importing the specified security template. If this parameter is missing, the settings in the security template are accumulated into the database. If this parameter is not specified and there are conflicting settings in the database and the template being imported, the template settings will take priority.

  • /areas-specifies the security areas to be applied to the system. If this parameter is omitted, all security settings defined in the database are applied to the system. To configure multiple areas, separate each area by a space. The following security areas are supported:

    • SECURITYPOLICY-Account Policies, Audit Policies, Event Log Settings, and Security Options.

    • GROUP_MGMT-Restricted Group settings

    • USER_RIGHTS-User Rights Assignment

    • REGKEYS-Registry Permissions

    • FILESTORE-File System permissions

    • SERVICES-System Service settings

  • /log log_filename-specifies a file in which to log the status of the configuration process (log_filename). If this parameter is missing, the configuration-processing information is logged in the Scesrv.log file, which is located in the %windir%\security\logs directory.

  • /quiet-specifies that the configuration process should take place without prompting the user for any confirmation.

Secedit /analyze-this option analyzes current systems settings against baseline settings that are stored in a database. The analysis results are stored in a separate area of the database and can be viewed in the Security Configuration and Analysis snap-in. The syntax for this command is as follows:

    secedit  /analyze  /db  db_filename  [/cfg  cfg_filename  ]  [/overwrite]    [/log  log_filename]  [/quiet]

  • /db db_filename-specifies the database used to perform the analysis.

  • /cfg cfg_filename-specifies a security template to import into the database prior to performing the analysis. Security templates are created using the Security Templates snap-in.

  • /log log_filename-specifies a file in which to log the status of the configuration process. If not specified, the configuration-processing information is logged in the Scesrv.log file, which is located in the s%windir%\security\logs directory.

  • /quiet-specifies that the analysis process should take place without prompting the user for any confirmation.

Secedit /import-allows you to import a security template into a database so that the settings specified in the template can be applied to a system or analyzed against a system. This command uses the following syntax:

    secedit    /import       /db    db_filename    /cfg    cfg_filename    [/overwrite][/areas area1 area2 ...] [/log log_filename] [/quiet]

  • /db db_filename-specifies the database that the security template settings will be imported into.

  • /cfg cfg_filename-specifies a security template to import into the database. Security templates are created using the Security Templates snap-in.

  • /overwrite-specifies that the database should be emptied prior to importing the security template. If this parameter is not specified, the settings in the security template are accumulated into the database. If this parameter is not specified and there are conflicting settings in the database and the template being imported, the template settings win.

  • /areas-specifies the security areas to export. If this parameter is not specified, all security settings defined in the database are exported. To export specific areas, separate each area by a space. The following security areas are exported:

    • SECURITYPOLICY-Account Policies, Audit Policies, Event Log Settings, and Security Options.

    • GROUP_MGMT-Restricted Group settings

    • USER_RIGHTS-User Rights Assignment

    • REGKEYS-Registry Permissions

    • FILESTORE-File System permissions

    • SERVICES-System Service settings

  • /log log_filename-specifies a file in which to log the status of the import process. If not specified, the import-processing information is logged in the scesrv.log file which is located in the %windir%\security\logs directory.

  • /quiet-specifies that the import process should take place without prompting the user for any confirmation.

Secedit /export-allows you to export security settings stored in the database. The syntax of this command is:

    secedit /export /db db_filename [tablename] /cfg cfg_filename [/areas    area1 area2...] [/log log_filename]

  • /db db_filename-specifies the database used to perform the security configuration.

  • /cfg cfg_filename-specifies a security template to export the database contents to.

    • tablename-specifies the table to export data from. If no argument is specified, the configuration table data is exported.

  • /areas-specifies the security areas to export. If this parameter is not specified, all security settings defined in the database are exported. To export specific areas, separate each area by a space. The following security areas are exported:

    • SECURITYPOLICY-Account Policies, Audit Policies, Event Log Settings and Security Options.

    • GROUP_MGMT-Restricted Group settings

    • USER_RIGHTS-User Rights Assignment

    • REGKEYS-Registry Permissions

    • FILESTORE-File System permissions

    • SERVICES-System Service settings

  • /log log_filename-specifies a file in which to log the status of the export process. If not specified, the export-processing information is logged in the scesrv.log file which is located in the %windir%\security\logs directory.

Secedit /generaterollback-allows you to generate a rollback template with respect to a configuration template. The syntax of this command is:

    secedit /generaterollback /cfg cfg_filename /rbk filename [/log log_filename]    [/quiet]

  • /db db_filename-specifies the database used to perform the rollback.

  • /cfg cfg_filename-specifies a security template with respect to which a rollback template is generated. Security templates are created using the Security Templates snap-in.

  • /rbkfilename-specifies a security template into which the rollback information is written. Security templates are created using the Security Templates snap-in.

  • /log log_filename-specifies a file in which to log the status of the rollback process. If not specified, the rollback-processing information is logged in the Scesrv.log file, which is located in the %windir%\security\logs directory.

  • /quiet-specifies that the rollback process should take place without prompting the user for any confirmation.

In addition, secedit.exe can be used to apply a single node from a security template. Thus, to reapply your preferred file permissions, you can use a single command-line command. To reapply your preferred registry permissions, you can use another line. Put both commands in a batch file or write a simple script, and you can reapply both file permissions and registry permissions across multiple servers. And you can use the scheduling service (schtasks.exe) to periodically refresh these settings without any replication burden. After testing the statements, you can schedule a periodic refresh by putting both commands (or the combination line) in a batch file. Test the batch file. If successful, use the task scheduler or schtasks.exe to schedule the refresh. Table 9.1 provides an explanation of the most useful schtasks.exe command-line switches; additional switches are available.

Table 9.1: The Switches for schtasks.exe

Switch

Description


/create

Create a task

/tn

The name of the new task

/tr

The name of the batch file or command to run

/sc

When to schedule the repetitive event (once, every n times a month, every month, every n times a day, at this time every day, and so on)

/d

Which day of the week; Monday is the default, so I could have left out this switch in the example; /d * runs the process every day

/ru

Under whose authority; if a user account name is entered here (use the domainname\username format), the password is entered using the /rp switch; to use a local computer account use the \machine switch and \u and \p parameters (when the SYSTEM account is used, no password is entered)

The Most Important Registry Keys that Need Protection

Microsoft officially recommends that system administrators restrict user access to certain subkeys under HKEY_LOCAL_MACHINE\SOFTWARE. The purpose of this restriction is to prevent unauthorized access to the software settings.

Note 

Microsoft officially recommends that system administrators restrict user access to the following registry keys:

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion.

For all earlier versions of Windows NT-based systems, including Windows 2000, it is recommended that the user restrict the Everyone group (note that in Windows XP and Windows Server 2003 the Everyone group has been restricted by default). For the Everyone group, it's sufficient to have the Query Value, Enumerate Subkeys, Notify, and Read Control rights to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key and the following subkeys under this key: AeDebug, Compatibility, Drivers, Embedding, Font Drivers, FontCache, FontMapper, Fonts, FontSubstitutes, GRE_Initialize, MCI, MCI Extensions, Ports (and all its subkeys), Type 1 Installer, Windows 3.1 MigrationStatus (and all its subkeys), WOW (and all its subkeys).

The same set of access rights (Query Value, Enumerate Subkeys, Notify, and Read Control) needs to be assigned to the Everyone group for the Uninstall, Run, and RunOnce subkeys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion.

Microsoft also recommends that you restrict user access to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib key that stores the data, which governs system performance. In Windows NT 4.0, the Everyone group by default has Read access to this key (it's recommended that you delete this group from the Perflib ACL). As shown in Fig. 9.15, in Windows Server 2003, the Everyone group by default has no access to this key.

click to expand
Figure 9.15: Restricting access to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib registry key

The Everyone group has restricted access rights (only Query Value, Enumerate Subkeys, Notify, and Read Control) to other registry keys, including HKEY_CLASSES_ROOT root key and all its subkeys, and for the HKEY_USERS\.DEFAULT key. By protecting these keys, you protect important system settings from changes (for example, this will prevent users from changing the filename extension associations or specifying new security settings for Internet Explorer).

Furthermore, it's necessary to restrict the Everyone group access to keys such as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UPS. The Everyone group only needs the following rights to these keys: Query Value, Enumerate Subkeys, Notify and Read Control. By setting these restrictions, you'll prevent unauthorized access to shared system resources and to using the ImagePath setting under the UPS key for starting undesirable software. Only the operating system (System) and members of the Administrators group need Full Control access to these keys.

Finally, it is necessary to provide a tip, universal for all Windows NT-based systems. Pay close attention to the Run, RunOnce, and RunOnceEx registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion. For example, the system runs all the programs listed under the RunOnceEx key only once, and then deletes the settings specifying the starting parameters for these programs. It's easy to see that these registry settings may allow users to run undesirable software on the local computer. Thus, Full Control access to this key should only be provided to the operating system (System) and members of the Administrators group. The list of registry keys, which are used most often for installing worms, viruses, and Trojans, is provided below:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce

  • HKEY_USERS\DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices

  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx

Therefore, if you suspect that your computer is infected, these registry keys must be checked first. Furthermore, the list of such keys is constantly being supplemented. Since recently, the following keys have been included into this list:

  • HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Controls Folder

  • HKLM\Software\Microsoft\Windows\CurrentVersion\DeleteFiles

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Extensions

  • HKLM\Software\Microsoft\Windows\CurrentVersion\ExtShellViews

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings

  • HKLM\Software\Microsoft\Windows\CurrentVersion\ModuleUsage

  • HKLM\Software\Microsoft\Windows\CurrentVersion\RenameFiles

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Setup

  • HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Shell Extensions

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Compatibility

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\drivers.desc

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers32\0

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Embedding

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\MCI

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\MCI Extensions

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Ports

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\WOW

Note 

It's necessary to mention one more registry key, which is also very important in terms of security. When you work with the Remote Access Service (RAS), the system sometimes displays dialogs prompting you to enter a login name and password. These dialogs often contain checkboxes, which allow you to save the password (for example, Save This Password or Remember This Password). Although this feature is very convenient for end users, it can possibly be very dangerous, because the passwords are stored in such a way that they can be easily retrieved by the system (and, for that matter, by anyone else). This is especially important for those of you working with laptops and other portable computers, because if your machine is lost or stolen, the person who finds (or steals) it will have access to all your networks.

The easiest way to protect yourself against this risk is to disable the feature for saving RAS passwords on RAS clients. Open the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters key and add the REG_DWORD setting named DisableSavePassword. Now the system won't prompt you to save your RAS password.



Windows Server 2003 Registry
Unicode Explained
ISBN: 1931769214
EAN: 2147483647
Year: 2005
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net