Tài liệu Methods of Restricting Registry Access phần 2 pptx

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 an

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 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