Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Windows NT 4.0 Workstation Baseline Security Checklist

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Important: The purpose of this checklist is to give instructions for configuring a baseline level of security on computers running Windows NT 4.0 Workstation. Additional advanced settings are provided in the complete Windows NT 4.0 Workstation Configuration Checklist on the Microsoft TechNet Security Web site.

This checklist outlines the steps you should take to secure computers running Windows NT Workstation, either on their own or as part of a Windows NT domain.

This checklist contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

Windows NT 4.0 Workstation Configuration

Steps

 

box

Verify that all disk partitions are formatted with NTFS

 

box

Verify that the Administrator account has a strong password

 

box

Disable unnecessary services

 

box

Disable or delete unnecessary accounts

 

box

Make sure the Guest account is disabled

 

box

Protect files and directories

 

box

Protect the registry from anonymous access

 

box

Apply appropriate registry ACLs

 

box

Restrict access to public Local Security Authority (LSA) information

 

box

Enable SYSKEY protection

 

box

Set stronger password policies

 

box

Set account lockout policy

 

box

Configure the Administrator account

 

box

Remove all unnecessary file shares

 

box

Set appropriate ACLS on all necessary file shares

 

box

Install antivirus software and updates

 

box

Install the latest Service Pack

 

box

Install the appropriate post-Service Pack security hotfixes

Windows NT 4.0 Server Configuration Checklist: Further Details

Verify that all disk partitions are formatted with NTFS

NTFS partitions offer access controls and protections that aren't available with the FAT, FAT32, or FAT32x file systems. Make sure that all partitions on your workstation are formatted using NTFS. If necessary, use the convert utility to non-destructively convert your FAT partitions to NTFS. Note that doing so will render the NTFS partitions unavailable to Windows 9x clients, unless you add a third-party utility such as NTFSDOS.

Warning: If you use the convert utility, it will set the ACLs for the converted drive to Everyone: Full Control. Use the fixacls.exe utility from the Windows NT Server Resource Kit to reset them to more reasonable values.

Verify that the Administrator account has a strong password

Windows NT allows passwords of up to 14 characters. In general, longer passwords are stronger than shorter ones, and passwords with several character types (letters, numbers, punctuation marks, and nonprinting ASCII characters generated by using the ALT key and three-digit key codes on the numeric keypad) are stronger than alphabetic- or alphanumeric-only passwords. For maximum protection, make sure the Administrator account password is at least nine characters long and that it includes at least one punctuation mark or nonprinting ASCII character in the first seven characters.

Disable unnecessary services

After installing Windows NT, you should disable any network services not on that list. In particular, you should consider whether your computer needs any Peer Web Services components and whether it should be running the Server service for file and print sharing.

Disable or delete unnecessary accounts

You should review the list of active accounts (for both users and applications) on the system in User Manager, disable any nonactive accounts, and delete accounts that are no longer required.

Make sure the Guest account is disabled

By default, the Guest account is disabled on systems running Windows NT Workstation. If the Guest account is enabled, disable it.

Protect files and directories

A number of file system permissions need to be changed to provide adequate security on your workstations and servers. These permissions require you to use NTFS for your system volume, but you should be doing that anyway. The definitive reference for these changes is the white paper NSA Windows NT System Security Guidelines, produced by Trusted System Services. Their recommendations call for setting file and directory ACLs as shown below. In the table, "Installers" refers to any accounts that have privileges to install application or system software.

Directory or file

Suggested Maximum Permissions

C:\

Installers: Change

Everyone: Read

Server Operators: Change

files

Installers: Change

Everyone: Read

Server Operators: Change

IO.SYS, MSDOS.SYS

Installers: Change

Everyone: Read

Server Operators: Change

BOOT.INI,
NTDETECT.COM,
NTLDR

(none)

AUTOEXEC.BAT,
CONFIG.SYS

Installers: Change

Everyone: Read

Server Operators: Change

C:\TEMP

Everyone: (RWXD)*(NotSpec)

C:\WINNT\

Installers: Change

Everyone: Read

Server Operators: Change

files

Everyone: Read

Server Operators: Change

win.ini

Installers: Change

Public: Read

Server Operators: Change

Control.ini

Installers: Change

Everyone: Read

Server Operators: Change

Netlogon.chg

(none)

\WINNT\config\

Installers: Change

Everyone: Read

Server Operators: Change

\WINNT\cursors\\WINNT\fonts

Installers: Change

Everyone: Add & Read

Server Operators: Change

PwrUsers: Change

\WINNT\help\

Installers: Change

Everyone: Add & Read

Server Operators: Change

PwrUsers: Change

*.GID, *.FTG, *.FTS

Everyone: Change

\WINNT\inf\

Installers: Change

Everyone: Read

*.ADM files

Everyone: Read

*.PNF

Installers: Change

Everyone: Read

Server Operators: Change

\WINNT\media\

Installers: Change

Everyone: Read

Server Operators: Change

PwrUsers: Change

*.RMI

Everyone: Change

\WINNT\profiles\

Installers: Add&Read

Everyone: (RWX)*(NotSpec)

..\All users

Installers: Change

Everyone: Read

..\Default

Everyone: Read

\WINNT\repair\

(none)

\WINNT\system\

Installers: Change

Everyone: Read

Server Operators: Change

\WINNT\System32\

Installers: Change

Everyone: RX [per 137155]

Server Operators: Change

Backup Operators: Change

files

Everyone: Read

Server Operators: Change

$winnt$.inf

Installers: Change

Everyone: Read

Server Operators: Change

AUTOEXEC.NT,
CONFIG.NT

Installers: Change

Everyone: Read

Server Operators: Change

cmos.ram,
midimap.cfg

Everyone: Change

localmon.dll,
decpsmon.*,
hpmon.*

Installers: Change

Everyone: Read

Server Operators: Change

Print Operators: Change

\WINNT\System32\config\

Everyone: List

\WINNT\System32\DHCP\

Everyone: Read

Server Operators: Change

\WINNT\System32\drivers\(including \etc)

Everyone: Read

\WINNT\System32\LLS

Installers: Change

Everyone: Read

Server Operators: Change

\WINNT\System32\OS2
(including \DLL subdir)

Everyone: Read

Server Operators: Change

\WINNT\System32\RAS

Everyone: Read

Server Operators: Change

\WINNT\System32\Repl

Everyone: Read

Server Operators: Change

\WINNT\System32\Repl\,

import, export, scripts

subdirs

Everyone: Read

Server Operators: Change

Replicator: Change

\WINNT\System32\spool

Installers: Change

Everyone: Read

Server Operators: Full

Print Operators: Change

\drivers\

\drivers\w32x86\2\

\prtprocs\

\prtprocs\w32x86\

\drivers\w32x86\

Installers: Change

Everyone: Read

Server Operators: Full

Print Operators: Change

\printers\, \tmp\

Installers: Change

Everyone: (RWX)(NotSpec)

Server Operators: Full

\WINNT\System32\viewers

Everyone: Read

Server Operators: Change

\WINNT\System32\wins

Everyone: Read

Server Operators: Change

C:\...\*.EXE, *.BAT, *.COM, *.CMD, *.DLL

Everyone: X

Protect the registry from anonymous access

The default permissions do not restrict remote access to the registry. Only administrators should have remote access to the registry, because the Windows NT registry editing tools support remote access by default. To restrict network access to the registry:

  1. Add the following key to the registry:

    Hive

    HKEY_LOCAL_MACHINE\SYSTEM

    Key

    \CurrentControlSet\Control\SecurePipeServers

    Value Name

    \winreg

  2. Select winreg, click the Security menu, and then click Permissions.

  3. Set the Administrators permission to Full Control, make sure no other users or groups are listed, and then click OK.

The security permissions (ACLs) set on this key define which users or groups can connect to the system for remote registry access. In addition, the AllowedPaths subkey contains a list of keys to which members of the Everyone group have access, notwithstanding the ACLs on the winreg key. This allows specific system functions, such as checking printer status, to work correctly regardless of how access is restricted via the winreg registry key. The default security on the AllowedPaths registry key grants only Administrators the ability to manage these paths. The AllowedPaths key, and its proper use, is documented in Microsoft Knowledge Base article 155363.

Apply appropriate registry ACLs

A number of registry keys need changes to their default ACLs for maximum security. The definitive reference for these changes is the white paper NSA Windows NT System Security Guidelines, produced by Trusted System Services. Their recommendations call for removing the Everyone ACE from the keys listed in the table below (where it exists), and then changing the ACL as noted in the table. In the table, "Installers" refers to any accounts that have privileges to install application or system software.

Warning: Unless the table says "Entire tree," change permissions only on the indicated key, not on its subkeys.

Key path

Permissions

Notes

\Software

Installers: Change

Everyone: Read

Only accounts that can install software should have change rights to this tree.

\Software\Classes

Installers: Add

Everyone: Read

Tree needs special treatment because restricting to read access for Everyone might break some applications.

\Software\Microsoft\Windows\CurrentVersion\App Paths

Installers: Change

Everyone: Read

Apply to entire tree. At install time this key is empty; set ACLs to prevent its misuse.

\Software\Microsoft\Windows\Current Version\Explorer

Everyone:Read

Apply to entire tree

\Software\Microsoft\Windows\Current Version\Embedding

Installers: Change

Everyone: Read

Apply to entire tree

\Software\Microsoft\Windows\Current Version\Run, RunOnce, Uninstall, and AEDebug

Everyone: Read

 

\Software\Microsoft\Windows NT\CurrentVersion\Font*, GRE_Initialize

Installers: Change

Everyone: Add

Change only keys that begin with "Font," except FontDrivers, and Gre-Initialize.

\Software\Microsoft\Windows NT\CurrentVersion\Type 1 Installer\Type 1 Fonts

Installers: Change

Everyone: Add

 

\Software\Microsoft\Windows NT\CurrentVersion\Drivers, Drivers.desc

Everyone: Read

Apply to entire tree

\Software\Microsoft\Windows NT\CurrentVersion\MCI, MCI Extensions

Installers:Change

Apply to entire tree.

\Software\Microsoft\Windows NT\CurrentVersion\Ports

INTERACTIVE: Read

Everyone: Read

Apply to entire tree.

\Software\Microsoft\Windows NT\CurrentVersion\WOW

Everyone: Read

Apply to entire tree.

\Software\Windows 3.1 Migration Status

Everyone: Read

Apply to entire tree.

\System\CurrentControlSet\Services\LanmanServer\Shares

Everyone: Read

Apply to entire tree. Prevents users from adding new shares.

\System\CurrentControlSet\Services

Everyone: Read

Apply to entire tree. Prevents non-adminis-trators from changing service settings.

Restrict access to public Local Security Authority (LSA) information

You need to be able to identify all users on your system, and therefore you should restrict anonymous users so that the amount of public information they can obtain about the LSA component of the Windows NT Security Subsystem is reduced. The LSA handles aspects of security administration on the local computer, including access and permissions. To implement this restriction, create and set the following registry entry:

Hive

HKEY_LOCAL_MACHINE\SYSTEM

Key

CurrentControlSet\Control\LSA

Value Name

RestrictAnonymous

Type

REG_DWORD

Value

1

Enable SYSKEY protection

The SAM database stores password hashes for domain and local computer accounts. An attacker who gains access to the SAM database files for a workstation (from the computer itself, the computer's emergency repair disk, or a backup tape) can use a password-cracking tool to attack these hashes, making it possible to gain access to local workstation accounts. The SYSKEY tool allows you to encrypt the SAM database to make it more difficult for an unprivileged attacker to use password-cracking tools against your stored password hashes. Microsoft Knowledge Base article 143475 details how to install and use SYSKEY.

One important decision when using SYSKEY is what mode to use. SYSKEY supports three modes: one that stores the decryption key locally, and two that store it externally. Although the first mode is more convenient, it is also less secure. As long as the key is stored on the computer, it is theoretically possible to locate it. Microsoft recommends using either of the two more secure modes.

Warning: Before you install SYSKEY, make sure to update your computer's emergency repair disk. After installing SYSKEY, make a second ERD using a new, separate floppy. Do not attempt to use the pre-SYSKEY ERD to restore your system after SYSKEY is installed.

Set stronger password policies

Use the Account Policy dialog in the User Manager or User Manager for Domains application (choose the Policies | Account command) to strengthen the system policies for password acceptance. Microsoft suggests that you make the following changes:

  • Set the minimum password length to at least eight characters

  • Set a minimum password age appropriate to your network (typically between 1 and 7 days)

  • Set a maximum password age appropriate to your network (typically no more than 42 days)

  • Set a password history maintenance (using the "Remember passwords" option) of at least 6.

Windows NT Service Pack 3 and later contain a password-filtering tool, passfilt.dll, that allows you to enforce strong password rules for password changes. The tool allows only passwords that meet all of the following criteria:

  • Must be at least six characters long

  • May not contain user account name or any portion of the user's full name

  • Must contain characters from three of the four character groups (uppercase, lowercase, numeric, and nonalphabetic punctuation characters)

Warning: This change must be performed on all domain controllers in a domain. If you fail to make the change to BDCs, when a BDC is promoted to the PDC role strong password checking will be disabled. You should also make the change on member servers so that local computer accounts are adequately protected.

To install passfilt.dll, make the following registry change (see Microsoft Knowledge Base article 151082 for more details about writing your own filters).

Hive

HKEY_LOCAL_MACHINE\SYSTEM

Key

CurrentControlSet\Control\LSA

Value Name

NotificationPackages

Type

REG_MULTI_SZ

Change

Add the string passfilt.dll to the list

Set account lockout policy

Windows NT includes an account lockout feature that will disable an account after an administrator-specified number of logon failures. To turn this feature on, use the Account Policy dialog in User Manager for Domains, and then select the Account lockout option. For maximum security, enable lockout after three to five failed attempts, reset the count after not less than 30 minutes, and set the lockout duration to "Forever (until admin unlocks)."

The Windows NT Server Resource Kit includes a tool that allows you to adjust some account properties that aren't accessible through the normal management tools. This tool, passprop.exe, allows you to lock out the administrator account. The /adminlockout switch allows the administrator account to be locked out

Configure the Administrator account

Because the Administrator account is built in to every copy of Windows NT, it presents a well-known objective for attackers. To make it more difficult to attack the Administrator account, do the following for the local Administrator account on each workstation:

  • Rename the account to a nonobvious name (e.g., not "admin," "root," etc.)

  • Establish a decoy account named "Administrator" with no privileges. Scan the event log regularly looking for attempts to use this account.

  • Enable account lockout on the real Administrator accounts by using the passprop utility

  • Disable the local computer's Administrator account.

Remove all unnecessary file shares

All unnecessary file shares on the system should be removed to prevent possible information disclosure and to prevent malicious users from leveraging the shares as an entry to the local system.

Set appropriate ACLs on all necessary file shares

By default, all users have Full Control permissions on newly created file shares. All shares that are required on the system should have the ACL restricted such that users have the appropriate share-level access (e.g., Everyone = Read).

NOTE: The NTFS file system must be used to set ACLs on individual files in addition to share-level permissions.

Install antivirus software and updates

It is imperative to install antivirus software and keep up-to-date on the latest virus signatures on all Internet and intranet systems.

Install the latest Service Pack

Each Service Pack for Windows NT includes all security fixes from previous Service Packs. Microsoft recommends that you keep up-to-date on Service Pack releases and install the correct Service Pack for your servers as soon as your operational circumstances allow. The current Service Pack, 6a, is available from the Microsoft Download Center:

Service Packs are also available through Microsoft Product Support. Information about contacting Microsoft Product Support is available at http://support.microsoft.com/support/contact/default.asp.

Install the appropriate post-Service Pack security hotfixes

Start by installing Windows Q29944 Post-Windows NT 4.0 Service Pack 6a Security Rollup (link is http://www.microsoft.com/NTServer/sp6asrp.asp), and then use one of the two following tools to determine the remaining hotfixes that should be applied:

  • Although it does not run natively on NT 4.0, consider running Microsoft's Baseline Security Analyzer (MBSA) (http://www.microsoft.com/technet/security/tools/mbsahome.mspx) from a Windows 2000 or XP machine to analyze multiple networked NT 4.0 machines at once. Besides revealing missing patches and updates, the MSBA will look for common vulnerabilities and recommend solutions.

Microsoft issues security bulletins through its Security Notification Service. When these bulletins recommend installation of a security hotfix, you should immediately download and install the hotfix on your member servers.

If you company is interested in C2 compliance, you should install the post-Service Pack 6a "C2 Update" hotfix, which makes a number of changes required to ensure complete C2 compliance. The C2 update is available from the Microsoft Download Center:

The update also can be ordered on various media through Microsoft Product Support Services.

Update the system Emergency Repair Disk

When you are finished with all critical updates and hotfixes, you should update the system's Emergency Repair Disk (ERD) to reflect these changes. For instructions, see "Update Repair Info" in Repair Disk Utility Help. (Run rdisk.exe, then click Help.)

THE INFORMATION PROVIDED IN THIS CHECKLIST IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.