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

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.

N
ote 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.

N
ote 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.

N
ote 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.

N
ote 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).

N
ote 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).

N
ote
N
otice that in Windows NT/2000, only Regedt32.exe provided access
t
o 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).

N
ote 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
N
T/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.