Methods of Restricting Registry Access phần 2

Chia sẻ: Nghia Tuan | Ngày: | Loại File: PDF | Số trang:9

Thêm vào BST

Báo xấu

73
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

The New Path Rule window 2. 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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Methods of Restricting Registry Access phần 2

1. Figure 9.7: The New Path Rule window 2. 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. 3. 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.
Figure 9.8: The New Hash Rule window 4. 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. 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.