Logo.jpg (26503 bytes)

 

Windows NT 4.0 Server Security

Security Checklists

Prepared by

Craig S. Wright

Last update: Friday, 15 January 1999

Note: This document is a PERMANENT work in progress

 

TABLE OF CONTENTS

General Security Issues

C2 Security

The National Computer Security Center (NCSC) is the United States government agency responsible for performing software product security evaluations. These evaluations are carried out against a set of requirements outlined in the NCSC publication Department of Defense Trusted Computer System Evaluation Criteria, which is commonly referred to as the "Orange Book."

Windows NT has been successfully evaluated by the NCSC at the C2 security level as defined in the Orange Book, which covers the base operating system.

In addition, Windows NT is currently under evaluation for its networking component of a secure system in compliance to the NCSC's "Red Book." The Red Book is an interpretation of the Orange Book as applies to network security.

Some of the most important requirements of C2-level security are the following:

Physical Security Considerations

Use a surge protector or power conditioner to protect the computer and its peripherals from power spikes. Also, perform regular disk scans and defragmentation to isolate bad sectors and to maintain the highest possible disk performance.

The computer should be protected as any valuable equipment would be. Generally, this involves keeping the computer in a building that is locked to unauthorised users, as most homes and offices are. In some instances you might want to use a cable and lock to secure the computer to its location. If the computer has a physical lock, you can lock it and keep the key in a safe place for additional security. However, if the key is lost or inaccessible, an authorised user might be unable to work on the computer. You might also want to establish procedures for moving or repairing the computer so that the computer or its components cannot be taken under false pretences. In addition, you might want to examine the physical link provided by your computer network, and in some cases use controls built in to certain hardware platforms to restrict who can turn on the computer.

No computer will ever be completely secure if people other the than authorised user can physically access it. For maximum security on a computer that is not physically secure (locked safely away), follow all or some of the following security measures:

  Controlling Access to the Power Switch

You might choose to keep unauthorised users away from the power or reset switches on the computer, particularly if your computer's rights policy denies them the right to shut down the computer. The most secure computers (other than those in locked and guarded rooms) expose only the computer's keyboard, monitor, mouse, and (when appropriate) printer to users. The CPU and removable media drives can be locked away where only specifically authorised personnel can access them.

On many hardware platforms, the system can be protected using a power-on password. A power-on password prevents unauthorised personnel from starting an operating system other than Windows NT, which would compromise system security. Power-on passwords are a function of the computer hardware, not the operating system software. Therefore the procedure for setting up the power-on password depends on the type of computer and is available in the vendor's documentation supplied with the system.

It should be noted that this prevents automatic reboot on system failure or crash.

Displaying 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 organisations 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 authorised to do so. The absence of such a notice could be construed as an invitation, without restriction, to enter and browse the system.

 

Example Here

 

Preventing access to the page file

  To be completed

   

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 Log on 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 Log on 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

Restricting the Boot Process

Most personal computers today can start a number of different operating systems. For example, even if you normally start Windows NT from the C: drive, someone could select another version of Windows on another drive, including a floppy drive or CD-ROM drive. If this happens, security precautions you have taken within your normal version of Windows NT might be circumvented.

In general, you should install only those operating systems that you want to be used on the computer you are setting up. For a highly secure system, this will probably mean installing one version of Windows NT. However, you must still protect the CPU physically to ensure that no other operating system is loaded. Depending on your circumstances, you might choose to remove the floppy drive or drives. In some computers, you can disable booting from the floppy drive by setting switches or jumpers inside the CPU. If you use hardware settings to disable booting from the floppy drive, you might want to lock the computer case (if possible) or lock the machine in a cabinet with a hole in the front to provide access to the floppy drive. If the CPU is in a locked area away from the keyboard and monitor, drives cannot be added or hardware settings changed for the purpose of starting from another operating system. Another simple setting is to edit the boot.ini file such that the boot timeout is 0 seconds; this will make hard for the user to boot to another system if one exists.

Other hardware configurations, such as firmware setup, boot password, and power-on password are also available on the latest hardware to control the boot process and should be appropriately investigated and used.

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 Log on 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.

Controlling Access to Removable Media

By default, Windows NT allows any program to access files on floppy disks and CDs. In a highly secure, multi-user environment, you might want to allow only the person interactively logged on to access those devices. This allows the interactive user to write sensitive information to these drives, confident that no other user or program can see or modify that data.

When operating in this mode, the floppy disks and/or CDs on your system are allocated to a user as part of the interactive log on process. These devices are automatically freed for general use or for reallocation when that user logs off. Because of this, it is important to remove sensitive data from the floppy or CD-ROM drives before logging off.

Note: Windows NT allows all users access to the tape drive, and therefore any user can read and write the contents of any tape in the drive. In general this is not a concern, because only one user is interactively logged on at a time. However, in some rare instances, a program started by a user can continue running after the user logs off. When another user logs on and puts a tape in the tape drive, this program can secretly transfer sensitive data from the tape. If this is a concern, restart the computer before using the tape drive.

To Allocate Floppy Drives During Log On

Use the Registry Editor to create or assign the following registry key value:

Hive:HKEY_LOCAL_MACHINE\SOFTWARE
Key:\Microsoft\WindowsNT\CurrentVersion\Winlogon
Name:AllocateFloppies
Type:REG_SZ
Value:1

If the value does not exist, or is set to any other value, then floppy devices will be available for shared use by all processes on the system.

This value will take effect at the next log on. If a user is already logged on when this value is set, it will have no effect for that log on session. The user must log off and log on again to cause the device(s) to be allocated.

To Allocate CD-ROMs During Log On

Use the Registry Editor to create or assign the following registry key value:

Hive:HKEY_LOCAL_MACHINE\SOFTWARE
Key:\Microsoft\WindowsNT\CurrentVersion\Winlogon
Name:AllocateCDRoms
Type:REG_SZ
Value:1

If the value does not exist, or is set to any other value, then CD-ROM devices will be available for shared use by all processes on the system.

This value will take effect at the next log on. If a user is already logged on when this value is set, it will have no effect for that log on session. The user must log off and log on again to cause the device(s) to be allocated.

Securing Base System Objects

To enable stronger protection on base objects, add the following value to the registry key

HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Control\SessionManager:
Name: ProtectionMode
Type: REG_DWORD
Value: 1

This registry setting informs the Windows NT Session Manager that security on the base system objects should be at C2 security level. Please refer to Appendix D of the Windows NT Resource Kit, Version 4.0 Update Guide for the impact of this setting.

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. 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.

Operating System Patches

Installed latest patches:

This includes service packs, hotfixes and all application level requirements.

System stripped to minimum running status (no compilers, unnecessary apps, etc).

Network Security

Network Security Issues

When you put a computer on a network, you add an access route to the computer, and you'll want that route to be secure. User validation and protections on files and other objects are sufficient for standard-level security, but for high-level security you'll need to make sure the network itself is secure, or in some cases isolate the computer completely.

The two risks from network connections are other network users and unauthorised network taps. If everyone on the network needs to access your secure computer, you will probably prefer to include the computer in the network to make it easier for these people to access data on the computer.

If the network is entirely contained in a secure building, the risk of unauthorised taps is minimised or eliminated. If the cabling must pass through unsecured areas, use optical fibre links rather than twisted pair to foil attempts to tap the wire and collect transmitted data.

Be aware of the security issues involved in providing access to — and from — the Internet community. Chapter 2, "Server Security on the Internet," in the Windows NT Server Internet Guide contains information on using network topology to provide security.

NetBios Access from the Internet

For NT systems that have direct Internet connectivity and NetBios, there are two configuration options:

A Windows NT system with direct Internet connectivity needs to be secured with respect to other services besides NetBios access, specifically Internet Information Server. Please refer to the Microsoft Internet Information Server: Security Overview white paper for details on this area.

IP Type Constraints

An option to enable IP filtering is to apply the steelhead routing engine to the server (see attached). The routing engine does not need to be used, but the service gives the user advanced filtering options for both incoming and outgoing packets. Both the steelhead filtering and native network neighbourhood packet filters need to be applied. The services should be restricted to individual machines if needed.

IP types to allow:

TCP allowed:

UDP allowed:

Disallow Source:

Registry Checklist

Change the following Registry permissions for "Everyone" to READ ONLY

HKEY_LOCAL_MACHINE\

HKEY_LOCAL_MACHINE\ Software\Microsoft\WindowsNT\CurrentVersion\

HKEY_LOCAL_MACHINE\ Software\Windows3.1MigrationStatus\

HKEY_CLASSES_ROOT \

Then add the following -

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\

Make

In user rights Shutdown Global / Local Group

Grant rights to Administrators and those with need of this privilege

Use NTFS, Not FAT

NT File System (NTFS) volumes can apply access-control lists (ACLs) to files and directories; these controls work in conjunction with permissions on shared directories. A file allocation table (FAT) volume supports only the latter, share-level form of security. For safety's sake, it's always the best thing to layer multiple defenses whenever they're available, so you should always use NTFS on Internet-connected Windows NT machines.

If NTFS ACLs give a network user full access to a partition but share-level permissions grant only read access, then the effective access is read only. Windows NT takes the intersection of NTFS ACLs and share permissions.

Directory Permissions To Change

Do these in the order shown:

(where %system% is C:\WINNT\)

C:\ Do all sub-directories

C:\WINNT\ Do all sub-directories

C:\WINNT\SYSTEM\SYSTEM32\ Do all sub-directories

C:\WINNT\REPAIR\ Do all sub-directories

C:\WINNT\SYSTEM32\CONFIG\ Do all sub-directories

C:\WINNT\SYSTEM32\SPOOL\ Do all sub-directories

C:\WINNT\SYSTEM32\DHCP\ Do all sub-directories

C:\WINNT\SYSTEM32\RAS\C:\WINNT\SYSTEM32\OS2\

C:\WINNT\SYSTEM32\WINS\

C:\BOOT.INI

C:\NTDLR

C:\NTDETECT.COM

C:\CONFIG.SYS

C:\AUTOEXEC.BAT

C:\TEMP Do all sub-directories

C:\BIN

C:\DEV

C:\DOS

C:\WIN32APP Do all sub-directories

C:\USERS – Administrators Group Do all sub-directories

C:\USERS – Owning Group Do all sub-directories

C:\USERS\DEFAULT\ Do all sub-directories

C:\INETPUB\

C:\WWWROOT\

C:\GOPHERROOT\

C:\WWWROOT\SCRIPTS\

C:\FTPROOT\

RIGHTS POLICIES

Bypass Traverse Checking

Administrators

System Users

Debug Programs

Remove Administrators

Shutdown The System

Remove Everyone and Users

Allow individual users based on machine use and rights

Access this Computer from the Network

change Everyone to users

add www_guest if needed

remove administrators from Internet hosts

Log on Locally

Remove everyone and guests

Remove users on NT server

ONLY administrator group on servers

Act as part of the operating system

ONLY as needed (eg SNA)

Add workstations to the domain

Domain Administrators ONLY

Backup Files and directories

Administrators

Backup Operators

Server Operators

Change System Time

Administrators

Server Operators

Create a pagefile

administrators

Create a token Object

Specific User only

Create permanent shared objects

Specific Administrators only

Force Shutdown from remote computer

Administrators only

Generate Security Audits

SNA

Security Administrator (single admin not group)

Increase Quotas

Administrators

Increase scheduling priority

Administrators

Print Managers

Load and unload device drivers

Single Administrator (Master) only

Lock pages in memory

as needed only

Log on as a batch job

SQLExec

Log on as a service

SNA

Manage Auditing and security log

Security Administrators

Modify firmware environment vales

Administrators

Profile Single process

Administrators

Profile System Performance

Administrators

Replace a process level token

Specific Administrator only

Restore files and directories

Administrators

Backup Operators

Server Operators

Take ownership of files or other objects

administrators

Enforce system times for certain users. For users not able to logon, disconnect when logon hours expire.

Auditing

Failure

Success

Registry Security issues

Set protections on certain keys in the registry, as detailed here.

By default, protections are set on the various components of the registry that allow work to be done while providing standard-level security. For high-level security, you might want to assign access rights to specific registry keys.

This should be done with caution, because programs that the users require to do their jobs often need to access certain keys on the users' behalf. For more information, see Chapter 24, "Registry Editor and Registry Administration."

For each of the keys listed below, make the following change:
Access allowed
Everyone Group QueryValue, Enumerate Subkeys,
Notify and Read Control

In the HKEY_LOCAL_MACHINE on Local Machine dialog:

\Software

This change is recommended. It locks the system in terms of who can install software. Note: it is not recommended that the entire subtree be locked using this setting, because that can render certain software unusable.

\Software\Microsoft\RPC (and its subkeys)

This locks the RPC services.

\Software\Microsoft\Windows NT\ CurrentVersion

\Software\Microsoft\Windows NT\ CurrentVersion\Profile List

\Software\Microsoft\Windows NT\ CurrentVersion\AeDebug

\Software\Microsoft\Windows NT\ CurrentVersion\Compatibility

\Software\Microsoft\Windows NT\ CurrentVersion\Drivers

\Software\Microsoft\Windows NT\ CurrentVersion\Embedding

\Software\Microsoft\Windows NT\ CurrentVersion\Fonts

\Software\Microsoft\Windows NT\ CurrentVersion\FontSubstitutes

\Software\Microsoft\Windows NT\ CurrentVersion\Font Drivers

\Software\Microsoft\Windows NT\ CurrentVersion\Font Mapper

\Software\Microsoft\Windows NT\ CurrentVersion\Font Cache

\Software\Microsoft\Windows NT\CurrentVersion\ GRE_Initialize

\Software\Microsoft\Windows NT\ CurrentVersion\MCI

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

\Software\Microsoft\Windows NT\ CurrentVersion\PerfLib

Consider removing Everyone:Read access on this key. This allows remote users to see performance data on the machine. Instead you could give INTERACTIVE:Read Access, which will allow only interactively logged on user access to this key, besides administrators and system.

\Software\Microsoft\Windows NT\ CurrentVersion\Port (and all subkeys)

\Software\Microsoft\Windows NT\ CurrentVersion\Type1 Installer

\Software\Microsoft\Windows NT\ CurrentVersion\WOW (and all subkeys)

\Software\Microsoft\Windows NT\ CurrentVersion\Windows3.1MigrationStatus (and all subkeys)

\System\CurrentControlSet\Services\LanmanServer\ Shares

\System\CurrentControlSet\Services\ UPS

Note that besides setting security on this key, it is also required that the command file (if any) associated with the UPS service is appropriately secured, allowing Administrators: Full Control, System: Full Control only.

In the HKEY_CLASSES_ROOT on Local Machine dialog:

\HKEY_CLASSES_ROOT (and all subkeys)

In the HKEY_USERS on Local Machine dialog:

\.DEFAULT

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
Type: REG_DWORD
Value:1

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.

To turn on auditing for RAS, use the regedit utility to set the key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\Parameters\Logging

to 1, then restart RAS.

Secure EventLog Viewing

Default configuration allows guests and null log ons ability to view event logs (system, security, and application logs). The Event log services use the following key to restrict guest access to these logs:

MACHINE\System\CurrentControlSet\Services\EventLog\[LogName]\RestrictGuestAccess
where LogName identifies one of the three event logs.

Set the value for each of the logs to 1. The change takes effect on next reboot. Needless to say, 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.  

User Permissions Issues

Protecting Files and Directories

Among the files and directories to be protected are those that make up the operating system software itself. The standard set of permissions on system files and directories provide a reasonable degree of security without interfering with the computer's useability. For high-level security installations, however, you might want to additionally set directory permissions to all subdirectories and existing files, as shown in the following list, immediately after Windows NT is installed. Be sure to apply permissions to parent directories before applying permissions to subdirectories.

User Rights

To view these files in File Manager, 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.

It is also highly advisable that Administrator scans the permissions on various partitions on the system and ensures that they are appropriately secured for various user accesses in their environment.

Secure Print Driver Installation

Registry key AddPrinterDrivers, under

HKEY_LOCAL_MACHINE\System\
CurrentControlSet\ Control\Print\Providers\
LanMan Print Services\Servers

is used to control who can add printer drivers using the print folder. This key 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).

Auditing issues

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:    

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 phoney 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 authorised 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.

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:
    1. Log on/Log off: Logs both local and remote resource log ons.
    2. File and Object Access: File, directory, and printer access.
    3. 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.
    4. 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.
    5. Security Policy Changes: Any changes to user rights or audit policies.
    6. Restart, Shutdown, and System: Logs shutdowns and restarts for the local workstation.
    7. 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 considered in addition to various preventive measures.

Auditing Base Objects

To enable auditing on base system objects, add the following key value to the registry key

HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Control\Lsa:
Name: AuditBaseObjects
Type: REG_DWORD
Value: 1

Note that simply setting this key does not start generating audits. The administrator will need to turn auditing on for the "Object Access" category using User Manager. This registry key setting tells Local Security Authority that base objects should be created with a default system audit control list.

Auditing of Privileges

Certain privileges in the system are not audited by default, even when auditing on privilege use is turned on. This is done to control the growth of audit logs. The privileges are:

  1. Bypass traverse checking (given to everyone)
  2. Debug programs (given only to administrators)
  3. Create a token object (given to no one)
  4. Replace process level token (given to no one)
  5. Generate Security Audits (given to no one)
  6. Backup files and directories (given to administrators and backup operators)
  7. Restore files and directories (given to administrators and backup operators)

1 is granted to everyone, so is meaningless from an auditing perspective.

2 is not used in a working system and can be removed from the administrators group.

3, 4, and 5 are not granted to any user or group; they are highly sensitive privileges and should not be granted to anyone.

However, 6 and 7 are used during normal system operations and are expected to be used. To enable auditing of these privileges, add the following key value to the registry key

HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Control\Lsa:
Name: FullPrivilegeAuditing
Type: REG_BINARY
Value: 1

Note that these privileges are not audited by default, because backup and restore is a frequent operation and this privilege is checked for every file and directory backed up or restored, which can lead to thousands of audits filling up the audit log in no time. Carefully consider turning on auditing on these privilege uses.

Shutdown Option on Full Audit Log

In a C2-configured system, the auditing system of Windows NT provides an option to the administrator to shut down the system when the security audit log is filled up. To enable this, use the following key value in the registry key

HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Control\Lsa:
Name: CrashOnAuditFail
Type: REG_DWORD
Value: 1

With this setting, the system will shut itself down when audit log full is detected. The value in the registry is reset to 2. When the system is rebooted, it only allows the administrators to log on to the machine (locally or remotely). They will be required to clean the audit log (or archive it), reset the value to 1, and reboot the system before any other user is allowed to log on.

Ftpd and anonymous ftp

  FTP Security Issues

Windows NT comes with a standard Internet service called file transfer protocol (FTP). A common use of FTP is to allow public file access via anonymous log on. When configuring FTP server, the administrator assigns the server a user account for anonymous log ons and a default home directory. The default anonymous user account for FTP is GUEST. This should be changed to a different user account and should have a password. Also, this account should not be member of any privileged groups, so that the only default group that shows up in the security token during log on is Everyone. The account should not be allowed "Logon on Locally" user right to restrict "insider attacks."

The home directory parameter should be configured carefully. FTP server exports entire disk partitions. The administrator can only configure which partitions are accessible via FTP, but not which directories on that partition. Therefore, a user coming via FTP can move to directories "above" the home directory. In gel it is recommended that if FTP service needs to run on a system, it is best to assign a complete disk partition as the FTP store, and to make only that partition accessible via FTP.  

Password and account security

Password Security Issues

User Accounts and Groups

With standard security, a user account (user name) and password should be required in order to use the computer. You can establish, delete, or disable user accounts with User Manager, which is in the Administrative Tools program group. User Manager also allows you to set password policies and organise user accounts into Groups.

Note: Changes to the Windows NT computer user rights policy take effect when the user next logs on.

Administrative Accounts vs. User Accounts

Use separate accounts for administrative activity and general user activity. Individuals who do administrative work on the computer should each have two user accounts on the system: one for administrative tasks, and one for general activity. To avoid accidental changes to protected resources, the account with the least privilege that can do the task at hand should be used. For example, viruses can do much more damage if activated from an account with administrator privileges.

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.

Logging On

All users should always press CTRL+ALT+DEL before logging on. Programs designed to collect account passwords can appear as a log on screen that is there waiting for you. By pressing CTRL+ALT+DEL you can foil these programs and get the secure log on screen provided by Windows NT.

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.

Passwords

Anyone who knows a user name and the associated password can log on as that user. Users should take care to keep their passwords secret. Here are a few tips:

General Startup and shutdown scripts NTFS (not FAT32) used exclusively External file systems/devices File Permissions Files run by system/administrator Application ownership Checksums stored  

File System Security Issues

Protecting Files and Directories

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. It is recommended that proper security be put via NTFS and not via the file sharing service.

The NTFS file system provides more security features than the FAT system and should be used whenever security is a concern. The only reason to use FAT is for the boot partition of an ARCcompliant RISC system. A system partition using FAT can be secured in its entirety using the Secure System Partition command on the Partition menu of the Disk Administrator utility.

With NTFS, you can assign a variety of protections to files and directories, specifying which groups or individual accounts can access these resources in which ways. By using the inherited permissions feature and by assigning permissions to groups rather than to individual accounts, you can simplify the chore of maintaining appropriate protections. For more information, see Chapter 4, "Managing Shared Resources and Resource Security" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

For example, a user might copy a sensitive document to a directory that is accessible to people who should not be allowed to read the document, thinking that the protections assigned to the document in its old location would still apply. In this case the protections should be set on the document as soon as it is copied, or else it should be first moved to the new directory, then copied back to the original directory.

On the other hand, if a file that was created in a protected directory is being placed in a shared directory so that other users can read it, it should be copied to the new directory; or if it is moved to the new directory, the protections on the file should be promptly changed so that other users can read the file.

When permissions are changed on a file or directory, the new permissions apply any time the file or directory is subsequently opened. Users who already have the file or directory open when you change the permissions are still allowed access according to the permissions that were in effect when they opened the file or directory.

Backups

Regular backups protect your data from hardware failures and honest mistakes, as well as from viruses and other malicious mischief. The Windows NT Backup utility is described in Chapter 6, "Backing Up and Restoring Network Files" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Obviously, files must be read to be backed up, and they must be written to be restored. Backup privileges should be limited to administrators and backup operators--people to whom you are comfortable giving read and write access on all files.

Protecting the Registry

All the initialisation and configuration information used by Windows NT is stored in the registry. Normally, the keys in the registry are changed indirectly, through 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
Type: REG_DWORD
Value:1

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.

The Backup utility included with Windows NT allows you to back up the registry as well as files and directories.

Note: Registry Editor should be used only by individuals who thoroughly understand the tool, the registry itself, and the effects of changes to various keys in the registry. Mistakes made in the Registry Editor could render part or all of the system unusable.

Security specific to Vendor Applications

 

Application Security Issues with FrontPage & IIS Security

Security is a primary consideration on the Internet as well as corporate intranets. Web server administrators must manage web servers in the context of unintentional or malicious actions on the part of end users. Web authors can invest a great deal of time and effort to create web sites that not only need to be protected from damage from other authors and browsers, but also from unauthorised browsing.

Default Settings

When installed with its default settings, FrontPage 97 provides the web server administrator and the FrontPage authors with a secure web-authoring environment. During installation of the Server Extensions, the web administrator is warned of circumstances that may result in an unsecured installation, such as the installation of web content on a FAT partition.

To ensure a secure installation, some capabilities, such as the marking of CGI scripts and ISAPI extensions as executable are disabled by default. These capabilities are explained below.

FrontPage Security Explained

FrontPage 97 is a web-authoring tool that utilises the security facilities of the web server and operating system. To ensure security when a web administrator actively manages web server security with FrontPage, both the IIS and Windows NT® security models must be understood. As described below, FrontPage itself does not restrict access to webs. Instead, FrontPage manipulates the access control provided by the Microsoft Internet Information Server to implement the FrontPage security model.

FrontPage Security Model

FrontPage 97 presents a simple, powerful security model adequate for the needs of most web authors. There are three kinds of users defined for every FrontPage Web: administrators, authors and browsers (end users). The list of administrators, authors and browsers is defined on a per-web basis. All FrontPage sub-webs either inherit the permissions (list of administrators, authors and browsers) of the FrontPage root web or use their own, unique permissions. In the FrontPage Server Administrator under the Authoring button, you can require SSL (Secure Socket Layer) to author a web by setting the "Require SSL for Authoring" check-box.

With FrontPage, administrators can perform the tasks of creating, renaming and deleting FrontPage Webs. Administrators can also add and remove administrators, authors and browsers. These operations either require the modification of the web server’s configuration or the file system permissions. Initially, all users or groups with Administrator privileges for Windows NT are also administrators in FrontPage. Additional FrontPage administrators can be added to FrontPage Webs when the Server Extensions are installed on the web or later on. FrontPage administrators do not also have to be Windows NT administrators. The only required Windows NT Administrator account is the one that installs the extensions initially. All administrators can also author and browse their webs.

FrontPage authors do the creative work of authoring the web content. Authors can create, edit, move, rename and delete pages and directories within their FrontPage Webs. The only operation authors can perform that updates the web server’s configuration and file systems permissions is to mark directories executable. Setting the NoExecutableCgiUpload parameter in the FrontPage configuration file can disable this capability. All authors can browse their webs.

Each FrontPage Web can either permit a finite list of authorised groups or users to browse the web or allow anyone to browse the web anonymously. By default, anyone can anonymously browse a FrontPage Web when it is created. Browsing a FrontPage Web can result in the execution of the "browse-time" WebBot components (search, discussion group and save results). The author can also configure IIS to require an SSL connection to browse their Web.

NOTE : Administer FrontPage Authors through Windows NT Groups

One of the easiest ways to manage your FrontPage authors is to create a group for each FrontPage web. Once FrontPage is told to allow that group to author the web, the addition of a new author can be performed completely from the Windows NT User Manager. Just create the author’s account, add it to the appropriate group and you’re done! The disadvantage of this technique is that the Windows NT User Manager is not available from a remote machine over HTTP.

IIS Security

IIS relies on the Windows NT File System (NTFS) to implement restrictions on web resources. FrontPage Extensions simply write the appropriate level of NTFS permissions for IIS to allow or deny browsers, authors, or administrators. IIS uses two user authentication schemes to identify users as necessary. IIS also supports a facility known as virtual directories, which play a role in restricting the read and execute access to web content.

User Authentication

Each HTTP request from a browser or the FrontPage Explorer runs under a user account on the Windows NT operating system. The operations that are performed during the execution of that HTTP request are limited by the capabilities granted to that user account on the Windows NT Server.

For the HTTP request to successfully execute, the appropriate Windows NT user account must be identified. The request is first attempted as the anonymous user, IUSR_<hostname> where <hostname> is the name of your Windows NT machine running your web server. But, if that execution fails to have sufficient access to complete, then user authentication is performed to allow the remote user to identify themselves via the techniques of Basic Authentication or Windows NT Challenge/Response.

By default Webs created with FrontPage can be browsed by anyone anonymously. When the "Allow Anonymous" option is enabled, IIS runs the HTTP request under a special, proxy user called IUSR_<hostname>. The IIS administrator can change the anonymous user. If the IUSR_<hostname> user has insufficient privileges, or the "Allow Anonymous" option is disabled, the user will be required to identify themselves or access will be denied.

To give a user permission to access a web, they must have a Windows NT user account on a machine that is accessible and trusted by the machine running the web server. Users can then identify themselves by entering the user name and password associated with the Windows NT user. This interaction is called user authentication. There are two user authentication techniques supported by IIS: Basic Authentication and Challenge/Response.

Basic Authentication is the authentication method supported by the majority of web servers on the Internet. When using Basic Authentication, the browser (or the FrontPage Explorer or Editor) prompts the user for their user name and password. The user name and password are then transmitted across HTTP (lightly encoded using a technique known as UUencoding). IIS will then use this user name and password and authenticate the user as the corresponding Windows NT user. One security risk of using Basic Authentication is that user names and passwords are transmitted across the network in an easily decoded format. During installation of the FrontPage 97 Server Extensions, FrontPage 97 recommends that you disable Basic Authentication, if it is enabled. However, if your web site must support authoring by FrontPage 1.1 clients, then you must keep Basic Authentication enabled. Furthermore, Basic Authentication is the only authentication technique that works through a firewall via a proxy server.

Windows NT Challenge/Response is a more secure authentication method than Basic Authentication. In Challenge/Response, the browser attempts to use the current user’s credentials. If those credentials are rejected, Challenge/Response will also prompt the user for their user name and password. When Challenge/Response is used, the user name and password are securely encrypted in a multiple transaction interaction between the browser and server. This interaction is secure against clever network snoopers that attempt to break into systems by simply replaying network traffic between a client and a server. Another benefit of using Challenge/Response is that if a user has logged on as a domain user on their local machine, they won’t have to authenticate themselves again when authoring against a remote machine in that domain.

There are three limitations of Windows NT Challenge/Response. Challenge/Response Authentication cannot be performed through a firewall via a proxy. In this case, users must use Basic Authentication. All browsers may not support Challenge/Response. Finally, Challenge/Response does not support "delegation" to third party servers.

Tip : Basic Authentication vs. Windows NT Challenge/Response

The exclusive use of Windows NT Challenge/Response for user authentication is required. When installed, FrontPage will configure the Internet Information Server 2.0 to use Challenge/Response.

Virtual Directories

Virtual directories are web server constructs that map the URL space onto the file system of the local machine. They control read and execute access to specified directories within the file system as well as allow seemingly related URLs to refer to non-contiguous content areas on the file system.

FrontPage automatically manages the use of virtual directories for executable and unreadable directories. When installed, FrontPage sets up virtual directories to mark the directories containing the FrontPage Server Extensions as executable. In addition, authors have the privilege of marking directories as executable to allow the directories to store such executable objects as:

Authors cannot execute their own CGI Scripts and ISAPI Extensions without the web server administrator setting the AllowExecutableScripts FrontPage configuration parameter. FrontPage also manages the use of virtual directories to mark its hidden directories as not readable. FrontPage marks its private directories as unreadable to avoid end users from browsing them.

Virtual directories cannot be used to merge non-contiguous content areas in FrontPage Webs. FrontPage 97 does not support their use for this purpose.

Tip : Non-contiguous Content Areas

FrontPage 97 does not support Non-contiguous content areas.

Windows NT Security Model

Windows NT implements the concepts of users and groups, assigns them privileges and grants them access to system resources. IIS (and consequently FrontPage) relies on the user accounts set up under Windows NT to implement browsing access control. FrontPage modifies Windows NT file permissions to manipulate IIS into enforcing author and administration access control. Windows NT also supports two types of file partitions: NTFS and FAT file partitions.

File Permissions

In an NTFS partition, each file has an ACL (Access Control List) which describes the users and groups that are permitted to read, write and execute the file. There are also directory ACLs that specify user access to the directory and the initial permissions to assign to new files created in the directory.

Each root web managed by FrontPage contains a copy of the admin.dll, author.dll and shtml.dll ISAPI DLLs. The ACL for the admin.dll represents the list of FrontPage administrators, the ACL for the author.dll, the authors for that web and the ACL for shtml.dll, the browsers for that web. Anonymous browsing for a web is implemented by giving the IUSR_<hostname> user (or a group that they belong to) execute privileges on shtml.dll as well as read access the rest of the content area. Note that all permissions are cumulative, and that all authors must also have browse permission, and all administrators must have author and browse permission. FrontPage sub-webs can implement unique permissions by maintaining the permissions on their own copies of the admin.dll, author.dll and shtml.dll ISAPI extensions. Alternatively, a FrontPage sub-web can inherit the permissions of the root web by keeping the permissions on its admin.dll, author.dll and shtml.dll in sync with the root web’s permissions.

FAT vs. NTFS File Partitions

Because there are no file permissions maintained in a FAT partition, storing web content in a FAT partition completely bypasses FrontPage and IIS access control. Users are warned that this situation exists when the FrontPage Server Extensions are installed onto a FAT partition. To apply security to the web, the user must either convert the partition from FAT to NTFS or move the content to an NTFS partition. With either solution the user will have to reinstall the Server Extensions.

Tip : Use NTFS not FAT!

Store your web content area on an NTFS partition, not a FAT partition.

IIS Authentication Process

HTTP is a stateless protocol, so each HTTP request is handled independently by IIS. For example, when an HTTP request comes in from the FrontPage Explorer addressed to admin.dll in a web, IIS initially attempts to execute the request as the anonymous user, IUSR_<hostname>. There are a number of reasons why IIS might fail to execute the admin.dll to handle this request:

If the anonymous user cannot execute admin.dll, then the web server returns error 401 (access denied). The Explorer will then prompt the browser for a user name and password and perform the Windows NT Challenge/Response (or Basic Authentication) interaction over HTTP with IIS. If the browser is using Challenge/Response, the user may not see a prompt, as the browser simply supplies the security ID of the logged in user. Once the user has been authenticated then IIS will again try to perform the operation with the user’s account. If the authenticated user has execute permissions on admin.dll, then he or she is a FrontPage administrator and the operation will proceed.

In actual use, the user is not prompted for their user name and password for every HTTP request, because the FrontPage Explorer caches the user’s credentials from their initial prompting for user name and password. However, if the cached credentials do not have sufficient permissions to perform the operation, the user will be prompted to enter a new username and password.

It’s important to note that even if the FrontPage and IIS settings all have correct values, a user can be denied access to a FrontPage Web based on the state of their user account. If their Windows NT user no longer exists, has been disabled or is in any other state that prevents it from executing these ISAPI DLLs, they will be denied access.

Network vs. Local Logon Rights

Microsoft IIS 2.0 implements Challenge/Response and Basic Authentication slightly differently. When a user is authenticated using Challenge/Response, they are logged on to the web server machine as a Network logon. When Basic Authentication is used, the user is logged on locally by default. For Basic Authentication it’s as if they actually logged on for an interactive session at the machine’s console.

In most situations, there are few benefits of a Network logon vs. a Local logon. The one situation that this distinction does impact is delegation applications. A delegation application is one in which part of the web server’s work is delegated to a secondary server process running on a different machine. For example, if the web server accesses a database server running on a different host machine, then it’s a delegation application. If the user has logged on locally, Windows NT security permits those user credentials to be honoured by the secondary server. If the user has logged on via the network, those credentials are not honoured. Consequently, when using Challenge/Response, the database server and web server must be running on the same host machine.

There are two negative impacts of Basic Authentication’s use of local logon. First, the Basic Authentication will not succeed if the user does not have local logon rights. Even if the FrontPage, IIS and Windows NT configuration appears to be correct, the lack of local logon rights granted to the user in the User Manager will mysteriously prevent Basic Authentication from authenticating the user. Second, if the user can obtain physical access to the host running the web server, they will be permitted to start an interactive session at the console because they have local logon rights.

Basic Authentication vs. Windows NT Challenge/Response

We recommend the exclusive use of Windows NT Challenge/Response for user authentication. When installed, FrontPage will configure the IIS 2.0 server to use NT Challenge/Response (the Basic Authentication setting will not be changed).

Run Syskey.exe

The program $winnt\system32\syskey.exe that comes with NT service pack 3 has to be run after passfil.dll is installed.

Syskey locks down the SAM database from unauthorized accesss.

It is best to install this into the registry for server machines. The other options to not allow automatic reboot (except with the floppy option if the floppy is in the drive on reboot).

System Policy Editor

Use The System Policy Editor utility to create a policy file for each domain. Use manual mode and store the policy as such:

\\PDC\NETLOGON\NTconfig.POL

Make sure that the ACL for this file is public read, admin only writeable. Make sure that this file is set to be replicated over to the BDCs.

Creating the policy

Start the policy editor on the domain. Select new file from the file menu. Add user and add group as needed. The default shares should be modified to reflect the needs of the base user account.

Select save as… and save the file as: "\\PDC\NETLOGON\NTconfig.POL"

In writing a policy the three options are:

Policy choices (default Policies)

User Policies

 

Computer Policies

 

File Sharing

In Windows NT/95 OS and what it offers in its networking capabilities, there are some security issues.

You can quickly scan a network, identify any win95/NT machine, grab a list of the resources available through the machine, and attempt to access those resources. Once gained access to a file shared resource, we attempt to see if the ".." bug exists. There is also the users on the machine itself that as we scan, we send a message to each user that they have been scanned.

Some of the problems with Win95/NT/WfWg is the same problem that exists in almost every configurable device on the network, is that the users have not configured it securely. Most people who set up sharable directories have left them passwordless. This allows any intruder on the Internet to steal files and possible modify them/delete them. Ensure that ALL file shares have hard to guess passwords used.

Windows 95 has no control of locking out further access attempts so the intruder can endlessly pound away on your machines.

Windows 95 has no logging of any of these attempts. An intruder can not only try quite a large number of passwords in a short period of time, there is no log of these attempts. Knowing someone is attempting to attack is as important as fixing the problems themselves.

Once the scan accesses a file shared directory, it attempts to determine if the machine is vulnerable to the ".." bug. This bug allows intruders to access the rest of the hard drive, even though the machine is configured to only allow access to a certian directory.

The bug is effective because the OS does not properly check for "..", "...", and "..\" which would give you access to directories above the directory file shared. This same type of bug is found on older NFS implementations on Unix.

The file sharing service if available and accessible by anyone can crash the NT 3.51 machine by using the dot..dot bug and require it to be rebooted. This technique on a Windows 95 machine potentially allows anyone to gain access to the whole hard drive. This vulnerability is documented in Microsoft Knowledge Base article number Q140818 last revision dated March 15, 1996.

It is easy for a network scanner to send a message through the popup program to let the users know they were scanned. The problem with this message utility is that the popup program lacks any authentication.

Removing default shares

If the non-sharing of the default shares is an issue you could probably write some sort of batch or cmd file that runs everytime you start the machine and disables the sharing. something like net share c$ /DELETE.

Web server security

There are a number of problems with webservers. Bugs in the server, stupid CGI scripts, erroneous configurations, strange other services (e.g. data base connections) are just a few things that might be used to damage your security.

You might want to look at the WWW Security FAQ to get some general security information on WWW.

To install an Windows NT machine as a web server or a firewall, tighten up the security on that box more that ordinary machines on the internal network since a machine accessible from the Internet are more vulnerable and more likely to be attacked. Securing the machine gives you a bastion host. Some of the things you should do include

 

Internet Information Server - additional info

See the Microsoft site for aditional documents on:

Frontpage - Additional info

Here are some documents on Microsoft's webserver on frontpage security

FTP server security

There are known problems with the FTP server that ships with Windows NT. There is another FTP server that comes with the Internet Information Server, IIS, that is more secure.

As stated elsewhere in this document, logging is not turned on by default. To turn on logging of the FTP server, there are a number of registry key parameters that can be changed. They are located under the following key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\FtpSvc\ Parameters

Some of the paramenters are LogAnonymous, LogFileAccess, LogNonAnonymous.

See Microsoft's articles on how to turn on

 Exchange

NT based security tools and products

These are always changing, appearing and dissapearing. See our links pages for the up to date sites to visit.

Windows NT Reported Vulnerabilities

New vulnerabilities and exposures are being discovered all the time, see our regularly updated pages on this topic.