[InterSect Alliance]
[InterSect Alliance]
[About Us]
[Services]
[Values]
[Staff]
[Projects]
[News]
[Contact]
WINDOWS NT 4.0 SECURITY
Graded Security Configuration Document
______________________________________________________________________________________________
Developed by Leigh Purdie and George Cora
Version 1.4
Version Date 16 January 2001
www.intersectalliance.com
[email.gif]
______________________________________________________________________________________________
This document is based on the Microsoft Windows NT security checklist, which can be found at
http://www.microsoft.com/security/ . However, the Microsoft document has been adapted to
provide a series of recommendations on the choices or grades of security installation that are
possible, using Windows NT 4.0. This is in recognition of the fact that installations will
exhibit varying levels of risk. This document makes the distinction between Workstation and
Servers, where required. Also, some of the registry settings may be dependant on the Service
Pack version in use, and therefore differencies may exist between this document and the actual
registry settings and values on your machine. Users are encouraged to notify Intersect
Alliance of any errors or omissions on the above email.
The security configuration parameters that are graded according to arbitrary levels of
PREMIUM, STANDARD or BASIC. These ratings are relative, and the gradings of PREMIUM, STANDARD
and BASIC should not be read in absolute terms. A number of security grades refer to a "risk
assessment". It is strongly recommended that a security risk assessment be used to ensure that
the most appropriate grade is chosen for a given production environment.
DISCLAIMER
CAUTION: The information contained in this document aims to provide assistance by identifying
the security grades for the Windows NT operating system. Implementing some of these
suggestions may potentially break or disrupt performance on systems on which the modifications
are made. The suggestions listed on this page may not be suitable for your environment. It is
therefore recommended that you test all changes on a non-production system before applying
them to a production environment. All modifications are made at your own risk. InterSect
Alliance is not responsible for any damage that may result from applying these recommendations
conatined in this document.
______________________________________________________________________________________________
TABLE OF CONTENTS
1.0 Initial Installation
1.1 System Mirroring
1.2 Alternative Operating Systems
1.3 Install the Latest Service Pack and Patches
1.4 File System
1.5 Filename Compatibility
1.6 CD Autorun
1.7 Devices
1.8 System Usage Policy
1.9 System PageFile
2.0 System Accounts
2.1 Unauthenticated Access
2.2 Appropriate Administrative Authentication
2.3 Local Accounts
2.4 Password Configuration
3.0 User Accounts and Rights
3.1 Log on Locally
3.2 Access this Computer from the Network
3.3 Bypass Traverse Checking
3.4 Backup and Restore
3.5 Shut Down the System
3.6 Scheduling Service Permissions
3.7 User Name Cache
3.8 Login Credential Caching
3.9 Information Release to Anonymous Users
3.10 Restricting remote access to the performance monitor
3.11 Command Key Modifications
3.12 Restrict access to the WinLogon Key
4.0 File and Registry Access Control
4.1 Increasing Security of New Systems
4.2 System Root Lockdown
4.3 Share Level Access Control
4.4 Administrative Shares
4.5 Remote Registry Access
5.0 Network Access Control
5.1 Packet Screening
5.2 Network Protocols
5.3 IP Routing
5.4 Services
5.5 SNMP Service Access Control
5.6 Service User
5.7 Network Authentication
6.0 Subsystems
6.1 OS/2 Subsystem
6.2 POSIX Subsystem
6.3 Distributed Components
7.0 Remote Access Services
7.1 RAS Security
8.0 Malicious Code
8.1 Anti-Viral Software
9.0 Event Logging
9.1 Windows NT Event Logging
9.2 Additional Events - Backup and Restore
9.3 Additional Events - Base Objects
9.4 Log Access Restriction
9.5 Time Synchronisation
Appendix A - Explanation of Windows NT Services
______________________________________________________________________________________________
1.0 Initial Installation
1.1 System Mirroring
System mirroring (disk cloning) is not recommended for Windows NT systems. If the disk is
cloned at the wrong point in the NT installation process, both systems will have the same
system identifiers (SID). Each installation of Windows NT receives a special system ID unique
among all other such IDs on the network, which makes its accounts and groups IDs also unique.
Cloned installations do not have unique SIDs, which negates certain security protections. If
system mirroring must be used, the source drive must be in a pre-GUI installation state (ie:
before the GUI portion of the Windows NT Setup occurs). Note that the NT4.0 Deployment tools
correctly compensate during installation, and can be used to "duplicate" an existing
installation, while including the correct SID and security changes.
Workstation
and
Server
Premium
Cloning of NT workstations is not to be undertaken.
Standard
Cloning of NT workstations is not to be undertaken.
Basic
Cloning of NT workstations is not recommended.
Table 1.1 System Mirroring
1.2 Alternative Operating Systems
Although access to Windows NT file systems can be achieved using bootable floppy disks or CD
Drives within either DOS or Linux, it is recommended that multiple operating systems are not
installed on Windows NT servers or workstations by default. Any requirement for multi-boot
operating environments should be addressed in the risk assessment.
Workstation
Premium
No other operating systems are to be installed on NT workstations. BIOS settings should be
restricted to disable boot capability from removable media, and be password protected.
Standard
No other operating systems are to be installed on NT workstations.
Basic
Other operating systems, or duplicate NT operating systems, may be installed on those systems
subject to the outcomes of a risk assessment.
Server
Premium
No other operating systems are to be installed on NT servers. BIOS settings should be
restricted to disable boot capability from removable media, and be password protected.
Standard
No other operating systems are to be installed on NT servers.
Basic
No other operating systems are to be installed on NT servers.
Table 1.2 Alternative Operating Systems
1.3 Install the Latest Service Pack and Patches
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 and workstations as soon as your operational circumstances
allow. Windows NT hotfixes are also available for specific security problems. These should be
installed on systems with higher security requirements, such as those that provide a service
to Internet uses.
Workstation
and
Server
Premium
Install the latest NT Service pack and Windows NT patches and hotfixes.
Standard
Install the latest NT Service pack.
Basic
Determine the Service Pack requirements based on risk
Table 1.3 Install the Latest Service Pack and Patches
1.4 File System
In order to activate the recommended settings specified in this document, it is critical that
NTFS be running all system volumes. Without NTFS, the access control or auditing features will
not be able to be activated.
Workstation
and
Server
Premium
All system volumes should be set to NTFS.
Standard
All system volumes should be set to NTFS.
Basic
Non-NTFS volumes, if they exist, should not be used to store any files that require some level
of access control or auditing.
Table 1.4 File System
1.5 Filename Compatibility
Filename compatibility can be enabled to allow 16-bit applications to work correctly. This
facility maps long filenames (eg: MyTestFile.txt) to a filename that can be read by older DOS
"8.3" style applications (eg: MYTEST~1.TXT). For most environments, this feature can be safely
turned off. However, if 16 bit applications are installed on the system, it is likely that
they will not be able to access some files.
To disable DOS "8.3" filename compatibility, set the following registry key:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Control\FileSystem
Name: NtfsDisable8dot3NameCreation
Type: REG_DWORD
Value: 1
Workstation
and
Server
Premium
Disable filename compatibility.
Standard
Disable filename compatibility.
Basic
Disable filename comptability if not required.
Table 1.5 Filename Compatibility
1.6 CD Autorun
The CD Autorun feature enables the capability to launch an application from CDs, if the
autorun.exe program exists on the CD. This can potentially allow arbitrary programs to be
executed without the knowledge or approval of the system administrator or the user. Assuming
that the workstation or server has a CD drive, the autorun feature should be disabled. To
disable the autorun feature, set the following registry key to 0:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Services\Cdrom
Name: AutoRun
Type: REG_DWORD
Value: 0
Workstation
Premium
Disable CD Autorun.
Standard
Disable CD Autorun.
Basic
Enable Autorun if required by the users.
Server
Premium
Disable CD Autorun.
Standard
Disable CD Autorun.
Basic
Disable CD Autorun, based on risk assessment.
Table 1.6 CD Autorun
1.7 Devices
If a system device is not installed, or should not be enabled, the entry for the device in
Control Panel -> Devices should be disabled. Some examples are:
i. Modem: If a modem is built into the PC, but should not be accessible by the end
user, disable the device.
ii. USB: If no USB peripherals are required on the system, remove the device.
iii. Remote Access ARP service: If no modems are attached, then RAS should not be
enabled.
iv. Serial: If PS/2 mice are used, consider removing the serial device
v. Alerter: Enabling the alerter service on Windows NT systems may allow remote machines
to initiate annoyance/denial of service attacks against your machines by creating extremely
large numbers of popup messages. If you aren't going to use the Alterter service, consider
turning it off.
Workstation
Premium
Disable all unused devices, including the following devices if not used by the system:
Modem
Serial
Sermouse
USB
Parallel
Parport
Remote Access ARP Service
Remote Access Auto Connection Driver
Remote Access MAC
Remote Access Wan Wrapper
Standard
Disable the following devices:
Modem
Remote Access ARP Service
Remote Access Auto Connection Driver
Remote Access MAC
Remote Access Wan Wrapper
Basic
Enable devices as required based on the outcomes of a risk assessment.
Server
Premium
Disable all unused devices, including the following devices if not used by the system:
Modem
Serial
Sermouse
USB
Parallel
Parport
Remote Access ARP Service
Remote Access Auto Connection Driver
Remote Access MAC
Remote Access Wan Wrapper
Standard
Disable all unused devices, including the following devices if not used by the system:
Modem
Serial
Sermouse
USB
Parallel
Parport
Remote Access ARP Service
Remote Access Auto Connection Driver
Remote Access MAC
Remote Access Wan Wrapper
Basic
Enable devices as required based on the outcomes of a risk assessment.
Table 1.7 Devices
1.8 System Usage Policy
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.
Edit the string LegalNoticeCaption with a short caption and the string LegalNoticeText with
the notice itself
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Windows NT\Current Version\Winlogon
LegalNoticeCaption: Wording of the legal caption as determined by company/agency
requirements
Workstation
and
Server
Premium
Set the Legal Notice Caption.
Standard
Set the Legal Notice Caption.
Basic
Set the Legal Notice Caption, as required by the risk assessment.
Table 1.8 System Usage Policy
1.9 System PageFile
The system pagefile can potentially hold sensitive information collected while the most recent
user has been working at the workstation or server. Set the following registry key to force
the system to clear the page file.
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Control\Session Manager\Memory Management
Name: ClearPageFileAtShutdown
Type: REG_DWORD
Value: 1
Workstation
and
Server
Premium
Clear the system page file at system shutdown.
Standard
Clear the system page file at system shutdown.
Basic
Set as determined by a risk assessment
Table 1.9 System Page File
2.0 System Accounts
2.1 Unauthenticated Access
The guest account is disabled by default from Service Pack 3 onwards. Verify that the account
has been disabled unless there is a specific requirement for guest access in the system
security plan, and appropriate countermeasures have been detailed. In situations where a
higher level of security is appropriate, the "Authenticated Users" group should be substituted
for the "Everyone" group for access to system resources.
Workstation
Premium
Ensure the Guest account has been disabled.
Standard
Ensure the Guest account has been disabled.
Basic
Allow the Guest account only if required, and if required.
Server
Premium
Ensure the Guest account has been disabled. Remove the "Everyone" group from all system rights
via User Manager. Replace with "Authenticated Users" instead.
Standard
Ensure the Guest account has been disabled.
Basic
Enable the Guest account if allowed by a risk assessment. Allow the Guest account only if
required, and if appropriate countermeasures have been documented.
Table 2.1 Unauthenticated Access
2.2 Appropriate Administrative Authentication
System administrative activities should not be performed using the same account that is used
for normal office automation activities. Separation of duties should be facilitated with the
provision of a "normal" account, with standard user-level privileges, and an "administrative"
account with heightened privileges. The use of generic accounts for administrative duties (ie:
accounts that are not attributable to a single user) are strongly discouraged for systems with
some security requirements. Emergency repairs aside, security auditing requirements imply that
administrative actions should be able to be tracked back to individual users.
Workstation
and
Server
Premium
Administrative users should be provided with both a "normal" general use account, and an
account with the heightened privileges that they require.
Standard
Administrative users should be provided with the "Administrator Right", as opposed to having
access to a generic account.
Basic
A generic "Administrator" account may be used, subject to the outcomes of a risk assessment.
Table 2.2 Appropriate Administrative Authentication
2.3 Local Accounts
Local non-administrative accounts on workstations and servers are discouraged unless a
specific requirement has been addressed in the appropriate security plan.
Workstation
and
Server
Premium
Local, non-administrative, user accounts should not be created.
Standard
Local, non-administrative, user accounts should not be created without appropriate security
plan authorisation.
Basic
Local, non-administrative, user accounts may be created subject to the outcomes of a risk
assessment.
Table 2.3 Local Accounts
2.4 Password Configuration
The following policy settings control how passwords must be used by all user accounts within
the domain. The policy settings used are based on those specified in the Departmental IT
Security Policy. All settings are made with the Windows NT "User Manager for Domains"
application. For systems that require extra password-related security controls, enforcing
slightly stronger passwords may be appropriate. Add PASSFILE to the notification packages
entry as detailed below to enforce the password features detailed below. Passwords should not
contain the user name or any part of the user's full name. Passwords should contain characters
from at least three (3) of the following four (4) classes:
a. English upper case letters A, B, C, ... Z
b. English lower case letters a, b, c, ... z
c. Westernized Arabic numerals 0, 1, 2, ... 9
d. Non-alphanumeric ("special characters") such as punctuation symbols .
Fpnwclnt.dll is a dynamic link library that lets File and Print Services for NetWare (FPNW)
and Directory Service Manager for NetWare (DSMN) perform password synchronization with Novell
NetWare servers. Fpnwclnt.dll only ships with Windows NT Server, but the registry key exists
on Windows NT workstations also. As such, the FPNWCLNT registry entry for workstations should
be substituted for 'PASSFILT', and the same should be done for a Windows NT Server PDC if
password synchronisation with Novell Netware servers is not required. If such synchronisation
IS required, the PASSFILT entry should be added to the indicated registry key.
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Control\LSA
Name: Notification Packages
Type: REG_MULTI_SZ
Value: PASSFILT
NOTE: Replace the 'FPNWCLNT' entry if it is present.
Workstation
and
Server
Premium
Maximum Password Age: Expires in 30 days
Minimum Password Age: Allow changes in 2 days
Minimum Password Length: At least 8 characters
Password Uniqueness: Remember 4 passwords
Account Lockout: Lockout after 5 attempts
Reset count after: 360 minutes
Lockout duration: Forever (until security officer unlocks)
Forcibly disconnect remote users from Server when logon hours expire: Set on
Users must logon in order to change password: Not set on
PASSFILT should replace FPNWCLNT in the indicated registry entry.
Standard
Maximum Password Age: Expires in 90 days
Minimum Password Age: Allow changes in 2 days
Minimum Password Length: At least 6 characters
Password Uniqueness: Remember 2 passwords
Account Lockout: Lockout after 10 attempts
Reset count after: 60 minutes
Lockout duration: 10 Days
Forcibly disconnect remote users from Server when logon hours expire: Set on
Users must logon in order to change password: Not set on
PASSFILT should replace FPNWCLNT in the indicated registry entry.
Basic
Maximum Password Age: Expires in 180 days
Minimum Password Age: Allow changes in 2 days
Minimum Password Length: At least 6 characters
Password Uniqueness: Remember 1 password
Account Lockout: Lockout after 15 attempts
Reset count after: 60 minutes
Lockout duration: 5 Days
Forcibly disconnect remote users from Server when logon hours expire: Set off
Users must logon in order to change password: Not set on
PASSFILT should replace FPNWCLNT in the indicated registry entry.
Table 2.4 Password Configuration
3.0 User Accounts and Rights
It is important that those accounts used for applications be limited in their RIGHTS, and in
particular their group membership. This is related to the other sections in this document. The
user and group rights can be selected from the User Manager | Policies | User Rights. However,
it is recommended that account rights would be better managed using groups.
3.1 Log on Locally
This right allows a user to log on locally at the computer's keyboard. Generally, the Log On
Locally user right in the domain should not be available to the "Everybody" and "Guest"
groups.
Workstation
Premium
Remove "Everyone" and "Guests" from this right.
Standard
Remove "Everyone" and "Guests" from this right.
Basic
Remove "Everyone" and "Guests" from this right, as required by a risk assessment
Table 3.1 Log on Locally
3.2 Access this Computer from the Network
This right allows a user to connect to the local computer over the network, and access local
data or devices if privileges are set appropriately. On workstations, and stand alone servers,
replace the "Everyone" group with "Users" group. For other servers, replace the "Everyone"
group with: "Backup Operators", "Server Operators", "Print Operators" and "Users". Note that
this setting MAY affect servers that do not require authentication (eg: IIS, anonymous FTP,
etc). Check server documentation before proceeding.
Workstation
and
Server
Premium
Replace the "Everyone" group.
Standard
Replace the "Everyone" group.
Basic
Decide on whether to allow unauthenticated users, based on the usage of the server and the
outcomes of a risk assessment.
Table 3.2 Access this Computer from the Network
3.3 Bypass Traverse Checking
Remove all users and groups from the Right named "Bypass traverse checking." There is nothing
inherently insecure about assigning users the Right to "bypass traverse checking," so long as
all system users understand that closing a directory's ACL to others does not necessarily deny
access to its file and subdirectories. Under the opinion that users tend to believe otherwise,
and that bypass traverse checking is seldom used or needed, the guidelines recommend it be
assigned to no one. You could assign this Right to administrative users who likely have broad
ACL Rights.
Workstation
and
Server
Premium
Remove the "Bypass Traverse Checking" from all users.
Standard
Remove the "Bypass Traverse Checking" from all users except Administrative users.
Basic
Allow "Bypass Traverse Checking".
Table 3.3 Bypass Traverse Checking
3.4 Backup and Restore
Remove the "backup" and "restore" Rights from "Server Operators". These extremely sensitive
Rights are best restricted to accounts used only for backup and restore, normally "Backup
Operators". These rights will allow a user to read all files, since this right is required
when undertaking backup and restore operations.
Workstation
and
Server
Premium
Remove backup and restore rights except for "Administrators".
Standard
Remove backup and restore rights except for "Backup Operators" and "Administrators".
Basic
Remove backup and restore rights as required by the risk assessment.
Table 3.4 Backup and Restore
3.5 Shut Down the System
The right to shut down the system should generally only be available to Administrators.
However, authenticated users would appreciate the capability to reboot a workstation.
Workstation
Premium
Remove the "Everyone" and "Guests" groups.
Standard
Remove the "Everyone" and "Guests" groups.
Basic
Determine requirement as per outcome of a risk assessment.
Server
Premium
Remove the "Users", "Everyone" and "Guests" groups.
Standard
Remove the "Users", "Everyone" and "Guests" groups.
Basic
Recommend removing the "Users", "Everyone" and "Guests" groups, as required by the outcomes of
a risk assessment.
Table 3.5 Shut Down the System
3.6 Scheduling Service Permissions
The Schedule service is used to schedule tasks to run automatically at a preset time. The
scheduled task is run in the context run by the Schedule service (typically the operating
system's context). 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 using regedt32:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Control\LSA
Name: Submit Control
Type: REG_DWORD
Value: 1
By default, the system operator account also has scheduler access. To remove access, set the
following registry permissions:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Services\Schedule
Security Permissions: Remove write access for Server Operator
Workstation
and
Server
Premium
The scheduling service should be restricted to "Administrators" only.
Standard
The scheduling service should be restricted to administrative staff only, and may include
groups such as "Administrators", "Backup Operators", etc. Users may be granted the right to
schedule tasks based on the outcomes of a risk assessment.
Basic
Requirement to restrict scheduling should be based on the outcomes of risk assessment.
Table 3.6 Scheduling Service Permissions
3.7 User Name Cache
The user name of the last successful login is displayed by default on the windows NT login
screen. Valid user names, although moderately simple to get hold of through other methods,
assist a potential attacker in assessing potential accounts to compromise. To remove the
display of cached user names, set the Registry value of DontDisplayLastUsername as follows:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Windows NT\Current Version\Winlogon
Name: DontDisplayLastUsername
Type: REG_SZ
Value: 1
Also in the same location in the Registry, delete the entry "DefaultPassword" if it is
present.
Workstation
Premium
Disable user name caching.
Standard
User name caching is acceptable.
Basic
User name caching is acceptable.
Server
Premium
User name caching is acceptable on servers that are physically secured such that only
authorised administrative staff have access.
Standard
User name caching is acceptable.
Basic
User name caching is acceptable.
Table 3.7 User Name Cache
3.8 Login Credential Caching
By default Windows NT caches credential information for the past 10 logins, in case the domain
controller is unavailable. This may present a problem to those installations that face a
higher risk profile. To prevent the caching of logon information, create or change the
following registry value:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Windows NT\Current Version\Winlogon
Name: CachedLogonsCount
Type: REG_DWORD
Value: 0
Workstation
Premium
Disable Login Credential caching.
Standard
Disable Login Credential caching.
Basic
Allow Login Credential caching.
Table 3.8 Login Credential Caching
3.9 Information Release to Anonymous Users
Windows NT allows non-authenticated users to list domain usernames and share names. This
information can be very useful to potential attackers. To prevent this type of access, set or
create the following registry key.
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Control\LSA
Name: RestrictAnonymous
Type: REG_DWORD
Value: 1
Workstation
Premium
Disable information release to anonymous users.
Standard
Disable information release to anonymous users.
Basic
Disable information release to anonymous users, as required by a risk assessment.
Table 3.9 Information Release to Anonymous Users
3.10 Restricting remote access to the performance monitor
Remote access to the performance monitor software could potentially allow users to query the
processes and process priorities on the local machine. Disable remote performance monitoring
for all but Administrators by setting the following key permissions:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Windows NT\CurrentVersion\Perflib
Security Permissions: Allow read/write for Administrators and System only.
Workstation
and
Server
Premium
Restrict remote performance monitoring to authorised Administrators only.
Standard
Remove any permissions to "Everyone" in using the Performance monitoring facilities can be
left set to default values.
Basic
Performance monitoring facilities can be left set to default values.
Table 3.10 Restricting remote access to the performance monitor
3.11 Command Key Modifications
By default, users can change the file association of *.reg files. The ability to modify such
file associations should be restricted to administrative users only. Secure this facility by
modifying the following registry permissions:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Classes\regfile\shell\open\command
Security Permissions: Restrict non-Administrators write access
Workstation
and
Server
Premium
Restrict access to the registry "command" key.
Standard
Restrict access to the registry "command" key.
Basic
Restrict access to the registry "command" key, based on the outcomes of a risk assessment.
Table 3.11 Command Key Modifications
3.12 Restrict access to the WinLogon Key
The winlogon key controls processes relating to the Windows NT logon sequence, and can be used
to raise a system operator's access level to Administrator. To secure the registry key set
permissions as follows:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Windows NT\CurrentVersion\Winlogon
Security Permissions: Remove Server Operator write access
Workstation
and
Server
Premium
Restrict write access to the winlogon key to authorised administrators only.
Standard
Restrict write access to the winlogon key to authorised administrators only.
Basic
Restrict write access to the winlogon key to authorised administrators only.
Table 3.12 Restrict access to the WinLogon Key
4.0 File and Registry Access Control
The default permissions set by Windows NT upon installation may be inadequate for certain
installations. Although Windows NT provides some basic security protection for files in a
default installation, security controls quickly degrade once an administrator installs new
software. This is due to the default Windows NT method of allowing change access for the
"Everyone" group to all new files in the c:\winnt directory, but restricting c:\winnt\*.*
files (as installed) to be only modifiable by administrators. This was put in place to try and
retain as much compatibility with older non-Windows NT applications as possible.
Unfortunately, it also has the side effect of making any new, non default-NT software
executables, DLLs or configuration files stored within the c:\winnt directory, changeable by
any user that has access to the system. Any new file that is executed by the system upon
bootup, or on service start (or many other situations) that are not part of the default
Windows NT installation, can be easily modified by a local user to perform functions with
system-level permissions. Some good examples are virus checkers, new hardware drivers, etc.
Applications installed in other areas of the system are also susceptible to similar attacks,
but there is more likelihood that applications that are automatically executed by system
processes will live within the system root (c:\winnt) hierarchy. As such, this is where the
following controls will focus.
For registry settings discussed below, many of the settings can be controlled through the
System Policy Editor which is much friendlier than the Registry Editor. The System Policy
Editor actually sets up a policy file (rather than directly changing the Registry) and that
file can be applied throughout the domains that are managed. The settings are shared
automatically if you name the file NTCONFIG.POL and place it in the NETLOGON share directory
in the primary and backup domain controllers. However, many modifications can only be
performed using the regedt32.exe command.
4.1 Increasing Security of New Systems
NOTE: THIS SHOULD BE DONE POST OPERATING SYSTEM / SERVICE PACK INSTALLATION, BUT PRIOR TO THE
INSTALLATION OF OTHER APPLICATIONS.
For the system root directory (usually c:\winnt), the system directory (if it exists, usually
c:\winnt\system), and the system32 directory (usually c:\winnt\system32), modify the
permissions for the "Everyone" group from "Change (RWXD)" to:
* Set "Special Directory Permissions" to "RWXD".
* Set "Special File Permissions" to "RX".
* NOTE: Do not set "replace permissions on subdirectories".
* NOTE: Do not set "replace permissions on existing files".
CREATOR OWNER, which should have Full Control, and other entries need not change. User
applications which create items in these directories can fully access those items on behalf of
the creating user, but all other non-administrative users gain only read access. The only case
where there might be compatibility problems is where one user installs programs that must be
altered by other users of the application, but on single use workstations, or correctly
administered servers, this should be a very rare occurrence.
4.2 System Root Lockdown
For systems with a higher level of required security protection, the following permission
settings should be implemented. The recommended directory settings are as follows:
Directory
Group Level Access Control
root of NTFS volume
Administrators, System Full Control
Server Operators Change
Everyone Change
CREATOR OWNER Full Control
\%SystemRoot%
Administrators, System Full Control
All \%SystemRoot%Sub-Directories
Server Operators Change
Everyone Read
CREATOR OWNER Full Control
\Boot.ini
Administrators Full Control
SYSTEM Full Control
\Ntdetect.com
Administrators Full Control
SYSTEM Full Control
\Ntldr
Administrators Full Control
SYSTEM Full Control
\Autoexec.bat
Administrators Full Control
SYSTEM Full Control
Everyone Read
\Config.sys
Administrators Full Control
SYSTEM Full Control
Everyone Read
\TEMP
Administrators Full Control
SYSTEM Full Control
CREATOR OWNER Full Control
Everyone Special Directory Access - Read, Write and Execute, Special File Access - None
\Program Files
Administrators Full Control
SYSTEM Full Control
All \Program Files Sub-Directories
Server Operators Change
Everyone Read
CREATOR OWNER Full Control
Exceptions to the Table above
Directory
Group Level Access Control
\%SystemRoot%\REPAIR
Administrators Full Control
\%SystemRoot%\COOKIES
\%SystemRoot%\FORMS
\%SystemRoot%\HISTORY
\%SystemRoot%\OCCACHE
\%SystemRoot%\PROFILES
\%SystemRoot%\SENDTO
\%SystemRoot%\Temporary Internet Files
\%SystemRoot%\Cursors
\%SystemRoot%\Fonts
\%SystemRoot%\PRINTERS
\%SystemRoot%\TMP
Administrators Full Control
CREATOR OWNER Full Control
Everyone Special Directory Access - Read, Write and Execute, Special File Access - None
System Full Control
\%SystemRoot%\SYSTEM32\CONFIG
Administrators Full Control
CREATOR OWNER Full Control
Everyone List
System Full Control
\%SystemRoot%\SYSTEM32\system32
Administrators, System Full Control
CREATOR OWNER Full Control
Everyone Change
Server Operators Change
\%SystemRoot%\SYSTEM32\drivers
Administrators, System Full Control
CREATOR OWNER Full Control
Everyone Read
Server Operators Full Control
\%SystemRoot%\SYSTEM32\repl
Administrators, System Full Control
CREATOR OWNER Full Control
Everyone Read
Server Operators Change
\%SystemRoot%\SYSTEM32\spool
Administrators, System Full Control
CREATOR OWNER Full Control
Everyone Read
Print, Server Operators Full Control
Power Users Change
\%SystemRoot%\SYSTEM32\repl\import
Administrators, System Full Control
CREATOR OWNER Full Control
Everyone Read
Server Operators Change
Replicator Change
Network No Access
\%SystemRoot%\SYSTEM32\repl\export
Administrators, System Full Control
CREATOR OWNER Full Control
Server Operators Change
Replicator Read
Workstation
and
Server
Premium
Configure the system in accordance with paragraph 4.2
Standard
Configure the system in accordance with paragraph 4.1
Basic
Configure the system in accordance with paragraph 4.1, if required by a risk assessment.
Table 4.1 Security of Operating System Root
4.3 Share Level Access Control
Network shares provide a user with the capability to distribute access to local server or
workstation files to other users on the network. Share level access control is subordinate to
NT file access control - it does not override any more restrictive permissions placed on the
file system. However, there is a significant risk of users not adequately understanding the
full repercussions of providing shares out to other users. As such, restricting the permission
to share directories on servers should be a priority, and should be considered on workstations
with significant security requirements. In order to restrict access to share creation, make
the following registry modifications using regedt32.exe
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Services\LanmanServer\Shares
Security Permissions: Restrict write access to the shares key, and all subkeys to those
groups or users who should be provided access. Set all other users (ie: the "Everyone
group") to a maximum "Read" permission.
Workstation
Premium
Creation of shares restricted to administrative staff only.
Standard
Workstation share creation, and the control over share-level access is available to "Power
Users".
Basic
Workstation share creation, and the control over share-level access is available to all
users.
Server
Premium
Creation of shares restricted to "Administrators" only, and all new shares must be detailed in
the appropriate system security plan.
Standard
Creation of shares restricted to administrative staff.
Basic
Server share creation, and the control over access is available to all users.
Table 4.3 Share Level Access Control
4.4 Administrative Shares
By default, each server and workstation creates several default administrative shares for it's
logical volumes (C:, D:, etc.), and also an ADMIN$ share that links to the windows NT
installation directory. The permissions associated with these shares cannot be easily
modified, and as such, they do not present a significant risk in a firewalled, physically
secure environment. They also simplify system administration. As such, removing the default
administrative shares should be considered only for those servers and workstations with
significant security requirements. To disable the administrative shares such as C$ and ADMIN$,
create or update the following registry keys:
Servers:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Services\LanManServer\Parameters
Name: AutoShareServer
Type: REG_DWORD
Value: 0
Workstations:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Services\LanManServer\Parameters
Name: AutoShareWks
Type: REG_DWORD
Value: 0
Workstation
and
Server
Premium
Remove the default administrative shares. Establish specific shares only as required by a risk
based security plan.
Standard
Leave the default administrative shares active to simplify system administration.
Basic
Leave the default administrative shares active to simplify system administration.
Table 4.4 Administrative Shares
4.5 Remote Registry Access
By default, Windows NT systems allow remote users to have some access to a system registry. To
disable remote access, set the following registry key permissions:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Control\SecurePipeServers\winreg
Security Permissions: Remove access for the Everyone group
Workstation
Premium
Remove remote access to the system registry.
Standard
Remove remote access to the system registry.
Basic
Allow remote access to the system registry, based on the outcomes of a risk assessment.
Table 4.5 Remote Registry Access
5.0 Network Access Control
5.1 Packet Screening
Windows NT 4.0 has the capability to limit the network card to offering particular services,
or ports. It does not readily allow the server or workstation to limit services to/from
particular host(s), like a firewall. If source-address packet screening is an identified
requirement, then a network firewall should probably be considered instead. Configure packet
screening by:
Control Panel -> Network -> Protocols -> TCP/IP Protocol -> Properties -> Advanced ->
Enable Security -> Configure.
Workstation
and
Server
Premium
Configure the network card to only allow packets destined for authorised legitimate ports (eg:
80 and 443 for web servers; 25 for mail servers, and so on). Select the "Permit Only" option.
Standard
Select packet screening only as required by the risk assessment.
Basic
Leave settings as per the default installation.
Table 5.1 Packet Screening
5.2 Network Protocols
If any network protocols are not required by the server or workstation, then remove them from
the supported network protocols list for each supported adapter. Generally, of the four
protocols that are available with a default install of Windows NT (TCP/IP, NetBEUI, IPX,
32-bit DLC), only TCP/IP and NetBEUI are required. NetBEUI is a non-routable protocol (without
protocol encapsulation).
Workstation
and
Server
Premium
Remove all protocols unless required and authorised by a risk assessment.
Standard
Remove all protocols except TCP/IP and NetBEUI.
Basic
Leave protocols as per the default installation.
Table 5.2 Network Protocols
5.3 IP Routing
In general, unless the server is being used as a Dial-up access server, there are few
situations where routing needs to be enabled on an NT server or workstation. Disable IP
Routing, as follows:
Control Panel | Network | Protocols | TCP/IP Protocol | Properties | Routing, and clear the
"Enable IP Forwarding" check box.
Workstation
and
Server
Premium
Disable IP Forwarding / Routing.
Standard
Enable/Disable IP Forwarding / Routing, as required by the risk assessment.
Basic
Enable/Disable IP Forwarding / Routing, as required.
Table 5.3 IP Routing
5.4 Services
Windows NT can be configured to run any number of services at boot time. These services may or
may not be required for the operation of the system. Whilst a well configured firewall will
usually prevent an external attack, it is still important to limit the services to those that
are required for the correct and functional operation of the system. Some default NT services
are explained in more detail in the Appendix to this document. The capability to start/stop
services should be particularly restricted. There are generally few circumstances where a
non-administrative user needs to interactively start or stop a service. To ensure only
administrators have the capability to install services, modify the registry as follows:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Services
Security Permissions: Remove All users except Administrators and SYSTEM groups.
Workstation
Premium
Remove all unneeded services, and change the registry setting.
Standard
Change the registry setting. Remove those services not required, as required by the risk
assessment.
Basic
Leave as default.
Server
Premium
Remove all unneeded services, and change the registry setting.
Standard
Remove those services not required, as required by the risk assessment.
Basic
Leave as default.
Table 5.4 Services
5.5 SNMP Service Access Control
SNMP is used to monitor and control network assets. If used on the server, the default
permissions allow the "Everyone" group to obtain the SNMP community string - a string which
can be thought of as a "password" used to allow access to certain SNMP capabilities. The
permissions on the SNMP registry key allow "Everyone" access by default. This access allows
any system user to obtain the community names utilised by the SNMP service. The permissions on
this registry key should also be set more strictly by the Administrator. Ensure that only
Administrator and other authorized users can access the contents of the following registry
key:
Hive : HKEY_LOCAL_MACHINE\SYSTEM
Key : CurrentControlSet\Services\SNMP\Parameters
Security Permissions: Remove all but Administrator and System.
NOTE: Ensure that the SNMP community name is changed from the default "public" community
name to a more obscure name.
Workstation
and
Server
Premium
If SNMP is used, restrict access to the SNMP community name, and modify the community name to
a more obscure string.
Standard
If SNMP is used, restrict access to the SNMP community name, and modify the community name to
a more obscure string.
Basic
Leave as default.
Table 5.5 SNMP Service Access Control
5.6 Service User
It may be appropriate to force non-standard Windows NT services to use an "Unprivileged
Service" account. In order to accomplish this task, create a local account named, for example,
"Unprivileged Service" with a 14-character, random password. Deselect "User Must Change
Password at Next Logon" and select "Password Never Expires." No other account parameters need
to be set. Assign the bare minimum rights to the account that it needs to perform it's
intended role. Set the service to run as the "Unprivileged Service" account rather than the
default "System". It may be necessary to give this account membership in certain groups so
that services that use the account can gain access to certain objects, typically one of the
Windows NT operator accounts or Power Users. Avoid adding the user to an administrators group,
as this will negate the purpose of creating the service account. If run on either member
servers, or domain controllers, the accounts must be domain accounts. This will enable the
security reports monitoring system to monitor their usage and ensure that appropriate account
lockout policies are enforced.
Workstation
Premium
Create dedicated accounts for all non-standard windows NT services, and also the "Schedule"
service, and remove privileges from the services as appropriate; where identified as a
requirement in the system security plan.
Standard
Create dedicated accounts for all non-standard windows NT services.
Basic
Leave as per the default installation.
Server
Premium
Create dedicated accounts for all non-standard windows NT services, and also the "Schedule"
service, and remove privileges from the services as appropriate; where identified as a
requirement in the system security plan.
Standard
Create dedicated accounts for all non-standard windows NT services, and also the Schedule
service.
Basic
Create dedicated accounts for all non-standard windows NT services, as required by the risk
assessment.
Table 5.6 Service User
5.7 Network Authentication
Windows NT uses the LANMAN password format to enable appropriate authentication of non-NT
clients. The use of LANMAN passwords exponentially reduces the resources required to "crack"
(exhaustively compare encrypted passwords against the captured version) a users password, if
the encrypted password is intercepted. If the Windows NT machine has no requirement to serve
non-NT systems, then LANMAN authentication should be disabled. To prevent Windows NT from
using the LANMAN format, modify the registry as follows:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\control\LSA\
Name: LMCompatibilityLevel
Type: REG_DWORD
Value: 2
To set Windows NT to ONLY use the LANMAN format for computers that specifically request it
(eg: Windows 95 systems):
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\control\LSA\
Name: LMCompatibilityLevel
Type: REG_DWORD
Value: 1
Windows NT supports a cryptographic integrity mechanism with replay protection called "SMB
Signing" for its native network sharing protocol, SMB. Windows NT uses SMB for access network
share directories and printers, and several other native Windows NT services, like remote
administration. SMB signing prevents active network taps from interjecting themselves into
already established sharing sessions, usually called "session hijacking." Without SMB signing,
such penetrations can modify and view all the information on the server to which the client
user has access. SMB signing prevents such penetrations. However SMB signing provides no
encryption of user data, and therefore any network tap can view all the data the user
transmits between client and server. However, Windows 95, earlier versions of Windows, and
Windows NT without this feature installed cannot engage in SMB signing. To enforce SMB signing
on Windows NT, modify the registry as follows:
Servers:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Services\LanManServer\Parameters
Name: EnableSecuritySignature
Type: REG_DWORD
Value: 1
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Services\LanManServer\Parameters
Name: RequireSecuritySignature
Type: REG_DWORD
Value: 1
Workstations:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Services\Rdr\Parameters
Name: EnableSecuritySignature
Type: REG_DWORD
Value: 1
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Services\Rdr\Parameters
Name: RequireSecuritySignature
Type: REG_DWORD
Value: 1
Workstation
and
Server
Premium
Remove the LANMAN authentication capability. Note that systems that require LAMAN passwords
will not be able to connect to the workstation. Set SMB signing to be a requirement. Note that
systems that do not implement SMB signing will not be able to connect to the
workstation/server.
Standard
Set the LANMAN authentication capability to be only available to those systems that
specifically require it.
Basic
Leave as default.
Table 5.7 Network Authentication
6.0 Subsystems
Windows NT supports a limited number of subsystems, which are groups of utilities which add
certain extra capabilities to the NT server or workstation. Unfortunately, the subsystems can
also degrade existing NT security, or introduce new security vulnerabilities.
6.1 OS/2 Subsystem
The OS/2 Subsystem is required if the server needs to significantly interact with OS/2
Clients. The subsystem introduces a security risk relating to processes which can potentially
persist across logins. ie: if a user starts a process then logs out, there is a potential for
that process to be accessed by the next user who logs into the system. As the process was
started by the first user, it retains that users system privileges. To disable the OS/2
Subsystem, delete the following registry key:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Control\Session Manager\SubSystems
Name: Os2
Workstation
and
Server
Premium
Remove the OS/2 Subsystem.
Standard
Remove the OS/2 Subsystem, unless required for operational reasons.
Basic
Leave as default.
Table 6.1 OS/2 Subsystem
6.2 POSIX Subsystem
The POSIX Subsystem modifies the Windows NT installation to provide a closer approximation to
POSIX standards compliance. Unfortunately, because Windows NT was not designed with POSIX
compliance in mind, applications which access files do not generally understand that filenames
with different case may be totally separate and distinct files, as opposed to the default
Windows NT behavior of assuming the names "TestFile.EXE" and "testfile.EXE" refer to identical
files. This feature may allow a user to create a lower-case file within the system path that
may be accessed prior to the intended legitimate system file. In other words, the POSIX
subsystem makes it possible to create a file with a lower case name which will be found in a
search path prior to a file with an upper case name. If the POSIX subsystem needs to be
installed, the directory access control modifications identified above for the system root
directory tree may reduce the risk somewhat, but similar protections should probably be
applied for all directories in the default system and user PATH configuration. To disable the
POSIX Subsystem, delete the following registry key:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Control\Session Manager\SubSystems
Name: Posix
Workstation
and
Server
Premium
Remove the POSIX Subsystem.
Standard
Remove the POSIX Subsystem, unless required for operational reasons.
Basic
Leave as default.
Table 6.2 POSIX Subsystem
6.3 Distributed Components
Unless there is an identified requirement for DCOM, the capability should be disabled. If it
is required, interactive write access to the DCOM "RunAs" capability should be restricted. To
remove interactive user write acces to the DCOM "RunAs" value, modify the following registry
key:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Classes\AppID
Security Permissions: Remove Set Value, Create Subkey, and Write DAC or Write Owner
permissions for the INTERACTIVE account.
Select the option to replace permissions on existing subkeys.
To disable DCOM on this system, modify the following registry key:
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Ole
Name: EnableDCOM
Type: REG_SZ
Value: N
Workstation
and
Server
Premium
Disable DCOM access.
Standard
Restrict access to the DCOM RunAs capability, as determined by a risk assessment.
Basic
Leave as default.
Table 6.3 Distributed Components
7.0 Remote Access Services
The Windows NT Remote Access Service (RAS) allows remote computers to connect to Windows NT
RAS servers across a phone connection, or, using the PPTP protocol, over an Intranet. Once
connected, the client computer functions as if directly attached to the RAS server's Local
Area Network. RAS can be limited to selected users, and has a "call-back" feature where the
server calls back a predetermined or user-specified telephone number to complete the dial-in
connection scenario. Remote access is often from sites where the physical security is not as
strong as the target site, and this could potentially present a significant risk that should
be considered in context of the system security plan. Note that individual accounts can
effectively be restricted to the RAS server by making them local accounts on the server. On a
Windows NT network, local accounts can only access the computer that holds the account, the
RAS server in this case.
7.1 RAS Security
Fixed line RAS usage does provide link encryption, but should be considered. RAS usage from
mobile devices should utilise the encrypted RAS service for both link encryption and PPTP
password negotiation. RAS Dialback should be used on those RAS connections that require a
greater degree of authentication. Note that the compromise of user identification and
authentication, coupled with the use of dialback facilities, could imply that nuisance phone
calls could be initiated against individual staff members with a source number of the agency.
However, correlation of agency telephone records should identify the originating source phone
number if action is required.
RAS Security
Premium
Encrypt all RAS session. Ensure that all clients use separate encryption keys/tokens.
Standard
Enable the "call-back" feature on RAS.
Basic
Enable userid/passwords for all RAS connections.
Table 7.1 RAS Encryption
8.0 Malicious Code
8.1 Anti-Viral Software
Depending on the system security plan, virus checks should be made on any uncontrolled data
that is capable of being infected by malicious code, that enters the agency from all other
networks where comparable virus checking facilities are not available and implemented.
Workstation
and
Server
Premium
Install a memory-resident virus checking application that monitors application calls for
malicious code.
Standard
Install a virus checking application that is scheduled to check the system for viruses on a
regular basis.
Basic
Install anti-viral software based on a risk assessment.
Dialup
and
Gateway
Systems
Premium
Install anti-viral software that monitors all incoming packets that may contain virii.
Standard
Install a memory-resident virus checking application that monitors application calls for
malicious code at least during connection to the agency resources.
Basic
Install anti-viral software based on a risk assessment.
Table 8.1: Malicious Code
9.0 Event Logging
System level event logging is a process that not only requires initial configuration, but also
potentially significant ongoing management resources. As such, any requirement for logging
should be subject to risk assessment, and be based on data owner and general security
requirements. Depending on the configuration of the event logging subsystem, the volume of
information produced may be significant, and plans may need to be made to deal with the
anticipated volume. In general, if there are no plans in place to review or archive the data
produced from the audit subsystem, then there may be very little value in turning on events.
9.1 Windows NT Event Logging
The event logs should be rotated, not overwritten, and saved (be wary of locking the system if
the event log file is full). There should be a procedure to archive the event logs in event of
an attack or other system failure. These commands can be set via User Manager -> Policies ->
Audit. Check that the event log file storage area is accessed only by the Administrator by
checking the permissions of %systemroot%\system32.
Workstation Premium Audit Category Success Failure
Logon and Logoff Levels
ON
ON
Startup, Shutdown & System
ON
ON
Security Policy Changes
ON
ON
User & Group Management
ON
ON
Use of User Rights
OFF
ON
File & Object Access
OFF
OFF
Process Tracking
OFF
OFF
Standard Audit Category
Success
Failure
Logon and Logoff Levels
ON
ON
Startup, Shutdown & System
ON
ON
Security Policy Changes
OFF
OFF
User & Group Management
OFF
OFF
Use of User Rights
OFF
OFF
File & Object Access
OFF
OFF
Process Tracking
OFF
OFF
Basic Audit Category Success Failure
Logon and Logoff Levels
OFF
OFF
Startup, Shutdown & System
OFF
OFF
Security Policy Changes
OFF
OFF
User & Group Management
OFF
OFF
Use of User Rights
OFF
OFF
File & Object Access
OFF
OFF
Process Tracking
OFF
OFF
Server Premium Audit Category Success Failure
Logon and Logoff Levels
ON
ON
Startup, Shutdown & System
ON
ON
Security Policy Changes
ON
ON
User & Group Management
ON
ON
Use of User Rights
OFF
ON
File & Object Access
ON
ON
Process Tracking
OFF
OFF
Standard Audit Category Success Failure
Logon and Logoff Levels
ON
ON
Startup, Shutdown & System
ON
ON
Security Policy Changes
ON
ON
User & Group Management
ON
ON
Use of User Rights
OFF
ON
File & Object Access
OFF
ON
Process Tracking
OFF
OFF
Basic Audit Category Success Failure
Logon and Logoff Levels
OFF
OFF
Startup, Shutdown & System
OFF
OFF
Security Policy Changes
OFF
OFF
User & Group Management
OFF
OFF
Use of User Rights
OFF
OFF
File & Object Access
OFF
OFF
Process Tracking
OFF
OFF
Table 9.1: Auditing
9.2 Additional Events - Backup and Restore
By default, Windows NT does not record events relating to the use of the backup and restore
rights. 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 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. To ensure that these rights are audited
also, set or create the following registry key:
Hive: HKEY_LOCAL_MACHINE\System
Key: \CurrentControlSet\Control\Lsa\
Name: FullPrivilegeAuditing
Type: REG_DWORD
Value: 1
Workstation
Premium
Set auditing for backup and restore rights, as required by the risk assessment.
Standard
Do not set auditing for backup and restore rights.
Basic
Do not set auditing for backup and restore rights.
Server
Premium
Enable auditing for backup and restore rights.
Standard
Set auditing for backup and restore rights, as required by the risk assessment.
Basic
Do not set auditing for backup and restore rights.
Table 9.2 Additional Events - Backup and Restore
9.3 Additional Events - Base Objects
"Base objects" are internal Windows NT objects not in the file system or Registry. Users do
not usually see or directly manipulate base objects although their programs may access them.
Windows NT does not log access to these objects by default. Note that logging these events
tends to flood the security log with events of little security relevance to most
administrators. To enable base objects auditing, set or create the following registry key:
Hive: HKEY_LOCAL_MACHINE\System
Key: \CurrentControlSet\Control\Lsa\
Name: AuditBaseObjects
Type: REG_DWORD
Value: 1
Workstation
and
Server
Premium
Set logging as determined by a risk assessment.
Standard
Do not set logging for base objects.
Basic
Do not set logging for base objects.
Table 9.3 Additional Events - Base Objects
9.4 Log Access Restriction
Access logs can often reveal significant details relating to user usage patterns, and
application installations. Restrict Guest access to the audit logs for Application and System.
Although Security is already protected through different mechanisms, you may wish to apply the
same key entry for consistency. Also, be sure to set the proper access control on the registry
key (which you may need to create), as follows:
Hive: HKEY_LOCAL_MACHINE\System
Key: \CurrentControlSet\Services\EventLog\Application\
Name: RestrictGuestAccess
Type: REG_DWORD
Value: 1
Security Permissions: Allow read/write for Administrators and System only.
Hive: HKEY_LOCAL_MACHINE\System
Key: \CurrentControlSet\Services\EventLog\System\
Name: RestrictGuestAccess
Type: REG_DWORD
Value: 1
Security Permissions: Allow read/write for Administrators and System only.
Hive: HKEY_LOCAL_MACHINE\System
Key: \CurrentControlSet\Services\EventLog\Security\
Name: RestrictGuestAccess
Type: REG_DWORD
Value: 1
Security Permissions: Allow read/write for Administrators and System only.
Workstation
and
Server
Premium
Restrict Guess access to Application, Security and System logs.
Standard
Restrict Guess access to Application, Security and System logs.
Basic
Leave as default.
Table 9.4 Log Access Restriction
9.5 Time Synchronisation
The difficulty associated with evaluating audit events over multiple servers is multiplied
when the operating systems are not time synchronised. The simplest way is to synchronise the
servers is nominating one server as having the base time, and using the schedule service to
run the "NET TIME" command every 24 hours. Alternatively, you may wish to set the server to
hook into a NTP (Network Time Protocol) hierarchy.
Workstation
and
Server
Premium
Establish an NTP hierarchy for workstations.
Standard
Use a scheduled NET TIME command to synchronise hosts.
Basic
Determine whether to time synchronise hosts, based on the outcomes of a risk assessment.
Table 9.5 Time Synchronisation
______________________________________________________________________________________________
Appendix A
Explanation of Windows NT Services
ALERTER: Relies on NetBIOS over TCP/IP for network communication. This service allows a user
to receive messages from other machines. These messages could be warnings or some type of
pre-determined network information. Recommend disabling the Alerter service on machines due to
its NetBIOS dependancy and the fact that it is hardly ever used.
CLIPBOOK SERVER: Relies on NetBIOS over TCP/IP for network communication. This server service
allows the contents of the clipboard to be shared over a network. Few use it, and it is
recommended that it should be disabled due to the ability of a remote intruder possible
gleaning sensitive information.
COMPUTER BROWSER: The Computer Browser service allows one to view available network resources
by browsing via Network Neighborhood. When active on a server, the server will register its
name through a NetBIOS broadcast or directly to a WINS server. It is recommended that the
service be disabled unless strictly required.
DHCP CLIENT: This service should be set to automatic if the machine is a dhcp client, if not,
disable it.
DIRECTORY REPLICATOR: This service allows NT systems to import and export directory contents.
If content replication is not needed, disable this service.
EVENT LOG: Responsible for logging activity on the host, including security activity.
LICENSE LOGGING SERVICE: Used to track use of licenses by different applications, it does not
have any serious impact on the network and should be set to automatic (which is the default
setting).
MESSENGER SERVICE: Relies on NetBIOS over TCP/IP for network communication. Similar to the
Alerter service in both design and function. Recommend stopping this service to prevent
username enumeration via NBTSTAT commands.
NET LOGON: This service is used by both Server and Workstation to provide for user
authentication. This service is said to be required at all times and runs as the built in
SYSTEM user.
NETWORK DDE and DDE DSDM: These service provide dynamic data exchange. DDE is used for such
applications as Chat, and other applications that may require this type of functionality.
These services are considered to be a moderate risk due to their TCP connection accepting
states.
NETWORK MONITOR AGENT: Network Monitor Agent is used to monitor, or sniff, the traffic passing
through a network adapter card. If the SMS version of this software is in use, an
administrator can remotely monitor traffic on other network adapter cards.
NTLM SECURITY SUPPORT PROVIDER: This service is present to help with backwards compatibility
and authentication with older software packages.
PLUG AND PLAY: Used to automatically configure PnP devices.
REMOTE PROCEDURE CALL LOCATOR AND SERVICES: RPC is a protocol that is used to encapsulate
function calls over a network. Its default configuration, automatic, is standard and should be
left alone. This service is considered to pose a high security risk, but the dependancies
existing on this service may be too great to disable it.
ROUTING AND REMOTE ACCESS SERVICE: This is an add-on service that enhances the functionality
of Windows NT. If you are using a modem to dial-out of your NT system, this service should be
set to automatic. If you are using its routing features, also set it to automatic. In general,
it should be disabled.
SCHEDULE: This service allows an application to be executed at a pre-specified time and date.
This can pose a serious security threat as this service can be used to start applications
under the SYSTEM context.
SERVER: Used as the key to all server-side NetBIOS applications, this service is required.
Without this service, some of the administrative tools, such as Server Manager, could not be
used. If remote administration or access to the machine is not needed, highly recommend
disabling this service. Contrary to popular belief, this service is NOT needed on a webserver.
SPOOLER: The spooler service is used to accept requests for print jobs from clients, and to
allow the local system to spool jobs to a network printer. This service should be set to
automatic.
TCP/IP NETBIOS HELPER: This service helps and enhances NBT and the Net Logon service. Because
the Net Logon service should be set to automatic, so should this service.
TELEPHONY SERVICE: This service is used to manage telephony drivers and the properties for
dialing. On a system that does not use any type of telephony or RAS devices should have this
service disabled.
UPS: This service is used in serial communication with an Uninterruptible Power Supply.
WORKSTATION: This service allows for outbound NetBIOS connections. Because it is used in
outbound connections only, it is normally not a security risk and should be set to automatic.