Controlling remote registry access
Hackers and unauthorized users can attempt to access a
system’s registry remotely just like you do. If you want to be sure
they are kept out of the registry, you can prevent remote registry
access. One way that remote access to a system’s registry can be controlled
is through the registry key
HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg. If
you want to limit remote access to the registry, you can start by
changing the permissions on this key.
If this key exists, then the following occurs:
-
Windows Server 2012 uses the permissions on the key to
determine who can access the registry remotely, and by default
any authenticated user can do so. In fact, authenticated users
have Query Value, Enumerate Subkeys, Notify, and Read Control
permissions on this key. -
Windows Server 2012 then uses the permissions on the
keys to determine access to individual
keys.
If this key doesn’t exist, Windows Server 2012 allows all
users to access the registry remotely and uses the permissions on
the keys only to determine which keys can be accessed.
Windows Vista and later Windows versions disable remote access
to all registry paths by default. As a result, the only registry
paths remotely accessible are those explicitly permitted as part of
the default configuration or by an administrator. In Local Security
Policy, you can use Security Options to enable or disable remote registry access. With Windows Vista and later
Windows versions, the following additional security settings are
provided for this purpose:
These security settings determine which registry paths and
subpaths can be accessed over the network, regardless of the users
or groups listed in the access control list (ACL) of the
Winreg registry key. A number of default paths
are set, and you should not modify these default paths without
carefully considering the damage that changing this setting might
cause.
You can follow these steps to access and modify these settings
in the Local Security Settings console:
-
Open Local Security Policy. If you enabled Show
Administrative Tools as a Start setting, you’ll see a related
tile on the Start screen. Another way to do this is by pressing
the Windows key, typing secpol.msc into the Apps Search box, and
then pressing Enter. -
Expand the Local Policies node in the left pane and then
select the Security Options node. -
In the main pane, you should now see a list of policy
settings. Scroll down through the list of security settings. As
appropriate, double-tap or double-click Network Access: Remotely Accessible Registry Paths or Network Access: Remotely
Accessible Registry Paths And Subpaths. -
On the Local Policy Setting tab of the Properties dialog
box, you’ll see a list of remotely accessible registry paths or a list of remotely accessible
registry paths and subpaths, depending on which security setting
you are working with. You can now add or remove paths or
subpaths as necessary. Note that the default settings are listed
on the Explain tab.
Note
Windows Server 2012 has an actual service called the
Remote Registry service. This service does, in fact,
control remote access to the registry. You want to disable
this service only if you are trying to protect isolated systems
from unauthorized access, such as when the system is in a
perimeter network and is accessible from the Internet. If you
disable the Remote Registry service before starting the Routing
and Remote Access service, you cannot view or change the Routing
and Remote Access configuration. Routing and Remote Access reads
and writes configuration information to the registry, and any
action that requires access to configuration information could
cause Routing and Remote Access to stop functioning. To resolve
this, stop the Routing and Remote Access service, start the Remote
Registry service, and then restart the Routing and Remote Access
service.
Access to the registry can be audited, as can access to files
and other areas of the operating system. Auditing allows you to
track which users access the registry and what they’re doing. All
the permissions listed previously in Table 3 can be audited.
However, you usually limit what you audit to only the essentials to
reduce the amount of data that is written to the security logs and
to reduce the resource burden on the affected server.
Before you can enable auditing of the registry, you must
enable the auditing function on the system you are working with. You
can do this either through the server’s local policy or through the
appropriate Group Policy Object. The policy that controls auditing
is Computer Configuration\Windows Settings\Security Settings\Local
Policies\Audit Policy.
After auditing is enabled for a system, you can configure
how you want auditing to work for the registry. This means configuring auditing for each key
you want to track. Thanks to inheritance, this doesn’t mean you have
to go through every key in the registry and enable auditing for it. Instead, you can
select a root key or any subkey to designate the start of the branch
for which you want to track access and then ensure the auditing settings are
inherited for all subkeys below it. (This is the default
setting.)
Say, for example, you want to audit access to HKLM\SAM and its
subkeys. To do this, you follow these steps:
-
After you locate the key in Registry Editor, press and hold or right-click it,
and select Permissions, or select the key, and then choose
Permissions on the Edit menu. This displays the Permissions For
SAM dialog box. -
In the Permissions For SAM dialog box, tap or click the
Advanced button. -
In the Advanced Security Settings dialog box, tap or click
the Auditing tab. -
Tap or click Add to display the Auditing Entry For dialog
box. Click Select A Principal to display the Select User,
Computer, Service Account, Or Group dialog box. -
Type the name of a user or a group account. Be sure to
reference the user account name rather than the user’s full
name. Only one name can be entered at a time. -
Tap or click Check Names. If a single match is found for
each entry, the dialog box is automatically updated and the
entry is underlined. Otherwise, you’ll see an additional dialog
box. If no matches are found, you’ve either entered the name
incorrectly or you’re working with an incorrect location. Modify
the name in the Name Not Found dialog box and try again, or tap
or click Locations to select a new location. When multiple
matches are found, in the Multiple Names Found dialog box,
select the name or names you want to use and then tap or click
OK. -
Tap or click OK. The user or group is added as the
Principal, and the Auditing Entry For dialog box is updated to
show this. Only basic permissions are listed by default. Click
Show Advanced Permissions to display the special permissions, as
shown in Figure 14. -
Use the Applies To list to specify how the auditing entry
is to be applied. The options include the following:
-
This Key Only The
auditing entries apply only to the currently selected
key. -
This Key And Subkeys
The auditing entries apply to this key and any subkeys of
this key. -
Subkeys Only The
auditing entries apply to any subkeys of this
key but not to the key itself.
-
Use the Type list to specify whether you are configuring
auditing for successful access, failed access, or both, and then specify which actions
should be audited. The events you can audit are the same as the
special permissions listed in Table 3. -
Repeat steps 4–9 to configure auditing for other users or
groups. -
The auditing entries are applied to subkeys by default
through inheritance. If you want to replace the auditing entries
on all child objects of this key with this key’s auditing
entries, select Replace All Child Object Auditing Entries With
Inheritable Auditing Entries From This Object. -
Tap or click OK twice.
|
