16 Steps to Building a Secure Web Server

When IBM brought an AS/400 to the Windows NT Magazine Lab, it claimed that the AS/400 was "the safest Web server on the planet" because professional security firms failed to break into it. Naturally, the Lab and I felt compelled to build a secure NT Web server. I spent approximately 3 hours completing the job. When the Lab turned the same professional security firms loose on my system, they were unable to break in.

An NT server is a great platform right out of the box; however, NT isn't bulletproof. An NT Web server definitely needs strengthening against unwanted intrusion.

In most cases, large companies can survive losses resulting from security breaches; smaller businesses might not. I've seen more than one business vanish overnight as a result of the financial damage an intrusion causes.

In this article, I'll describe how I built my NT Web server and give tips on how you can build your own. I'll also describe steps to increase security on your server.

How I Did It
I made numerous changes to NT's original configuration to secure the system I built for the Lab, which the Lab used for Internet services only. I created a standalone server in its own private workgroup and installed only the necessary default services (plus Internet Information Server--IIS). I didn't add any optional services or use any third-party security add-ons.

If you're familiar with NT's administration tools and the basic concepts of granting and removing user rights and permissions, you know that these modifications involve editing the Registry. If you're considering building your own server, have an up-to-date Emergency Repair Disk (ERD) handy. Also, use caution when changing the Registry: Mistakes in editing the Registry can lead to an unbootable NT server.

Step 1: Install the Latest Service Pack and Applicable Hotfixes
After you install your operating system (OS), you can load the current service pack. I used Service Pack 3 (SP3).

Some network engineers claim that installing service packs isn't always necessary. However, sometimes service packs contain features that fix security problems. Because Microsoft doesn't always itemize service pack features, you won't know which features are included unless you use the service pack. The same is true for post-service pack hotfixes. On at least one occasion, I used an unrelated hotfix that contained the solution to an obscure security problem I had. However, the associated Microsoft Support Online article and README file didn't mention this hotfix.

You can always test a hotfix or service pack on a nonproduction (or backup) server before you implement it on your live server. If you don't have a second server or don't feel comfortable loading fixes, you can seek a network professional's assistance. This money will be well spent. To minimize the risk of a faulty service pack or hotfix breaking my NT server, I wait about a week after Microsoft releases a new one to see whether any major complaints arise from the user community.

If you don't know which service packs you need, you can load them all or seek a network professional's advice. The order in which you install hotfixes is important because later hotfixes sometimes supersede earlier ones. You need to pay attention to the date and time stamps on the files listed on Microsoft's FTP site and install the hotfixes in chronological order. The hotfixes are located at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes. If you add services or install new versions of NT components later, you'll need to reinstall the latest service pack and hotfix (so keep them available).

When I built my system, I loaded five mandatory post-SP3 hotfixes: getadmin-fix, teardrop2-fix, srv-fix, simptcp-fix, and pent-fix. If you want to learn about what these hotfixes can do, read Microsoft Support Online articles located in the named subdirectories.

Step 2: Change NTFS File and Directory Permissions
NTFS provides more advanced security features than FAT file systems, so use NTFS whenever possible (e.g., if you install an additional hard drive or create new partitions on existing drives). FAT offers no security at the file and directory levels. If you must use a FAT file system, consider securing the FAT partition by using the Secure System Partition command on the Partition menu of the Disk Administrator utility. You can use FAT for the boot partition of an ARC-compliant RISC system (e.g., an Alpha), but don't put any files on that partition other than the Windows NT installation default boot files.

The files and directories that comprise the OS software on any partition require protection. The standard set of permissions on these files and directories provide a reasonable degree of security without interfering with the computer's usability. However, you can modify the NTFS file and directory permissions, if necessary. For high-level security installations, set directory permissions for all subdirectories and existing files immediately after you install NT. Remember that you need to apply permissions to parent directories before you apply permissions to subdirectories. Table 1 provides a list of the permissions you need to apply. You will also need to apply exceptions to the general security permission settings within the /winnt directory. Table 2 provides these exceptions. Because several critical OS files exist in the root directory of the system partition on Intel-based systems, you might also consider assigning the permissions listed in Table 3.

To view these files in Explorer, you can choose the By File Type command from the View menu, then select the Show Hidden/System Files check box in the By File Type dialog box. Be sure to review your changes on each partition to ensure they have been properly secured. You can use Explorer or a specialized tool such as CACLS from the Microsoft Windows NT Server 4.0 Resource Kit, or Somarsoft's DumpACL (available at www.somarsoft.com) to perform this audit. Also, review your file and directory permissions periodically to determine whether sensitive files are exposed to unauthorized users or groups.

Step 3: Secure NT Services
Several NT-based services are vulnerable when exposed to an untrusted network like the Internet. Therefore, consider disconnecting (unbinding) these services from any publicly exposed network adapters, including serial communications (COM) ports (dialup adapters) if you use Remote Access Service (RAS) for Internet or inbound dial-up access. For example, unless you must support telecommuters who need access to this service, don't make the server available to remote users. If remote Internet users need to access this sensitive service, you can use a Virtual Private Network (VPN). Establishing a VPN with Point-to-Point Tunneling Protocol (PPTP) provides a more secure means of supporting telecommuter connections.

If you aren't supporting telecommuters, you still need the server to work correctly on your private network. Disable the server bindings to any network adapter cards connected to the Internet or other untrusted networks. Do not leave the following standard services bound to an exposed network card, except under special circumstances: Alerter, Clipbook Server, Dynamic Host Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), Directory Replicator, Messenger, Network Dynamic Data Exchange (DDE), Network DDE DSDM, Schedule, Simple Network Management Protocol (SNMP), and simple TCP/IP services. In short, bind only the required services (e.g., Web or email) to a public network adapter.

In my secured system, I used only one network adapter card and loaded only default services, which simplified the unbinding process. I disabled the WINS client binding from the adapter, and rebooted the system. To unbind services from a network adapter, open the Network applet in Control Panel, click the Bindings tab, select your exposed network adapters, and click Disable. You can then close the dialog box and reboot the server.

I didn't install the FTP service portion of IIS and encourage you not to install it. FTP clients send passwords in clear text, and packet sniffers can easily grab them. Also, minor oversights in setting your directory and file permissions can lead to a system security breach. The only services running on my system were the event logs, NT LAN Manager (NTLM) Security Support Provider, Remote Procedure Call (RPC) Service, and Web Service.

Step 4: Obscure the Administrator Account
Crippling the built-in Administrator account (i.e., removing its permissions and rights) is a great idea. This powerful built-in account is dangerous to leave available because intruders can use it as a target for gaining access to your network.

Some network professionals argue that renaming or disabling the Administrator account is easier than crippling it. However, there are two reasons why the easier way isn't necessarily the safest way to handle this vulnerable account. First, before Microsoft released SP3, the RedButton utility easily revealed your newly renamed Administrator account. SP3 fixed that problem, but you're better off safe than sorry. Second, intruders can recognize a disabled account and start guessing account names and passwords until they find what works.

If you cripple the Administrator account, intruders might spend days, weeks, or even months trying to guess the account name and associated password. Even if the hackers eventually discover the name and password, they will also find that the account has no rights or permissions, and they've wasted their time. In the meantime, you can closely monitor your audit logs to detect break-in attempts and the would-be intruder, and take steps to make your network more secure.

On my installation, I used the built-in TCP/IP filtering security to disable all ports except port 80 so a tool like RedButton couldn't contact the NT system. I also used a shortcut to obscure the Administrator account. This shortcut can work for you if you're certain you won't expose non-Internet service ports (e.g., port 137, port 138, and port 139 for NetBIOS) in the future.

First, I gave the Administrator account an obscure, hard-to-guess name. Then I created a new Administrator account and removed all default permissions and rights, effectively creating a dummy target for would-be intruders. I removed the right to log on from the network, so users couldn't access the system across the network. That way, an intruder who learned the new account name and associated password would still need to log on to the system using the local keyboard console. Administrators working remotely might require the right to log on from the network to perform certain operations. It's always best to require any remote user to use PPTP to access the corporate network from across the Internet. If you don't use an encryption method such as PPTP, a hacker can sniff your network traffic more easily and possibly use the information in the network traffic to penetrate the system.

NT also creates a Guest user account (as seen in User Manager). However, leave this account disabled until a guest uses your network, and then create a specific account for that person. (You will need to delete the account after the guest has finished using it).

Step 5: Activate Screen Savers
If you enforce a policy of using the NT screen-saver feature, enable the Password-Protected option, and set the activation time to a low value (i.e., 1 minute to 10 minutes). When a user walks away from a computer without logging off, the screen saver will automatically activate, thus protecting the system from unwanted access. The effort users expend continually deactivating screen savers is worth the level of safety that you obtain from using them. However, heavily animated screen savers on a server unnecessarily use CPU cycles so a blank screen saver will serve you better.

Step 6: Protect the Registry
NT stores all initialization and configuration information in the Registry. Some processes modify their own keys, and you can modify other keys by using a Registry editor. Because you can configure the NT Registry from a remote location, you need to restrict access to it. To restrict access, create the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\ SecurePipeServers\winreg Registry key. The security permissions set on this key define which users or groups can access the Registry remotely. By default, NT Workstation doesn't define this key or restrict remote access to the Registry. The NT Server default setting permits only administrators to access the Registry remotely. However, you might consider not letting anyone access the Registry remotely, including administrators.

Step 7: Secure the Event Logs
By default, NT lets guests and anonymous users view the System Log and Application Log. By default, NT also protects the Security Log from guest access. However, users who have the Manage Audit Logs user right can view the Security Log. The event log service uses the RestrictGuestAccess entry (type REG_DWORD) in the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSetServices\ EventLog\Log Name Registry key to restrict guest access to these logs. To restrict anonymous and guest access, you can set the value for each log to 1. The change will take effect the next time the system reboots. You can also change the user access permissions on the Registry key so that users other than those who can access the Administrator and system accounts cannot access this key. Otherwise, an intruder can reset the Registry key value and permit unwanted access to the logs.

Step 8: Hide the Name of the Last User
By default, NT leaves the name of the last user to log on in the Username field of the logon dialog box, which makes it more convenient for a frequent user to log on. However, this username also provides 50 percent of the puzzle needed to break into a system locally. You can use a Registry editor to create the Don't-DisplayLastUserName entry (type REG_SZ and data value of 1) in the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\WindowsNT\ CurrentVersion\Winlogon Registry key so that the username doesn't appear in the logon dialog box.

Step 9: Restrict Anonymous Network Access to the Registry
SP3 for NT 4.0 includes a security enhancement that restricts anonymous (null session) logons that connect to specific named pipes. SP3 provides the NullSessionPipes entry (type REG_MULTI_SZ) in the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\LanManServer\ Parameters Registry key, which defines the list of named pipes that are exempt from this restriction. Microsoft's Support Online article "Can No Longer Access the Registry With Null Sessions" (http://support.microsoft.com/support/kb/articles/q143/1/38.asp) provides complete details about modifying this key.

Step 10: Restrict Anonymous Lookup
NT has a feature that lets anonymous users list domain usernames and count share names. Users who want enhanced security have asked Microsoft for help in restricting this feature. SP3 for NT 4.0 (and a hotfix for Windows NT 3.51) lets you restrict this feature. To implement your restrictions, you can use the RestrictAnonymous entry (type REG_DWORD and data value of 1) in the HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\Lsa Registry key.

Step 11: Remove Default Administrator Shares
Windows and DOS don't display shares ending in a dollar sign ($). You can use this method to hide any shares that you don't want users to see or make administrative shares invisible to network browsers. You can connect to hidden shares only if you know the exact share name.

Default administrative shares can't be removed by unsharing them. Likewise, deleting a share will remove it only temporarily (the share will reappear the next time you reboot the system). To permanently remove administrative shares, you can edit the appropriate Registry key. For NT Server, the Registry key is HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ LanManServer\ Parameters\ AutoShareServer. For NT Workstation, the Registry key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\AutoShareWks. Change the value to 3D0 and reboot the system.

Step 12: Perform System Audits
Auditing can detect suspicious activity before it escalates into a major problem. Actions that are important to audit are failed logon attempts, failed attempts to access sensitive data, and changes to security settings. You can also audit successful logons and find out whether a user is accessing unauthorized accounts after hours or while someone is on vacation. Depending on your network usage and policies, you can monitor suspicious activity by auditing the successful use of user rights, user and group management, security policy changes, and system restart and shutdown events. You can activate system auditing by using the following steps:

1. Log on with an account belonging to the Administrator group.
2. Click Start, and choose Programs, Administrative Tools, User Manager.
3. Choose the Policies menu, and select Audit.
4. Select Audit These Events.
5. Enable the options you want to use. The Success check box enables logging for successful operations, and the Failure check box enables logging for unsuccessful operations (Table 4 lists the available options).
6. Click OK to close the dialog box, then close User Manager when you're finished.
7. Enable file and directory auditing by adjusting their individual properties using Explorer.

Step 13: Audit Base Objects
Auditing base objects adds a level of protection because it logs sensitive object access to the event logs. However, you can't start generating audits just by setting this value; the administrator must turn on auditing for the Object Access category in User Manager. This setting tells the Local Security Authority (LSA) that it must create base objects with a default system audit control list. To audit base system objects, use the AuditBaseObjects entry (type REG_DWORD and data value of 1) in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Registry key.

Step 14: Audit Privileges
By default, the system includes certain privileges that you can't audit, even when you turn on privilege auditing. NT leaves these privileges disabled to control audit log growth. However, you can audit these privileges if you want to detect account tampering. Table 5 lists these privileges and default assignments. Auditing the first item in Table 5 won't provide you with any useful information because it's a privilege granted to everyone. Regarding item 2, only programmers can debug programs. Item 3, item 4, and item 5 are highly sensitive rights, and should not be granted to any user or group unless absolutely necessary. Item 6 and item 7 are used during normal system operations. To audit these privileges, you can use the FullPrivilegeAuditing entry (type REG_BINARY and data value of 1) in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Registry key.

Step 15: Disable Caching Logon Credentials
By default, NT caches the logon credentials for the last user. With this feature, a user can log on to the system even if the system is disconnected from the network and the domain controllers are unavailable. Because I installed my system as a standalone server in a separate workgroup, I didn't worry about domain controllers and caching. However, to be on the safe side, I made an adjustment.

The credential cache is protected, but you can disable this cache completely if your environment requires a high level of security. To disable credential caching, use the CachedLogonsCount entry (type REG_DWORD and data value of 0) in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Win-dowsNT\CurrentVersion\Winlogon Registry key.

Step 16: Enable TCP/IP Filtering Security
As a final step to secure my system, I employed the built-in TCP/IP filter. I shut down all ports except port 80 for the intrusion test, which made the task quick and easy. If you're planning to use the TCP/IP filter and you have FrontPage, PPTP, Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP) mail, or other Internet services, you'll need to open the associated ports so that those services can work correctly. To activate TCP/IP filtering, go to Control Panel and open the Network applet. Select the Protocols tab and view the TCP/IP protocol properties. Click Advanced on the IP Address tab, and select the Enable Security check box. Click Configure, and select all three Permit Only options (i.e., TCP ports, Internet Control Message Protocol--ICMP ports, and User Datagram Protocol--UDP ports). This selection will activate filtering for all three packet types. Click Add under TCP ports, and add port 80 for the Web server. Open any other ports you need to open.

When you enable ICMP and UDP ports (by selecting the Permit Only options) without adding ports, NT will not accept any of these packet types, effectively blocking almost all system traffic. (The system will still respond to ping packets.)

Some Sound Advice
Most of the modifications I made to my system addressed network access. However, you can modify your system further to strengthen overall security. For instance, you can employ system keys that are part of SP3, or use two or more network cards (one for internal private use and one for Internet public use) and bind only certain services to the internal private cards to ease administration. Most important, you must consistently monitor event logs and clear or save them. Thus, you need to set an acceptable log size and keep sufficient log records so that no logs roll off before you inspect them.

To adjust your log properties, open Event Viewer and select Log Settings from the Log menu. A dialog box in which you can make your adjustments will pop up.

If you want to examine the list of security issues that have surfaced with NT and other BackOffice products over the last year or so, or learn more about NT security, visit my Web sites at http://www.ntsecurity.net and http://www.ntshop.net.

This article is adapted from Mark's book, Internet Security with Windows NT (Duke Press at http://www.dukepress.com).