Protecting theRegistryagainstUnauthorizedRemoteAccess
Remote access to theregistry is very convenient when the system administrator needs to
support end users from his own workplace. Furthermore, some services must also have
access to theregistry in order to function correctly. For example, on a system that runs
directory replication, the Directory Replicator service requires access to theremote
registry. The Spooler service also requires this access, when it is connecting to a printer
over the network.
However, in some cases, this capability may be potentially dangerous, that's why remote
access must be authorized.
When you attempt to connect the registry of the remote Windows NT-based system, the
Server service will check if there's an
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Win
reg key in that registry (Fig. 9.16
). Getting remoteaccess to theregistry is made possible
with the following factors:
If there isn't a \winreg subkey key in theregistry that you want to protect, then any
remote user will have access to the registry. This user will be able to manipulate
your registry within the limits defined by its ACL.
If there's a \Winreg subkey, then theAccess Control List defined for this key will
specify who can accesstheregistry remotely. (But remember that Back Orifice
2000, or BO2K, allows remoteaccess to the registry, despite the presence of a
\winreg subkey and its access permissions. However, someone must install its
server part on your system).
Figure 9.16: Configuring theAccess Control List for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\W
inreg
This means that to protect your system from unauthorizedremote access, you need to
configure the ACL for the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Win
reg. If the ACL for \Winreg key provides theremote user's read or write access (explicitly
or through group membership), the user will be able to connect to theregistry remotely.
After establishing the connection, the user rights will be restricted only by his or her
access rights to individual keys. Thus, if the user has Read access to the Winreg key, this
will provide him or her access to other registry keys (if this is allowed by their ACLs).
Thus, to manage remoteregistry access, proceed as follows:
1. If your registry does not contain the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServe
rs\Winreg key, create it by following the procedure described in step 2.
N
ote You only need to create the \Winreg key on those computers running
Windows NT 4.0 Workstation. Windows NT 4.0 Server, Windows 2000
Professional, Windows 2000 Server, Windows XP, and Windows Server
2003 systems contain this key by default (unless someone has deleted it), and
system administrators have Full Control access to this key.
2. Start Registry Editor (if you are running Windows 2000 or earlier, use
Regedt32.exe), and then locate the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control registry key
and create the SecurePipeServers subkey. Under this key, create the Winreg
subkey. Next, under the Winreg subkey, create a new value entry of the REG_SZ
data type, and name it Registry Server.
3. Edit the current permissions for the Winreg subkey or add users or groups to
whom you want to grant access. The default permissions on this key are different
for different operating systems:
o On Windows 2000 systems, remoteaccess to theregistry is provided to the
members of the Administrators group and to the SYSTEM built-in account.
o On a Windows XP Professional, network access to theregistry is provided
to the members of the Administrators and Backup Operators built-in
groups, and to the Local Service built-in account. Administrators have Full
Control access, and Backup Operators have Read access. On a Windows
XP Home Edition, by default only the Administrators group can gain access
to theregistry over the network. Administrators have Full Control access.
o On Windows Server 2003 systems, network access to theregistry is
provided to the Administrators and Backup Operators built-in groups, and
to the Local Service built-in account. Administrators have Full Control
access, and Backup Operators have Read access.
N
ote
N
otice the usage of the Local Service built-in account on Windows
XP and Windows Server 2003 systems in contrast to the usage of the
SYSTEM built-in account on Windows 2000. As was already
mentioned, the Local Service account is less privileged than the
SYSTEM built-in account.
4. If you have restricted remoteregistry access, and therefore, some services that
require it to function correctly begin to experience problems, you can either add
the account name of the service to theaccess list on the Winreg subkey.
Alternately, you can configure Windows to bypass theaccess restriction to certain
keys. To do so, you will need to list the keys for those services in the Machine
(Fig. 9.17
) or Users values under the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServe
rs\Winreg\AllowedPaths key.
Figure 9.17: The Machine value of the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServe
rs\Winreg\AllowedPaths registry key
N
ote The Users value does not exist by default. You might have to create the value.
Under the Machine value (REG_MULTI_SZ data type), you can add any valid path to a
location within the registry to the default value which you want to allow remoteaccess to,
provided that no explicit access restriction exists for that location. For the Users value
(REG_MULTI_SZ data type), use the following information to add keys for which you
want to bypass restrictions—a valid path to a location in theregistry to which you want to
allow user access, provided that no explicit restrictions exist for that location.
.
Protecting the Registry against Unauthorized Remote Access
Remote access to the registry is very convenient when the system administrator. key in the registry that you want to protect, then any
remote user will have access to the registry. This user will be able to manipulate
your registry