Protecting the Registry against Unauthorized Remote Access

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

Thêm vào BST

Báo xấu

111
lượt xem 7
download

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

Protecting the Registry against Unauthorized Remote Access Remote access to the registry is very convenient when the system administrator needs to support end users from his own workplace.

Chủ đề:

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

Lưu

Nội dung Text: Protecting the Registry against Unauthorized Remote Access

Protecting the Registry against Unauthorized Remote Access Remote access to the registry is very convenient when the system administrator needs to support end users from his own workplace. Furthermore, some services must also have access to the registry in order to function correctly. For example, on a system that runs directory replication, the Directory Replicator service requires access to the remote 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 remote access to the registry is made possible with the following factors: If there isn't a \winreg subkey 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 within the limits defined by its ACL. If there's a \Winreg subkey, then the Access Control List defined for this key will specify who can access the registry remotely. (But remember that Back Orifice 2000, or BO2K, allows remote access 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 the Access Control List for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\W inreg This means that to protect your system from unauthorized remote 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 the remote user's read or write access (explicitly or through group membership), the user will be able to connect to the registry 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 remote registry 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. Note 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, remote access to the registry 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 the registry 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 the registry over the network. Administrators have Full Control access. o On Windows Server 2003 systems, network access to the registry 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. Note Notice 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 remote registry 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 the access list on the Winreg subkey. Alternately, you can configure Windows to bypass the access 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 Note 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 remote access 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 the registry to which you want to allow user access, provided that no explicit restrictions exist for that location.