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.
The Right Version of SP3
If you are in the US or Canada, verify that you are running the strong 128-bit encryption (domestic-grade) version of SP3 rather than the weak (export-grade) 40-bit version. When you install the export-grade version on top of a 128-bit domestic-grade NT installation, the software presents you with a message, which Screen 2 shows, informing you of the security downgrade. If you download the service pack from Microsoft's FTP server (http://support.microsoft.com/support/ntserver/content/service packs/where.asp), you do not have the 128-bit version of SP3. To obtain this version, you must go to a special URL (http://mssecure.www.conxion.com/cgi-bin/ntitar.pl) that verifies your physical location according to your machine's IP address. Be aware that the IP address of your system or proxy server must have a reverse DNS lookup record associated with it. The Web site needs this record so it can verify your US or Canadian location according to the information about your domain name in the InterNIC's WHOIS database. If you don't have a reverse DNS entry, you can't complete the download.
Here's a tip: When you download the strong-encryption version of SP3, the default filename is nph-ntfinal.exe. If you rename this file to ms128.exe before the download begins or after it completes, you can use the command
MS128 /x
to extract only the SP3 files without installing them (i.e., to unpack the self-extracting archive file for faster installation).
Disabling Cached Logons
One of NT's default behaviors that is a concern in high-security environments is the software's automatic caching of user logon credentials. As a result of using this logon caching, NT lets a user log on to the system even when no domain controller is available to authenticate the logon. Although this ability is convenient for the user, it leaves a security hole for the systems administrator. To disable this behavior in NT, you need to modify the Registry (for information about how to disable automatic caching, see R. Franklin Smith, "Protect Your Passwords," page 127).
The fact that Microsoft didn't include a Registry entry to disable cached logons as one of the default policies for NT computers in System Policy Editor's (SPE's) .adm template files is unfortunate. Microsoft could have easily added an NT template that locks out users when a domain controller is unavailable, especially considering that the Windows 95 policy template file comes with a similar policy. Fortunately, you can easily add a policy to the default winnt.adm file or a new .adm file that automatically sets this Registry value (and any other Registry entries you want). You can then add this new .adm file entry into your organization's ntconfig.pol system policy file for automatic assignment to all relevant NT systems (for information about using SPE and policy files, see my article, "Further Explorations of the NT System Policy Editor," April 1997 and Darren Mar-Elia, "Windows NT System Policies," July 1998).
To add a policy for disabling cached logons, locate the following section in the existing winnt.adm file or create a new policy template (.adm) file with a similar CATEGORY name:
CATEGORY !!System
CATEGORY !!Login_Policies
Add the policy information you see in Listing 1. When you create this new policy, note that capitalization and correct spelling are very important.
After you implement this addition, you have a new policy, as Screen 3 shows, in your system policies dialog box. When you select the check box next to this policy, you are setting the CachedLogonsCount Registry value to the default of 10 cached logons. When you clear this check box, you are disabling logon caching. You must also add a label for the policy and, alternately, additional Help text related to the policy. To create the label and Help text, add the information you see in Listing 2 under the \[strings\] section at the bottom of the policy file (for everything to work, you must label this entry with the same name as the policy). Remember that modifying the system to restrict cached logons renders a machine completely unable to log on in the event that no domain controller is available.
Protecting LSA's Secrets
One of the more recent post-SP3 hotfixes relates to the Local Security Authority (LSA) service. As with other NT hotfixes, Microsoft released the LSA-fix hotfix and then upgraded it to LSA2-fix to correct additional problems. If you install this fix, make sure you get the newer LSA2-fix. So, if you previously downloaded the hotfix and archived it (as I frequently do with Microsoft patches), you might not be aware of the update.
LSA2-fix corrects several security-related LSA behaviors, including preventing a user with administrative access from dumping sensitive security information from the LSA. This information is collectively known as LSA Secrets. These secrets include logon passwords for services that log on using nonsystem user accounts. (For more information about this problem, see Microsoft Support Online article Q184017, "Administrators Can Display Contents of Service Accounts Passwords," at http://support.microsoft.com/support/kb/articles/q184/0/17.asp.) At first glance, this dumping doesn't appear to be much of a security hole because administrators are ultimately trusted users who have access to this information anyway. However, the ability to dump the LSA Secrets might cause concern in some environments. At the very least, this ability makes hackers' work easier in the event they compromise an administrative account in the domain.
You can download the LSA2-fix from Microsoft's FTP server (ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/lsa2-fix). To enable this hotfix, you simply install it; this fix doesn't require any additional Registry modifications. However, be aware that early users of this hotfix reported some unwanted or unexpected side effects after installing it. One such side effect is the disabling of cached logons. The LSA2-fix exhibits behavior similar to enabling the CachedLogonsCount Registry value. This behavior might or might not be a problem, depending on your environment. However, if you have laptop users running NT and you enable this hotfix, they might be unpleasantly surprised when they attempt to log on using their domain user account and password. Forewarned, as they say, is forearmed.
| TABLE 1: TCP and UDP Port Descriptions | |
|---|---|
| Port Number | Description |
| Port 135 | Remote procedure call (RPC)/Location Service |
| Port 137 | NetBIOS Name Service |
| Port 138 | NetBIOS Datagram Service |
| Port 139 | NetBIOS Session Service |
By disabling the ability of Internet-based hosts to access these services, you'll make compromising your network significantly more difficult for hackers. Although port-filtering provides some protection, you might want to use a sophisticated firewall solution or proxy server (for information about protecting your network with Microsoft's proxy server, see Zubair Ahmad, "Proxy Server 2.0," page 147). Even if you use such a product, you need to block the aforementioned ports in your firewall to reduce the vulnerability of the proxy server or firewall server to external attacks.
Service Pack 4
By the time you read this, NT Service Pack 4 (SP4) will probably be available on Microsoft's Web site. This service pack will incorporate SP3's security and feature enhancements with the post-SP3 hotfixes and provide several new features for preparing to migrate to NT 5.0. Supposedly, Microsoft will maintain the same defaults for the various security enhancements that were present in the original SP3 and post-SP3 hotfixes. As a result, administrators will need to manually activate items such as strong Security Accounts Manager (SAM) encryption, password filtering, SMB signing, NT LAN Manager (NTLM) authentication disabling, and other security-related features. Microsoft's conservative approach makes sense, because enabling all these fixes by default can be disastrous in many environments.
SP4 also has the unique distinction of being the first service pack to go through a public beta test. Microsoft hopes that this process will result in a more stable version that avoids the false starts users have seen in the past with not-ready-for-prime-time patches.
Be Proactive
Maintaining network security is a never-ending process, so you need to set up a proactive security regimen. This regimen can include activities such as frequent review of security event logs (which means you need to enable auditing if you haven't already) and regular visits to various NT security-related Web sites and newsgroups. To get you started, I've provided you with a list of Web sites (see "NT Security Resources") that I've found to have good NT security information and security-related products.
Wrapping It Up
I've tried to bring to your attention some of the greatest areas of concern and exposure surrounding security on an NT network. Although no network is totally invincible, taking action to lock down the physical security and operating system (OS) holes will provide your network with less exposure to hackers, and will provide you with a better night's sleep.
| NT SECURITY RESOURCES |
|
NT Security Network http://www.ntsecurity.net NT BugTraq http://www.ntbugtraq.com SANS Institute http://www.sans.org Microsoft's Security Page http://www.microsoft.com/security L0pht Heavy Industries http://www.l0pht.com Aelita Software Group http://www.ntsecurity.com Intrustion Detection Systems http://www.intrusion.com Internet Security Systems http://www.iss.net |
