NT Server Security Checklist

Steps to address NT's security weaknesses

Windows NT systems have been the subject of much attention lately. I'm not talking about the latest Microsoft public relations campaign extolling NT's virtues, I'm talking about the full-scale security war that hackers are waging against the NT operating system (OS). Several denial-of-service and NT password gathering and hacking utilities such as GetAdmin, RedButton, and TearDrop2-based programs have appeared during the past year. These utilities expose holes in NT's architecture and maliciously attack NT systems in various ways. The hackers and NT security experts who develop these programs are causing some real headaches for Microsoft, as well as enterprises and NT administrators. What was intended as a useful and necessary campaign to expose holes in NT's security architecture has rapidly escalated into a security hole witch hunt.

All the negative publicity about NT's security holes is frightening. After all, who wants to run an OS that's easy to hack? However, NT is very securable. Notice I didn't say secure, I said securable. NT gives you several tools to secure your servers and workstations against many types of attacks. However, Microsoft doesn't enable most NT security features by default, even when you install Service Pack 3 (SP3--for information about SP3 and NT security, see Mark Joseph Edwards, "Service Pack 3 Is Really Security Pack 3," August 1997). Contrary to popular belief, you can't just install the latest Microsoft service pack and walk away. Although installing the latest patches is a good start, you need to implement a comprehensive set of policies and procedures to address various weaknesses in NT and networked PCs as a whole.

Every new denial-of-service attack and security-cracking utility (and the subsequent fixes Microsoft has issued to thwart them) has made NT more secure. Although NT users have to suffer through interim periods in which the OS is defenseless against a particular type of attack, Microsoft has been quick to respond with updates (i.e., service packs and hotfixes) that patch the affected system components.

To effectively address the latest security concerns, you need to develop a comprehensive NT systems security checklist that covers the most important aspects of maintaining a secure NT network environment. In this article, I'll give you security tips to help you audit your system configurations and take the necessary steps to improve the security of your environment.

Getting Physical with Security
The most obvious, although often overlooked, concern when you're securing your NT systems is physical security. After all, Registry modifications and service pack patches won't help if someone can walk up to your server and boot a 3.5" disk or CD-ROM to load an alternative OS, remove an unprotected tape, or access an Emergency Repair Disk (ERD) to analyze and crack the Security Accounts Manager (SAM) databases. To ensure physical security on your network, you need to consider implementing the following procedures.

Put servers and important equipment in a secure location.
Nothing prevents physical meddling like a locked room. Wherever possible, keep your important network equipment (e.g., servers, routers, hubs, switches) in a secure, locked room that only trusted personnel can access. In addition, people in high security environments can consider implementing a key access system that uses key cards to maintain a log detailing the comings and goings of visitors to the network operations center.

Set a system BIOS password.
Most modern systems contain BIOS password options that let you control who can change the BIOS configuration settings on the computer. You can use these options to cause the system to require a password before the system will boot. Consider setting these BIOS password options for different security access levels (e.g., View vs. Change) to prevent unauthorized users from changing your server and workstation BIOS settings.

In addition, consider using a password at system boot to prevent unauthorized users from rebooting network servers. However, be aware that requiring a password at system boot can interfere with the system's ability to perform an unattended reboot after a manual restart or power outage. If a server can't reboot because a systems administrator isn't around to enter the BIOS password, you'll have some unhappy users. The system BIOS on some new systems lets you continue the boot process without the password and disables the ability to boot the system until you enter the password. Consider using this boot option for network servers.

Disable or limit access to removable drives.
A classic security hole involving physically accessible systems is the use of removable 3.5" disk and CD-ROM drives. Unauthorized users can use these drives to boot alternative OSs that let them circumvent network security and gain unauthorized access to system data. A locked equipment room takes care of this problem, unless you have to locate your server in a commonly accessible area. However, regardless of the server's location, you can help prevent attacks by setting the BIOS boot order option to boot from the hard disk first and boot from the 3.5" disk or CD-ROM drive second. Configuring your system in this manner also helps protect the server from boot sector viruses in the event a user leaves a boot sector virus-infected disk in the server's 3.5" drive.

Secure backup media.
Backup tapes and ERDs often contain sensitive, security-related data (e.g., the SAM database in the Registry) that a hacker can target for password-cracking attacks. For this reason, be sure you physically secure any removable media that contains such data. As with many physical access attacks, you can avoid this attack by keeping your sensitive data in a locked room.

Control access to power.
How secure are your building's power controls, and how easily can someone throw a switch (e.g., an electrician performing some repair work during the weekend) and cut the power in your building? If you can regulate access to these facilities, strongly consider doing so. Furthermore, next to any such controls, place a sign that offers contact names and telephone numbers for responsible individuals in your organization whom a repair person must contact before performing any work.

Other physical security concerns are obvious but important nonetheless. For example, in environments in which servers are in physically secured areas, be sure you don't leave an unattended server logged on (especially with the Administrator account). Because you might walk away from a server while you're logged on as the administrator, be sure you configure a secure screen saver (i.e., one that locks the station after a short idle period) for this account's profile.

Setting General Network Security Guidelines
After you address your network's physical security considerations, you can tackle some network-specific security concerns. These guidelines can help you evaluate particular network security needs for your environment.

Use switch ports.
Hackers (both external and internal) often use network sniffers (e.g., the NT Server or Systems Management Server--SMS--version of Network Monitor or hardware devices with similar functionality) running on the company's primary LAN segment to collect usernames, passwords, and other important data. Shared-media network hub arrangements let any user view all data transmitted on the network. A better approach is to use switch ports in these environments for as many users as possible, to limit the information users can see. Switches, unlike shared-media hubs, don't transmit all data to all ports. Instead, you can view only the data that is transmitted to or from particular users within their switched port's private collision domain where the users connect to the LAN. Besides this security benefit, switches provide better network performance. Although switches are expensive for environments with a large number of users, switches warrant consideration given the inherent performance and security boosts they provide. (Switches limit the traffic that another host connected to a particular switch port, a sniffer running on the host of the same port as the server, or the server itself can view; however, a hacker can still access a lot of authentication and session data.)

Disable clear text authentication.
A corollary to my previous warning about network sniffing. Applications such as FTP and certain Web clients use clear text authentication by default (or exclusively) to connect with servers: Limit the use of clear text passwords on your network wherever possible. For example, Screen 1 shows the global configuration option for disabling clear text authentication in Internet Information Server (IIS) 4.0.

Sending clear text usernames and passwords across network connections is a highly insecure activity that you need to avoid at all costs. Be aware that some applications, such as using Netscape Navigator to access an Exchange Server running Outlook Web Access or other secure IIS pages, will fail if you disable clear text authentication. Therefore, before you change your production servers, you need to thoroughly test the ramifications of disabling clear text authentication.

Toughening Password Security
Another area in which you can strengthen your network security is to toughen your network user password policies. You need to enforce the strictest password policies you can politically survive within your organization.

Force password expirations.
At a minimum, make all network users change their passwords once every quarter. In addition, consider restricting the reusability of passwords by setting the Password Uniqueness option under the User Manager Account Policy dialog box, as Screen 2 page 153 shows, to a value of 2 or more. So for example, a value of 3 specifies that users can't reuse their previous three passwords when selecting a new and different password at password-changing time.

Set password length.
I recommend you enforce user passwords of at least seven characters for maximum security (but under any circumstances, no less than six characters). Longer passwords are OK, but they might not deliver the increased security you expect; this reduced return occurs because of particularities of Microsoft's hash-generation algorithms for user passwords.

Use strong passwords.
Another important password-related policy is forcing users to use strong passwords (i.e., passwords that contain a mixture of different character types). Unfortunately, you can't set this policy from the User Manager Account Policy dialog box: You have to install the passfilt.dll file, which comes with SP3, on all your network domain controllers. Although you need to add this file only on the Primary Domain Controller (PDC) to implement strong passwords, I suggest you also add it on your Backup Domain Controllers (BDCs) in case NT needs to promote a BDC to be the PDC at some point.

The passfilt.dll file forces all user passwords to conform to the same simple guidelines; otherwise, NT issues an error. These guidelines state that passwords must be at least six characters long. The passwords must contain at least three character types (lowercase letters, uppercase letters, numbers, or non-alphanumeric and special characters). Finally, the passwords can't contain any part of the user's name. To enable this password-filtering feature, you must modify the Notification Packages value of the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa Registry key after you install SP3. Specifically, you need to add the string %SYSTEMROOT%SYSTEM32PASSFILT.DLL (e.g., c:winntsystem32passfilt.dll) to the end of the existing data for this REG_MULTI_SZ value (don't replace the existing data; just append it).

After you reboot the system, NT will enforce strong passwords on the domain. Strong password enforcement isn't unique to SP3; products such as Mission Critical Software's Enterprise Administrator provide strong password enforcement options. In some cases, these third-party products might be preferable to the SP3 version of this security measure because they provide greater flexibility and stronger potential restrictions.

Use password crackers.
Regularly run a password cracking utility against your SAM database as part of your security regimen, even if you enable SP3's passfilt.dll or use a third-party product such as Enterprise Administrator. A password cracker can help you grasp how much damage hackers can do once they access your SAM database. Several utilities can help you crack passwords, but my favorite is the latest version of L0phtCrack (el-zero-p-h-t Crack) from the famous hacker organization L0pht Heavy Industries. The folks at L0pht are on the cutting edge of NT security issues, and they often expose NT's flaws (the LanMan authentication hotfix that L0pht's "Mudge" discovered is a good example). The latest version of L0phtCrack is Microsoft's worst nightmare and every NT administrator's new best friend. It lets you run (in the background, if desired) dictionary-based and brute-force attacks against LanMan and NT hash codes. It even includes a network sniffer tool that can grab user logon authentications (including LanMan and NT hash codes) as they occur on the network. L0phtCrack is a powerful tool that needs to be part of every NT administrator's toolkit. You can download a trial version or order the commercial version from L0pht's Web site.

Use security analysts.
No discussion of security tools would be complete without mentioning NT security analysis tools such as Intrusion Detection's Kane Security Analyst and Kane Security Monitor. The analyst product conducts a comprehensive security audit of your system to determine areas of weakness and possible improvement, and the monitor product provides realtime monitoring and alerting to detect attempted security breaches and notify systems administrators. For a review of the monitor product, see Mark Joseph Edwards, "Kane Security Monitor 3.03," June 1998. I highly recommend both products.

Along the same lines, don't forget the C2 Configuration Utility (c2config.exe) that comes with the Microsoft Windows NT Server 4.0 Resource Kit. Although this utility doesn't offer any of the advanced analysis or monitoring features of commercial security products, it's handy for enabling some basic system security measures. For example, you can use it to remove unwanted application subsystems (POSIX and OS/2), instruct NT not to display the last username (which you can also set for the domain via System Policy Editor--SPE), and enable system access warning messages that appear before the logon dialog box. This last capability is especially important, because legal precedents have shown that the successful prosecution of intruders is often contingent on a proper notification that unauthorized access of the system is illegal.

One other company producing excellent NT security analysis tools is Internet Security Systems (ISS). ISS produces RealSecure real-time intrusion detection and response software. This product is a true distributed network security monitor that analyzes network traffic across a corporate LAN or WAN to identify possible intrusions. ISS also produces several security scanning products that let you probe your network's firewalls, intranets, and public Internet servers for potential security holes.

Secure the SAM.
The last item on the password portion of our security checklist is securing the keys to the NT kingdom--the SAM database. By default, NT places extremely weak protection on the SAM database (where NT stores all usernames and passwords). As a result, strongly consider using SYSKEY, SP3's utility for encrypting the SAM database. SYSKEY lets you apply 128-bit encryption to the SAM database, a security measure I consider a must for security-conscious environments or Internet-connected networks. However, you need to be aware of some important considerations before you enable SYSKEY on a domain controller, so consult Microsoft Support Online article Q143475 (http://support.microsoft.com/support/kb/articles/q143/4/75.asp) and Mark Joseph Edwards, "Service Pack 3 Is Really Security Pack 3," August 1997 before proceeding with this utility.

NT Security: A Journey, Not a Destination
No network is ever 100 percent secure, regardless of the security measures you put into place. The universal constants of human ingenuity and the continual supply of new OSs and application versions means that NT can never be totally immune to malicious attacks. Despite this constant threat, you can take some big steps to provide an adequate level of security to your organization by following the security guidelines provided in this article.

In a future article, I'll continue this security checklist by discussing what you need to do to lock down NT after applying SP3 and the security-related post-SP3 hotfixes. Specifically, I'll discuss what you need to do to prevent unauthorized access to the Registry and file systems and how you can strengthen NT's over-the-wire encryption of data for both user passwords and session data. I'll discuss the individual security-related hotfixes in detail and what problems each hotfix addresses, and give you some tips relating to port-filtering and using Microsoft Proxy Server to strengthen your network firewall.