1. Install Latest Service Pack and applicable hot-fixes
Install the latest recommended Microsoft Service Pack for the NT operating system. The applicable hot-fixes should also be installed. Generally not all hot-fixes are required. Also the order in which hot-fixes are installed is very important, as later hot-fixes sometimes supersede earlier hot-fixes.
2. Display a Legal Notice Before Log On
Windows NT can display a message box with the caption and text of your choice before a user logs on. Many organizations use this message box to display a warning message that notifies potential users that they can be held legally liable if they attempt to use the computer without having been properly authorized to do so. The absence of such a notice could be construed as an invitation, without restriction, to enter and browse the system.
The log on notice can also be used in settings (such as an information kiosk) where users might require instruction on how to supply a user name and password for the appropriate account.
To display a legal notice, use the Registry Editor to create or assign the following registry key values on the workstation to be protected:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Windows NT\Current Version\Winlogon
Name: LegalNoticeCaption
Type: REG_SZ
Value: Whatever you want for the title of the message box
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Windows NT\Current Version\Winlogon
Name: LegalNoticeText
Type: REG_SZ
Value: Whatever you want for the text of the message box
The changes take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes.
Example:
Welcome to the XYZ Information Kiosk
Log on using account name Guest and password XYZCorp.
Authorized Users Only
This system is for the use of authorized users only. Individuals using this computing system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may be monitored. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials.
3. Rename Administrative Accounts
It is a good idea to rename the built-in Administrator account to something less obvious. This powerful account is the one account that can never be locked out due to repeated failed log on attempts, and consequently is attractive to hackers who try to break in by repeatedly guessing passwords. By renaming the account, you force hackers to guess the account name as well as the password.
Make the following changes:
* Remove right "LOG ON FROM THE NETWORK" from Administrator's group
* Add right "LOG ON FROM THE NETWORK" for individuals who are administrators
* Enable auditing of failed login attempts
* Lock out users for more than 5 login failures
* Require password of at least 8 characters
4. Disable Guest Account
Disable Guest account and remove all rights (note: if using with Internet Information Server then ensure that web user account has permission to access appropriate directories and the right to "LOG ON LOCALLY"
Limited access can be permitted for casual users through the built-in Guest account. If the computer is for public use, the Guest account can be used for public log-ons. Prohibit Guest from writing or deleting any files, directories, or registry keys (with the possible exception of a directory where information can be left).
In a standard security configuration, a computer that allows Guest access can also be used by other users for files that they don't want accessible to the general public. These users can log on with their own user names and access files in directories on which they have set the appropriate permissions. They will want to be especially careful to log off or lock the workstation before they leave it.
5. Logging Off or Locking the Workstation
Users should either log off or lock the workstation if they will be away from the computer for any length of time. Logging off allows other users to log on (if they know the password to an account); locking the workstation does not. The workstation can be set to lock automatically if it is not used for a set period of time by using any 32-bit screen saver with the Password Protected option. For information about setting up screen savers, see Help.
* Install password protected screen saver that automatically starts if workstation is not used for 5-15 minutes
6. Allowing Only Logged-On Users to Shut Down the Computer
Normally, you can shut down a computer running Windows NT Workstation without logging on by choosing Shutdown in the Logon dialog box. This is appropriate where users can access the computer's operational switches; otherwise, they might tend to turn off the computer's power or reset it without properly shutting down Windows NT Workstation. However, you can remove this feature if the CPU is locked away. (This step is not required for Windows NT Server, because it is configured this way by default.)
To require users to log on before shutting down the computer, use the Registry Editor to create or assign the following Registry key value:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Windows NT\Current Version\Winlogon
Name: ShutdownWithoutLogon
Type: REG_SZ
Value: 0
The changes will take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes.
7. Hiding the Last User Name
By default, Windows NT places the user name of the last user to log on the computer in the User name text box of the Logon dialog box. This makes it more convenient for the most frequent user to log on. To help keep user names secret, you can prevent Windows NT from displaying the user name from the last log on. This is especially important if a computer that is generally accessible is being used for the (renamed) built-in Administrator account.
To prevent display of a user name in the Logon dialog box, use the Registry Editor to create or assign the following registry key value:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Windows NT\Current Version\Winlogon
Name: DontDisplayLastUserName
Type: REG_SZ
Value: 1
8. Restricting Anonymous network access to Registry
Windows NT version 4.0 Service Pack 3 includes a security enhancement that restricts anonymous (null session) logons when they connect to specific named pipes including the one for Registry.
There is a registry key value that defines the list of named pipes that are "exempt" from this restriction. The key value is:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: System\CurrentControlSet\Services\LanManServer\Parameters
Name: NullSessionPipes
Type: REG_MULTI_SZ
Value: Add or Remove names from the list as required by the configuration.
Please refer to Knowledge Base article Q143138 for more details.
9. Restricting Anonymous network access to lookup account names and network shares
Windows NT has a feature where anonymous logon users can list domain user names and enumerate share names. Customers who want enhanced security have requested the ability to optionally restrict this functionality. Windows NT 4.0 Service Pack 3 and a hotfix for Windows NT 3.51 provide a mechanism for administrators to restrict the ability for anonymous logon users (also known as NULL session connections) to list account names and enumerate share names. Listing account names from Domain Controllers is required by the Windows NT ACL editor, for example, to obtain the list of users and groups to select who a user wants to grant access rights. Listing account names is also used by Windows NT Explorer to select from list of users and groups to grant access to a share.
The registry key value to set for enabling this feature is:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: System\CurrentControlSet\Control\LSA
Name: RestrictAnonymous
Type: REG_DWORD
Value: 1.
This enhancement is part of Windows NT version 4.0 Service Pack 3. A hot fix for it is also provided for Windows NT version 3.51. Please refer to Knowledge Base article Q143474 for more details on this.
10. Enforcing strong user passwords
Windows NT 4.0 Service Pack 2 and later includes a password filter DLL file (Passfilt.dll) that lets you enforce stronger password requirements for users. Passfilt.dll provides enhanced security against "password guessing" or "dictionary attacks" by outside intruders.
Passfilt.dll implements the following password policy:
* Passwords must be at least six (6) characters long. (The minimum password length can be increased further by setting a higher value in the Password Policy for the domain).
* Passwords must contain characters from at least three (3) of the following four (4) classes:
Description Examples
English upper case letters A, B, C, ... Z
English lower case letters a, b, c, ... z
Westernized Arabic numerals 0, 1, 2, ... 9
Non-alphanumeric ("special characters") such as punctuation symbols
* Passwords may not contain your user name or any part of your full name.
These requirements are hard-coded in the Passfilt.dll file and cannot be changed through the user interface or registry. If you wish to raise or lower these requirements, you may write your own .dll and implement it in the same fashion as the Microsoft version that is available with Windows NT 4.0 Service Pack 2.
To use Passfilt.Dll, the administrator must configure the password filter DLL in the system registry on all domain controllers. This can be done as follows with the following registry key value:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: System\CurrentControlSet\Control\LSA
Name: Notification Packages
Type: REG_MULTI_SZ
Value: Add string "PASSFILT" (do not remove existing ones).
11. Disabling LanManager Password Hash Support
Windows NT supports the following two types of challenge/response authentication:
* LanManager (LM) challenge/response
* Windows NT challenge/response
To allow access to servers that only support LM authentication, Windows NT clients currently send both authentication types. Microsoft developed a patch that allows clients to be configured to send only Windows NT authentication. This removes the use of LM challenge/response messages from the network.
Applying this hot fix, configures the following registry key:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: System\CurrentControlSet\Control\LSA
Name: LMCompatibilityLevel
Type: REG_DWORD
Value: 0,1,2 (Default 0)
Setting the value to:
* 0 - Send both Windows NT and LM password forms.
* 1 - Send Windows NT and LM password forms only if the server requests it.
* 2 - Never send LM password form.
If a Windows NT client selects level 2, it cannot connect to servers that support only LM authentication, such as Windows 95 and Windows for Workgroups.
For more complete information on this hot fix, please refer to Knowledge Base article number Q147706.
12. Wiping the System Page File during clean system shutdown
Virtual Memory support of Windows NT uses a system page file to swap pages from memory of different processes onto disk when they are not being actively used. On a running system, this page file is opened exclusively by the operating system and hence is well-protected. However, systems that are configured to allow booting to other operating systems, may want to ensure that system page file is wiped clean when Windows NT shuts down. This ensures that sensitive information from process memory that may have made into the page file is not available to a snooping user. This can be achieved by setting up the following key:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: System\CurrentControlSet\Control\SessionManager\Memory Management
Name: ClearPageFileAtShutdown
Type: REG_DWORD
Value: 1
Note that, this protection works only during a clean shutdown, therefore it is important that untrusted users do not have ability to power off or reset the system manually.
13. Protecting the Registry
All the initialization and configuration information used by Windows NT is stored in the registry. Normally, the keys in the registry are changed indirectly, through the administrative tools such as the Control Panel. This method is recommended. The registry can also be altered directly, with the Registry Editor; some keys can be altered in no other way.
The Registry Editor supports remote access to the Windows NT registry. To restrict network access to the registry, use the Registry Editor to create the following registry key:
Hive: HKEY_LOCAL_MACHINE
Key: \CurrentcontrolSet\Control\SecurePipeServers
Name: \winreg
The security permissions set on this key define which users or groups can connect to the system for remote registry access. The default Windows NT Workstation installation does not define this key and does not restrict remote access to the registry. Windows NT Server permits only administrators remote access to the registry.
14. Secure EventLog Viewing
Default configuration allows guests and null log ons ability to view event logs (system, and application logs). Security log is protected from guest access by default, it is viewable by users who have "Manage Audit Logs" user right. The Event log services use the following key to restrict guest access to these logs:
Hive: HKEY_LOCAL_MACHINE
Key: \System\CurrentControlSet\Services\EventLog\[LogName]
Name: RestrictGuestAccess
Type REG_DWORD
Value: 1
Set the value for each of the logs to 1. The change takes effect on next reboot. Needless to say that you will have to change the security on this key to disallow everyone other than Administrators and System any access because otherwise malicious users can reset these values.
16. Secure Print Driver Installation
Registry key AddPrinterDrivers under HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\Print\Providers\LanMan Print Services\Servers, Key value AddPrinterDrivers (REG_DWORD) is used to control who can add printer drivers using the print folder. This key value should be set to 1 to enable the system spooler to restrict this operation to administrators and print operators (on server) or power users (on workstation).
Hive: HKEY_LOCAL_MACHINE
Key: System\CurrentcontrolSet\Control\Print\Providers\LanMan Print Services\Servers
Name: AddPrintDrivers
Type REG_DWORD
Value: 1
17. The Schedule Service (AT Command)
The Schedule service (also known as the AT command) is used to schedule tasks to run automatically at a preset time. Because the scheduled task is run in the context run by the Schedule service (typically the operating system's context), this service should not be used in a highly secure environment.
By default, only administrators can submit AT commands. To allow system operators to also submit AT commands, use the Registry Editor to create or assign the following registry key value:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Control\Lsa
Name: Submit Control
Type: REG_DWORD
Value: 1
There is no way to allow anyone else to submit AT commands. Protecting the registry as explained earlier restricts direct modification of the registry key using the registry editor. Access to the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Schedule should also be restricted to only those users/groups (preferrably Administrators only) that are allowed to submit jobs to the schedule service.
The changes will take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes.
18. Secure File Sharing
The native Windows NT file sharing service is provided using the SMB-based server and redirector services. Even though only administrators can create shares, the default security placed on the share allows Everyone full control access. These permissions are controlling access to files on down level file systems like FAT which do not have security mechanisms built in. Shares on NTFS enforce the security on the underlying directory it maps to and it is recommended that proper security be put via NTFS and not via the file sharing service.
Also note that the share information resides in the registry which also needs to be protected as explained in a section earlier.
* Service Pack 3 for Windows NT version 4.0 includes several enhancements to SMB based file sharing protocol. These are:It supports mutual authentication to counter man-in-the-middle attacks.
* It supports message authentication to prevent active message attacks.
These are provided by incorporating message signing into SMB packets which are verified by both server and client ends. There are registry key settings to enable SMB signatures on each side. To ensure that SMB server responds to clients with message signing only, configure the following key value:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: System\CurrentControlSet\Services\LanManServer\Parameters
Name: RequireSecuritySignature
Type: REG_DWORD
Value: 1
Setting this value ensures that the Server communicates with only those clients that are aware of message signing. Note that this means that installations that have multiple versions of client software, older versions will fail to connect to servers that have this key value configured.
Similarly, security conscious clients can also decide to communicate with servers that support message signing and no one else.
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: System\CurrentControlSet\Services\Rdr\Parameters
Name: RequireSecuritySignature
Type: REG_DWORD
Value: 1
Note that setting this key value implies that the client will not be able to connect to servers which do not have message signing support.
Please refer to Knowledge Base article Q161372 for further details on SMB message signing enhancements.
Windows NT version 4.0 Service Pack 3 also includes another enhancement to SMB file sharing protocol such that by default you are unable to connect to SMB servers (such as Samba or Hewlett-Packard (HP) LM/X or LAN Manager for UNIX) with an unencrypted (plain text) password. This protects from sending clear text forms of passwords over the wire. Please refer to Knowledge base article Q166730 if you have any reasons to allow clients to send unencrypted passwords over the wire.
Additionally, customers may want to delete the administrative shares ($ shares) if they are not needed on an installation. This can be accomplished using "net share" command. For example:
C:\> net share admin$ /d
19. Auditing
Auditing can inform you of actions that could pose a security risk and also identify the user accounts from which audited actions were taken. Note that auditing only tells you what user accounts were used for the audited events. If passwords are adequately protected, this in turn indicates which user attempted the audited events. However, if a password has been stolen or if actions were taken while a user was logged on but away from the computer, the action could have been initiated by someone other than the person to whom the user account is assigned
When you establish an audit policy you'll need to weigh the cost (in disk space and CPU cycles) of the various auditing options against the advantages of these options. You'll want to at least audit failed log on attempts, attempts to access sensitive data, and changes to security settings. Here are some common security threats and the type of auditing that can help track them:
20. Threat Action
Hacker-type break-in using random passwords Enable failure auditing for log on and log off events.
Break-in using stolen password Enable success auditing for log on and log off events. The log entries will not distinguish between the real users and the phony ones. What you are looking for here is unusual activity on user accounts, such as log ons at odd hours or on days when you would not expect any activity.
Misuse of administrative privileges by authorized users Enable success auditing for use of user rights; for user and group management, for security policy changes; and for restart, shutdown, and system events. (Note: Because of the high volume of events that would be recorded, Windows NT does not normally audit the use of the Backup Files And Directories and the Restore Files And Directories rights. Appendix B, "Security In a Software Development Environment," explains how to enable auditing of the use of these rights.)
Virus outbreak Enable success and failure write access auditing for program files such as files with .exe and .dll extensions. Enable success and failure process tracking auditing. Run suspect programs and examine the security log for unexpected attempts to modify program files or creation of unexpected processes. Note that these auditing settings generate a large number of event records during routine system use. You should use them only when you are actively monitoring the system log.
Improper access to sensitive files Enable success and failure auditing for file- and object-access events, and then use File Manager to enable success and failure auditing of read and write access by suspect users or groups for sensitive files.
Improper access to printers Enable success and failure auditing for file- and object-access events, and then use Print Manager to enable success and failure auditing of print access by suspect users or groups for the printers.
21. Enabling System Auditing
Enabling system auditing can inform you of actions that pose security risks and possibly detect security breaches.
To activate security event logging, follow these steps:
1. Log on as the administrator of the local workstation.
2. Click the Start button, point to Programs, point to Administrative Tools, and then click User Manager.
3. On the Policies menu, click Audit.
4.Click the Audit These Events option.
5. Enable the options you want to use. The following options are available:
• Log on/Log off: Logs both local and remote resource logins.
• File and Object Access: File, directory, and printer access.
• Note: Files and folders must reside on an NTFS partition for security logging to be enabled. Once the auditing of file and object access has been enabled, use Windows NT Explorer to select auditing for individual files and folders.
• User and Group Management: Any user accounts or groups created, changed, or deleted. Any user accounts that are renamed, disabled, or enabled. Any passwords set or changed.
• Security Policy Changes: Any changes to user rights or audit policies.
• Restart, Shutdown, And System: Logs shutdowns and restarts for the local workstation.
• Process Tracking: Tracks program activation, handle duplication, indirect object access, and process exit.
6. Click the Success check box to enable logging for successful operations, and the Failure check box to enable logging for unsuccessful operations.
7.Click OK.
Note that Auditing is a "detection" capability rather than "prevention" capability. It will help you discover security breaches after they occur and therefore should always be consider in addition to various preventive measures.
