Additional steps you can take to patch NT's security holes
When I wrote about Windows NT-related security last July (see "NT Server Security Checklist"), I discussed several measures you can take to improve the security of your NT systems and network.
This month, I'll tell you about additional NT-related security holes and how you can prevent hackers from exploiting these weaknesses. I'll describe more post-Service Pack 3 (SP3) security hotfixes and tell you what you need to know to evaluate and implement them. Finally, I'll update you on late-breaking developments related to NT security.
Restricting Registry Access
One of SP3's most important lockdown features automatically prevents anonymous users from accessing NT's Registry. Users who modify the Registry can effectively defeat any in-place restrictions, so protecting the Registry is very important. Access to the Registry can also lead to tampering with system authentication behavior and user-account information. To protect yourself from such attacks and to maintain a secure NT system, you must install SP3.
You might want to go a step further and restrict Registry access to authenticated users on your network. Giving Registry access to unauthorized network users who have valid logons is just as risky as providing anonymous users with access. To help secure the Registry, SP3 lets you create a special Registry subkey with an Access Control List (ACL) that effectively defines which users have what types of remote access to the local Registry. You create this special subkey (note that this entry is a key, not a value), winreg, under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers Registry key. When you create this subkey, you can set permissions on it using regedt32's Security\Permissions option, as Screen 1, page 136 shows. In most cases, you want to restrict the remote Registry access to include only network administrators.
SMB: Sign on the Dotted Line
Another SP3 security-related feature that administrators will want to consider is Server Message Block (SMB) signing. SMB signing helps foil man-in-the-middle attacks on SMB sessions between NT servers and clients. In such attacks, a rogue machine intercepts client-to-server SMB sessions and tricks the client into believing the rogue machine is an SMB server. This intercept lets the hacker access the client's response to the server's authentication challenge during the SMB negotiation process. When you use SMB signing to prevent these attacks, the client and server must digitally sign all SMB packets, which lets these machines perform mutual authentication. You enable SMB signing in the Registry on NT servers and workstations, and you can require SMB signing for all SMB sessions for a particular machine.
Two Registry values on the server relate to SMB signing. The first value, EnableSecuritySignature, is in HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Par-ameters. You can set this value, which is of type REG_DWORD, to 0 (disabled) or 1 (enabled); this value defaults to 0. You must set this value to 1 to turn on SMB signing on the server.
The second value, RequireSecuritySignature, is in the same Registry key as the previous value. You can set the RequireSecuritySignature value, which is of type REG_DWORD, to 0 (disabled) or 1 (enabled); this value defaults to 0. You must set this value to 1 to require SMB signing for the clients that connect to the server.
On the client side, you enable or disable SMB signing by adding the same Registry values to the client's HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters Registry key. These values affect workstation (SMB Redirector) behavior.
The only other noteworthy difference between SMB signing on servers vs. workstations is that SP3 enables the EnableSecuritySignature value on the workstation by default. However, this default doesn't mean every NT client running SP3 automatically uses SMB signing; it takes two to tango, and you must enable this feature on both the server and workstation for it to be effective.
Does SMB signing have any drawbacks? Definitely. The biggest problem is that SMB signing isn't effective unless you enable it on every NT server and workstation on the network. In addition, NT is the only version of Windows that supports SMB signing. As a result, you probably want to consider SMB signing only in a pure NT environment in which you can mandate this feature on both servers and workstations. If even one non-NT client circumvents SMB signing, you face a security hole that can defeat the purpose of enabling this feature in the first place. The other problem with SMB signing relates to performance: Be aware that encrypting and decrypting signed SMB packets exacts approximately a 10 percent performance penalty over regular SMB sessions.