The IT Security Cookbook - Securing Windows NT (3.5 - 4.0)

  • A quick guide to securing NT
  • General
  • Accountability
  • Access Control
  • Secure data exchange / communications
  • Routing
  • Availability
  • Security Tools (link to Part 2) 

    A quick guide to securing NT

    • Users: Ensure that good passwords (mixed case, punctuation, numbers) are used by users and staff. Disable or change default passwords. Use the available password checking mechanisms to ensure that good passwords are chosen. Set a maximum age, minimum age, length and history uniquemenss according to the system sensitivity (e.g. 180, 1, 8, 5).
    • Setup a legal notice for the logon box.
    • Install C2config from the resource kit, configure all C2 items except halt on audit failure, Posix and network services.
    • Install DumpAcl and use it to regularly check for strange modifications in the system.
    • Install Regsnap to compare snapshots of the registry & system files. Useful for monitoring and following installations / deinstallations.
    • NT4: Install service pack 3 and consider enabling encrypted passwords and password filtering.
    • Consider disabling remote access to the registry.
    • Use automatic screen locking with password protection.
    • Disable the guest account if possible, otherwise add a password.
    • Don't trust domains that are not trust worthy. Reboot after removing trusts.
    • Share directories restrictively, read-only where possible and never allow everyone write access.
    • Use NTFS rather than FAT filesystems.
    • Update your Win95 & WfW clients with the password security patch, even better disable caching.
    • Enable Auditing on important files (e.g. registry, logon scripts) and events (logon/logoff).
    • Monitor the logs regularly for strange behaviour.
    • Use the performance meter (or something similar) to monitor the system.
    • Setup regular backups, test restores. Backup the registry to a file regularly.
    • Use backup domain controllers & replication to increase logon availability.
    • Use RAID or disk syncing to improve availability of NT shares. Keep a warm copy of the boot disk and provide dual booting (e.g. by using DriveImage).
    • Update the emergency repair disk regularly (with the /s option to rdisk.exe). 
    • See also the section NT as an Internet Server below.
    • A few registry entries that I find important can be found in nt_tips.reg. If using it, please download it, open it with an editor, make sure you understand what the changes are, adapt if necessary, then double click on it to install it. They have been tested on NT4 SP3. Hopefully I'll update this file with new entries now and again.

    General

    Some useful tips for NT:

    • File completion: If the following registry entry is set to 9, NT will complete file names on the command line with the tab key:
      HKEY_CURRENT_USER\Software/Microsoft/Command Processor/CompletionChar

    Reference Documentation

    Ref. Document number  Ver. Title Date Author
    [nt1] Technet CD    Enterprise Planning Guide - Security  May'95 Microsoft
    [nt2] ISBN 1-55615-653-7  3.5 NT resource Toolkit  1995 Microsoft
    [nt3] ISBN 1-55615-814-9    Windows NT 3.5 Guidelines for Security, Audit and Control  1994 Microsoft
    [nt4] Technet CD  5.95 Enterprise Planning Guide - Domains  May'95 Microsoft
    [nt5] Technet CD /Backoffice  5.95 The Microsoft Strategy for Distributed Computing and DCE Services  May'95 Microsoft
    [nt6]   3.5 NT Server "Concepts and Planning Guide"    Microsoft
    [nt7] The Perl Journal #8 Issue #8, "NT Administration with Perl" Winter 1997 Dave Roth

    Assurance

    • The basic security architecture and design is good, but the implementation is not without problems (see next section).
    • In August 1995, NT 3.51 (not NT4) was certified as being C2 conform in a special non networked (!) configuration (see also the chapter "OS Overview" ). NT with networking is being certified at the moment (Dec.'98).
    • Microsoft does not openly discuss security problems/algorithms, nor subject them to peer review. Their principle seems to be Security through Obscurity. Until authentication and encryption methods used in NT are well known, subjected to intense peer review, NT cannot be considered as a Trusted System. This situation improved in spring 1997 with Microsoft dedicating a portion of http://www.microsoft.com/   to security.
    • NT is still young, certain parts of it's security functions are not well understood. 

    Principal dangers

    The principal dangers with NT are:

    • Unauthorised access due to accounts with weak passwords or no password (such as guest).
    • Unauthorised access due to mistakes: users added to wrong groups, shares with wrong permissions, files with wrong permissions, too many rights given to users, misconfiguration of RAS.
    • Unauthorised use of privileges.
    • Unauthorised monitoring of network traffic.
    • Denial of service attacks (lots of new different attack methods were reported in 1997).
    • Deletion/changing of security log entries.
    • The registry, being a central configuration database is a weak point, especially since it can be remotely edited from Win95 and NT clients (better in NT4/SP3).
    • An entire domain can be compromised if one of it's servers is subverted. 

    Current known problems/dangers

    NT has lots of good points (compared with Win95 or Win3.1), but it is not without it's problems. The following is a list of known security problems and administrative problems.

    • The guest account is enabled in V3.5 by default: On a new V3.5 server installation, all drives on the server are shared to everyone. As guest login is enabled with no password, these drives can be mounted from any client. The registry can be changed (certain entries) over the network by any machine. If the guest account is disabled or a password it set, the problem disappears. On V3.51, the guest account is disabled by default.
    • To share printers or files with:
      • non-NT computers outside the current domain (and where no trust exists), the guest account must be enabled without a password. If this is necessary then everyone read and write access on the filesystem should be removed where not absolutely necessary (see printing section on the following page).
      • NT computers outside the current domain (and where no trust exists), it is enough to create the same user accounts with the same passwords (or a guest account with a password known to those who need to access the resource).
    • On NT4.0, fewer 16 bit programs work. Stay with 3.51 if 16-bit applications are needed.
    • NT has a defined list of rights which can be attributed to users or groups. However certain rights cannot be attributed, they are built in to NT. This is a serious limitation and has not been fixed in V4.0.
    • NT Network: it is not possible to share directories to specific hosts only. The ACL can include users and groups but not host names.
    • An administrator (or correspondingly privileged user) cannot change the ownership of files. To achieve change of ownership, he must attribute the Take Ownership Right to the said user, this user must take ownership of the required files and then the right must be revoked. This is very messy and subject to abuse.
    • No email system is (yet) bundled with NT, but MS-Exchange is available separately. There is no email command line utility for use in scripts.
    • The NT scripting language is a laugh. Fortunately, Perl is delivered with the NT resource kit (3.51 and later). Hopefully it will become the standard scripting language of NT.
    • Logins in to remote hosts is not supported. Command line login in to remote machines is possible through the resource kit command remote command.
    • The NT system logging mechanism (event log), while quite good, does not offer centralised logging for a group of machines.
    • If a domain trusts another domain, the User Manger shows the entire list of users and groups in both domains, making it difficult to manage users. A custom filter mechanism would be nice.
    • A serious danger posed is caused not by NT, but by Win95 & WfW: password caching. This little feature can compromise your whole network. SWITCH IT OFF.
    • Trusts: A domain can trust another domain. The former is the trusting domain and the latter the trusted domain. The administrator on the trusted domain can see all user accounts and their details on the trusting domain but cannot change them. Seeing them alone is enough to perhaps find open of weakly configured accounts.
    • There is no user accounting system, no disk defragmentation utility, no disk quota system.
    • Changing a driver or installation an application generally requires a reboot.
    • You cannot set a limit on the number of failed logon attempts to the administrator account. It would be nice if, for example after 5 false attempts, administrator logon was blocked for 5 minutes. This would reduce greatly the number of possible login attempts per hour possible during a logon attack.
    • The Win32 development API is different on NT and Win95!
    • The job scheduler (at) runs in the security context of the system, not the user which submits the job. The at scheduler is far too primitive for administration of large important servers. It doesn't even approach the UNIX cron utility (which also is not without fault).
    • NT4 has several "denial of service attack" weaknesses. Basically the server hangs (CPU at 100%) up if unexpected data arrive at certain ports such as DNS, 135, 1031 etc.. SP3 fixes these issues, but there are always more such weknesses lurking. 

    NT as an Internet Firewall / Internet server

    NT is only suitable as an internet server if protected by a filter and very carefully setup. See also the Firewalls Chapter:

    • make sure that the NT firewall is standalone (not part of a domain) and that is trusts nobody!
    • WWW servers:
      • don't mix internal and external WWW servers on the same machine.
      • run WWW servers as separate domains or standalone.
      • run the WWW service under a dedicated user which has no access to other files on the system.
      • avoid .BAT files, never use FAT filesystems, only NTFS.
      • don't put interpreters such as PERL in the cgi-bin directory.
    • Consider revoking the "Access from network" privilege, making it difficult to attack from the Internet, but more difficult to administer.
    • Read Microsoft's checklist for IIS and NT4 www.microsoft.com/security/products/iis/CheckList.asp
    • Remove a maximum of services, or set their startup values to "manual". If possible, disable: NetBIOS, Computer Browser, Network monitor tools, Remote Access, RPC (difficult), Alerter, Messenger.
      Disable one at a time & observe the effects, you may find that RPC cannot be disabled. Then at least make sure that RPC is blocked by the firewall filter of the NT server.
    • Disable Netbios over TCP/IP on the Internet interface (unless you *really* want to publish NT shares across the Internet). Use NetBEUI for shares locally (but avoid these too).
    • Consider renaming the administrator account to something unusual (I'm not that convinced of this though)
    • Install a filter between the NT server and the Internet and allow only the necessary ports through (e.g. 80 for WWW, FTP 20/21). Avoid especially allowing NBT (137,138,139)  or Netbios/RPC (111, 135) for remote administration. 
    • NT4 allows a TCP/IP filter to be configured at kernel level that specifies what IP addresses  can access which TCP ports, UDP ports or IP protocol number.
      • see Network properties -> protocols -> TCP/IP ->  IP address -> Advanced -> Enable Security -> Advanced. Difficult to use though.
      • This can be useful for configuring the inside interface or for limiting access to the outside interface (especially to UDP ports). It does not work on dial-up interfaces.
      • There is a limitation however: either all ports or specific ports are allowed, you can deny specific ports.
    • NT4/SP3 also allows the user passwords stored in the registry (normally only in obfuscated form) to be encrypted. Refer to KB Q143475 and syskey.exe. This makes cracking the entries available in the registry much more difficult, but requires careful implementation. 
    • Disable SNMP.
    • Check recent CERT & MS advisories for weakness/fixes to services you have enabled.

    NT workstation

    • Make sure that the global Admin group is part of the local Admin group (net localgroup Administrators).
    • Avoid Trojan horses: User should always use CTL-ALT-DEL to logon/logoff/lock screen.
    • Do not allow power user to create local users -> Set musmgr.exe permissions accordingly (cacls musmgr.exe /E /R Everyone).
    • Disable guest account (net user Guest /active:no).
    • Use User profiles: Restrict program manager functionality [1]
    • Restrict Control panel [2]
    • Remove MS-DOS prompt (cacls cmd.exe /E /R Everyone), if possible.
    • Consider restricting floppy disk access: use NT floppy lock [3]. (Note: not tested successfully)
    • Remove regedt32.exe, configure registry from network, or only allow execution by the administrator (cacls regedt32.exe /E /R Everyone)
    • Customise *.inf [4].
    • Disable Workgroups. 

    Accountability

    Identification / authentication

    NT only offers one mechanism for identifying/authorising and authorising users: Lan Manager 3 (either as peer to peer or in a domain configuration).

    • NIS, NIS+, FNS or Kerberos are not directly supported, but some of these are available from third parties. The "GINA" DLL can be replaced to achieve this. But if you try to use two programs which want to access Gina, it will break.
    • NT provides a secure logon sequence to avoid trojan horses. The user must press CTL-ALT-DEL to logon, logoff or lock the screen. This is a very useful feature and users should be trained to use to expect it and use it to lock unattended screens. I don't know how secure the sequence is, since it can be sent remotely in programs sucha s PC Anywhere.
    • Passwords are sent encrypted over the network, if the client is Lan Manager 2 or a Microsoft client (Win95, NT), otherwise the password is sent in clear text (e.g. with older versions of Samba and Windows). The encryption algorithm is based on challenge response and hashing. The fact both clear text and encrypted password are supported, can allow certain attacks whereby the attacker convinces the server to ask for clear text passwords and then sniff them on the network.

    NT Domains / Lan Manager 3.0

    Lan Manager identifies subjects via usernames and authenticates via entry of a password.

    • See also the "Policy" chapter.
      • The account policy has the following defaults: force logoff if session is idle for 40 mins, password must be min. 6 characters and must be changed every month for a minimum of 14 days. The last 3 passwords used must be unique, the reset count is 20 minutes and the lockout duration 60 minutes (when a password is incorrectly entered 3 times).
      • It is suggested that the policy be set as follows : force logoff if session is idle for 1000 mins, password must be min. 6 characters and must be changed every 3 months for a minimum of 3 days. The last 5 passwords used must be unique. Up to 5 incorrect logins should be allowed, with a lockout duration of 12 hours and reset count of 12 hours. Unfortunately not all parameters can be set on the command line, but here is an example anyway:
        net accounts /forcelogoff:1000 /minpwlen:6 /maxpwage:90 /minpwage:3 /uniquepw:5 /domain
        net accounts /sync

        To view the current settings, type
          net accounts /domain.

    • Consider changing the name of the Administrator account. Protect the administrator password (keep in a locked safe), change passwords regularly. Delete the Administrator from the domain user's group.
    • Create a special account for each administrator, with the rights needed. Train the administrators to use their own personal accounts when not executing administration functions.
    • Display legal notice when before the user logs in: (via c2config.exe or via HKEY_LOCAL_MACHINE Software\Microsoft\WindowsNT\CurrentVersion\Winlogon: LegalNoticeCaption, LegalNoticeText).
    • Automatic logon should be disabled (this is the default): via c2config.exe or via HKEY_LOCAL_MACHINE Software\Microsoft\WindowsNT\CurrentVersion\Winlogon, either AutoAdminLogon should not exist or be REG_SZ : 0. Likewise DefaultPassword should not exist.
    • The net session command can be used to view users connect to a server.
    • Restrict the workstations that a user is allow to log onto.
    • Don't restrict logon times unnecessarily, but for sensitive systems, consider restricting login times for users: net user USER_NAME /times:Monday-Friday,06-19.
    • With NT4/SP3, it is possible to enable a password filter (to increase password strength) on the PDC and BDCs. The policy implemented is: minimum 6 characters, made up of at least 3 of the 4 following groups: A-Z, a-z, 0-9 and ".,;:*&%!+" and may not contain the username. See also the knowledge base article Q151082.
      The following registry entry is needed:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
      Value: Notification Packages
      Type: REG_MULTI_SZ
      Data: Passfilt.dll

    • The SMB password exchange is set to refuse clear text passwords if SP3 is installed on NT4. This is good from a security point of view, but it may then refuse access to other SMB servers such as SAMBA. See also KB Q166730 for a workaround.A good solution is to upgrade Samaba to a version that supports "pass through" authentication to an NT server or supports encrypted passwords.

    Guest Account

    • If the guest account is needed, assign a password.
    • Disable the Guest account (Prevent remote registry and share abuses from unknown users):
      net user Guest /active:no /passwordreq:yes
    • Do not allow guest to log onto the server console. Revoke the log on locally right.
    • The guest account should only belong to the guest group, i.e. not Administrators or Domain users!
    • To share printers or files with computers outside the current domain (and where no trust exists), the guest account must be enabled without a password, or with a password known to all those who wish to access the resource. If this is necessary then everyone read and write access should be removed from resources & files where it is not absolutely necessary (see the "Filesystem" section). Also guest access should be restricted to a specific list of machines:
      net user Guest /active:yes /passwordreq:no /workstation:host1,host2
    • In NT4/SP3, anonymous access to the registry is forbidden, by use of a new "Authenticated Users" groups that basically includes everyone except the anonymous user. 

    Temporary Users

    • Accounts should be configured to expire on a certain date.
      net users USER_NAME /expires:30/12/96 /domain
    • Accounts should only be usable from certain workstations.
      net users USER_NAME /workstations:computer1,computer2,computer3 

    User Groups

    • Carefully consider who manages what part of the system.
    • NT groups uses "User Groups" to separate responsibilities. There are local groups and global groups:
      • Local groups on a workstation are limited to that workstation (view via net localgroup).
      • Local groups in the domain are visible in the entire domain (view via net localgroup). They can only be assigned permissions in the domain it belongs to. Local groups can contain users and global groups from the local and trusted domains, but not other local groups.
      • Global groups in the domain are visible in the domain and all domains who trust this domain (view via net group /domain). Global groups can only contain members (users, not localgroups) from it's own domain.

    By default, NT separates tasks into the following groups:
     

    Function NT Workstation group  NT Server group 
    Advanced System administrators  Administrators Administrators
    Basic administration (disks/sharing)  Power Users  Server operators 
    User account creation/deletion  Power Users  Account operators 
    Printer configuration  Power Users  Print operators 
    System backups/restore  Backup operators  Backup operators 
    Any user at all Everyone Everyone
    normal users Users Users
    Guest Guests Guests

    It is suggested that a new group be created: Security Administrators, having the rights listed in the next section "Rights".

    TBD: define global groups and how they relate to the above. 

    Rights

    NT has a defined list of rights which can be attributed to users or (preferably) groups. Rights is the term for what a user is allowed to do on a system. E.g. if a user has the "log on locally right", this user will be allowed to login to the machine console. Certain rights cannot be attributed, they are built in to NT. For instance, if you want allow an administrator to be able to share filesystems & printers, but not be able to carry out other administrator functions, it is not easy (you'd need to remove rights such as Backup/Restore/Shutdown/Change time from the Operator group and use that for sharing alone).

    • Grant privileges to groups, not users, where possible.
    • Avoid giving the Take Ownership right to users or operators.
    • Be very careful about who has restore rights - they can overwrite any file.
    • Be very careful about who has backup rights - they can read any file.
    • Attribute "Advanced User Rights" with caution.  Keep a log on paper of which users have "Advanced User Rights".

    TBD: Bypass Traverse Checking: If this right is disabled (in the User Manager), a user must have list permission on a directory before being able to execute a program in it.

    The following table recommends what rights should be attributed to what (NT Server local) groups. Note the addition of the new group Security admins. The basic rule is: attribute the minimum rights necessary to each group.

    Legend:
    "Yes" => NT default, keep this value
    "Yes" => NT default, remove this value
    "New" => Add this value
     

            Group      
    Right Users Security
    admins     		 Backup
    oper.     		 Administrators Printer
    oper.     		 Account oper.  Server oper. 
    Backup files and directories      Yes Yes     Yes
    Restore files and directories      Yes Yes     Yes 
    Change system time        Yes     Yes
    Access this computer from a network Yes*[5] Yes** Yes** Yes Yes** Yes** Yes**
    Log on locally    New Yes Yes Yes Yes Yes
    Manage audit and security log    New   Yes      
    Force shutdown from a remote system        Yes     Yes
    Shutdown the system      Yes Yes Yes Yes Yes
    Add Workstation to domain        Yes   New New
    Load/unload device drivers        Yes      
    Take ownership of files / objects.        Yes      
     
    Built-in rights (cannot be changed): 
    Create & manage user accounts         Yes   Yes**[6]
    Create & manage global groups        Yes   Yes**   
    Create & manage local groups  Yes[7]      Yes   Yes**  
    Assign user rights       Yes      
    Lock the server        Yes     Yes
    Override the server lock             Yes
    Format server's hard disk        Yes     Yes
    Create common groups        Yes     Yes
    Keep local profile      Yes Yes Yes Yes Yes
    Share & stop sharing directories       Yes     Yes
    Share & stop sharing printers        Yes Yes   Yes
     
    Advanced rights: 
    Act as part of the operating system               
    Bypass traverse checking (TBD: test!!) Yes Yes Yes Yes Yes Yes Yes
    Create a pagefile       Yes      
    Create a token object               
    Create permanent shared objects               
    Debug programs        Yes      
    Generate Security Audits    Yes          
    Increase Quotas        Yes      
    Increasing scheduling priority        Yes      
    Lock pages in memory               
    Log on as a batch job               
    Log on as a service               
    Modify firmware environment values        Yes      
    Profile single process        Yes      
    Profile system performance    Yes   Yes      
    Replace a process level token               

    The Everybody local group has the right to log on over the network and to lock the server (although only those users who can log on locally will actually be able to do it). Everybody also has the Bypass traverse checking right.

    The Replicator group has the right Log on as a service. 

    User Profiles (for NT clients only)

    Mandatory user profiles[8] (or User Login Profiles) may be used to restrict user access to: Program manager functionality, program groups, Control panel, access to the MS-DOS prompt. Mandatory user profiles also make it very easy to install new icons groups for all users, however the user cannot have any "personal settings" like desktop colours, layout etc.. The profile editor (upedit.exe) is used to manage profiles and the User Manager attributes a profile to a particular user.

    Use mandatory user profiles to restrict the icons/programs to dedicated administrator users (if any exist).

    User Environment profiles do not offer any particular security benefits, but roaming users are presented with the same interface everywhere. The profile file (*.usr) must be stored on a shared directory. 

    Domain Controllers

    • Install backup domain controllers to insure availability, if user profiles and logon scripts are kept on the PDC, replicate them to each BDC.
    • Install PDCs in locked server rooms. 

    Logon scripts

    • NT 3.51: If the login script finishes too quickly, enable the option Wait for logon Script to complete before starting program manager in the User Profile Editor for the default user profile.
    • Since the logon script (root\system32\Repl\Import\Scripts) is shared to everyone (as NETLOGON$), anyone can read the script. AVOID putting any confidential information in the logon scripts (e.g. passwords)!
    • NETLOGON$ should be shared read-only (i.e. no write access) to everyone.

    The logon script can be used to:

    • Set system time if no time synchronisation tool (such as NTP) is available e.g. to set the time to that of the PDC: via net time \\server1 /set /yes or net time /domain /set
    • Setup standard shares (standard shares are important to avoid user mistakes).
    • Install the latest virus checker software, if it is not already installed, or update it.[9]
    • Run the virus checker if it is not part of the boot process.
    • Download certain configuration files to obliterate user manipulations.
    • The following environment variables are available for use in login scripts: %HOMEDRIVE%, %HOMEPATH%, %HOMESHARE%, %OS%, %PROCESSOR%, %USERDOMAIN%, %USERNAME%. Other variables may be viewed by entering the set command.
    • A message alias can be set for users in their login script. E.g. net name john /add. This must be run on john's workstation. 

    Naming Services

    DNS

    See the Network security chapter. DNS can be used for Netbios name to IP address resolution, if so configured in Control Panel->Network->TCP/IP->DNS. 

    DHCP

    See the Network security chapter for a general discussion of DHCP. DHCP basically allows a client to boot and request network configuration parameters from a DHCP server on the network. The client sends his MAC address and the server can use this address to uniquely identify the machine, if needed.

    • WINS will need to be running for DHCP to work properly.
    • DHCP as offered in NT allows setting of the following parameters for clients, allowing highly automated client installation: IP address, Client name, Default routers, DNS servers, domain name and WINS configuration. 

    WINS

    WINS allows Netbios name to IP address resolution via a highly automated dynamic database. It reduces the need for LMHOSTS files. See "NT Server TCP/IP" 3.5, Chapter 5 (page 105) for configuration. WINS can be started/stopped on the server via net start wins or net stop wins. The WINS administration tool is winsadmn.

    • Enable standard logging.
    • Specify a Database Backup Path as being in a local directory and switch on Backup on termination.
    • Specify static mappings for important servers.
    • If static mappings are necessary, they can be kept in a local file which can be used to initialise the database on startup, by setting the registry parameters \SYSTEM\CurrentControlSet\Services\Wins\Paramaters\Datafiles to a list of files. 

    IP Naming service files

    TCP/IP reads not just the DNS records, but flat ASCII files (in root\winnt\system32\drivers\etc by default) to discover IP addresses (hosts), network names (networks), protocols (protocols) and services (services). This data is not kept in the registry.

    • If these files are used, make a backup before changing them. Consider synchronising these files across all servers. 

    System logs & Monitoring

    A system administrator who regularly checks logs will learn a lot about how the system functions, can guarantee less downtime and at the same time should notice when security breaches occur. Monitoring logs should not be regarded as a boring job, but a chance to understand the guts of the system!

    The NT event log centralises logging for most applications into three logs: the security log (covered in the following section "auditing"), the system and application logs. However logs are not centralised for a group of machines (unfortunately). These logs are in root\WINNT35\system32\config and may be viewed with GUI eventvwr or via the command line utility dumpel.

    • The security log secevent.evt should be restricted so that it may only be viewed by the security administrator.
    • A maximum size should be specified (for example 100 MB).
    • When event log starts to fill up, it can be configured to "overwrite events older than 7 days" (this assumes that at least weekly full backups are made). See Event Viewer->Log->Settings.
    • To avoid a system crash if the log fills up use c2config.exe or set the registry flag \System\CurrentControlSet\Control\Lsa\CrashOnAuditFail.
    • For class  systems, consider writing logs to WORM or a printer. It's the only way of being such that logs are not deleted during an attack. To change the directory where the log is stored, change the registry entry \System\CurrentControlSet\Services\EventLog\Security.
    • For automatic analysis, you'll probably need to build customised scripts (use perl5, which has built-in functions for reading/writing logs). The following Perl script would show the events for the date 4th May. 1996:

      dumpel -l security | perl -ne "if (/04\/05\/96/) {print ;}"
      dumpel -l system | perl -ne "if (/04\/05\/96/) {print ;}"
      dumpel -l application | perl -ne "if (/04\/05\/96/) {print ;}"

    • More complex Perl scripts for daily log analysis are to be found in Appendix D. One example is dumplog.cmd which reports interesting entries in the three logs and sends them to the administrator via SMTP email (using the postmail utility). The dumplog utility should be run from the scheduler each night (the scheduler must be started first, see Control panel->services->Scheduler):
      at 23:50 /EVERY:m,t,w,th,f,S,su c:\util\security\dumplog
    • Basic statistics about machine usage can be had from the following commands. These could be used in a weekly or monthly monitoring script which emails this data automatically to the administrator.
      net statistics server
      net statistics workstation
      net share
      net file
      net view \\COMPUTER_NAME
      net session \\COMPUTER_NAME 

    Performance monitor

    NT gathers an great deal of statistics on system usage. Regular monitoring of these statistics can help to detect strange system behaviour using the GUI perfmon. Alerts can be set if predefined thresholds are achieved. The following is the mere tip of the iceberg!

    • To start disk performance monitoring (i.e the Logical Disk object in the performance meter), type diskperf -Y and reboot.
    • Disk performance will be degraded by perhaps 10%, so on heavily loaded servers it is perhaps better to use the performance monitoring now and then to find bottlenecks.
    • Selected events may be logged. In addition a sublog may be generated with just a subset of a full log file.
    • Bookmarks may be used for easier navigation in large log files.
    • Server performance:
      • observe the memory/page faults per second and Commit Limit and set an alert to this limit + 10%.
      • The pagefile size should be bigger than this value.
      • If the processor/percent CPU is less than 100%, then you system is not CPU bound and adding processors won't help performance!
      • The process object Working Set can be helpful in finding out which applications are hogging memory.
    • Workstation performance: As servers above, plus monitor working set size.

    Auditing

    NT offers quite good auditing features (in comparison to most UNIX systems for example). Selective auditing of objects (files, directories, printers etc.) is possible on a per user basis. However, high-level "big picture" auditing tools are lacking.

    • The utility c2config.exe can be used for quick (and simple) one-time-audits of servers.
    • The utility DumpAcl is useful for one-time-audits of system configuration (see the tools section).
    • Regsnap is useful for monitoring registry changes and system files.
    • TBD: Perl scripts for system integrity checking (with DumpAcl)
    • Recovers and reloads of NT are not logged. Neither are control panel settings, event log settings.
    • Logs can be cleared to hide actions ==> archive frequently.
    • Intensive logging degrades performance. 

    Event Auditing and the security log

    Switch on the following auditing in the "User manager->Policies->Audit" [10], depending on the data sensitivity:
     

    Permission Class  Class  
      Successful Failure Successful Failure
    Logon/logoff X X X X
    File & Object access        X
    Use of user rights    X   X
    User & group management    X X X
    Security policy changes    X X X
    Restart, shutdown, system    X X X
    Process tracking        X

    File Auditing

    Audit access to certain important files ("file manager->security->audit") should be enabled. Two types of files are given with slightly different access auditing.
    Type 1: root\winnt35\system32\config\secent.evt, registry key files, regedt32.exe
    Type 2: root\winnt35\ntsetup\config.sys, logon scripts, root, winnt35, system32.
     

    Permission Type 1  Type 2 
      Successful Unsuccessful Successful Unsuccessful
    Read   X   X
    Write X X   X
    Execute X X   X
    Delete X X   X
    Change ownership  X X   X
    Take ownership  X X   X

    Registry auditing

    The registry is very important to NT and must be protected to prevent compromise of the system. It is organised like a filesystem tree and permissions / auditing attributes may be set per leaf as with NTFS files (see regedt32.exe). Logging all access would probably generate huge logs, but selective auditing of particular keys could be useful. Registry auditing could be enabled when a security breach is suspected, but not confirmed. 

    • Auditing of success or failure of the following actions on registry keys is possible:
      Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Create Link,
      Delete, Write DAC, Read Control
    • Another strategy is just to audit access to the registry files (see above), to minimise log entries. 

    Network Connection Auditing

    Connections can be monitored (e.g. for strange names, new and unexpected use of resources) with net session, net use and the resource kit network monitor. 

    Clipbook Auditing

    Can be used if required for applications that use the Clipbook (clipbrd.exe). Can generate many log entries. 

    Network Services logging

    Certain services can be configured to log their actions, e.g. ftp, RAS, PPP. See the Network Components section. 

    Printer Auditing

    Auditing is set in Printer Manager->Security->Audit.

    Printers used for printing confidential information should have the following events audited for failure: Take Ownership, Change permissions, Delete, Full Control.
    Optionally, successful use of Print, Take Ownership, Change permissions, Delete can be enabled. 

    Access Control

    Objects are protected by a two different methods, rights/privileges (discussed in the Identification/authentication section) and permissions (or Access Control Lists, discussed in this section). Rights are attributed to users through their account properties and the groups they belong to, permissions are assigned to objects managed by NT. The following pages discuss the different permission mechanisms for the principal objects in the NT system. 

    The NT Registry

    The registry is a database containing configuration parameters for NT and applications and it is split up into several logical trees, physically stored in files in %SystemRoot%\system32\config:
     

    System HKEY_LOCAL_MACHINE\SYSTEM
    software HKEY_LOCAL_MACHINE\software
    default  
    system.alt  backup copy of system hive
    security HKEY_LOCAL_MACHINE\security
    sam HKEY_LOCAL_MACHINE\sam (security account manager)
    userdef  
      HKEY_USERS
      HKEY_CLASSES_ROOT, HKEY_CURRENT_USER (a pointer for the current user into HKEY_USERS)
      HKEY_CURRENT_CONFIG (a pointer into HKEY_LOCAL_MACHINE\System\CurrentControlSet)

    There is also a LOG file associated with each of the above, in which changes are written before being checkpointed. The registry may be directly edited via the regedt32.exe tool.

    TBD: what should the NTFS file permissions be for the actual binary registry files listed above?

    The registry is organised like a filesystem tree and permissions attributes may be set per leaf as with NTFS files (see regedt32.exe). These permissions control which users can access which entries.

    • NT4/SP3 prevents remote sharing of the registry to anonymous users (a good thing).
    • By default with SP3, only Administrators have remote access. The following entry can be used to add other users to the list allowed remote access: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg\Description (type REG_SZ).
      The AllowedPaths key in the same location can contain registry paths that are exempted.
    • NT4/SP3 also allows the user passwords stored in the registry (normally only in obfuscated form) to be encrypted. Refer to KB Q143475 and syskey.exe. This makes cracking the entries available in the registry much more difficult, but requires careful implementation. 
    • The resource kit provides scanreg which allows seaching of the registry for strings from the command line, and also includes a help file RegEntry.hlp describing many registry entries.

    Screen Access Control

Automatic screen locking with password protection should enabled after (say) 5 minutes (Control Panel --> Desktop). 

    Scheduler Access Control

    The job scheduler (at) runs in the security context of the system account (or whatever account is used to run the scheduler service), not the user which submits the job. By default only administrators can use at (see HKEY:LOCAL_MACHINE System\CurrentControlSet\Lsa\SubmitControl. If this value is 0x00000001, System Operators can also use at). There is no ACL for at.

    Other front ends to at are winat (GUI) and soon, both delivered with the resource kit. Soon executes commands "soon".

    => The at scheduler is far too primitive for administration of large important servers. It doesn't even approach the UNIX cron utility (which is not without fault either).

    Printer Access Control

    Printer ACLs are set in Printer Manager->Security->Permissions. The default are:

    Printer Operator, Server Operator, Administrator = Full Control
    Creator Owner = Manage Documents
    Everyone = Print

    • For confidential printers, the "Print" per mission can be selectively set.
    • By default, the print spool directory is root\system32\spool\printers. A frequently used printer server could possibly fill the root disk. To avoid this the default spool directory may be changed by adding DefaultSpoolDirectory in HKEY_LOCAL_MACHINE SYSTEM\CurrentControlSet\Control\Print\Printers to the full path of the spool directory.
    • Access to printers can be restricted like any other object. See printer manager -> permissions.
    • It is not possible to browse printers across domains without trust. 

    Clipbook Access Control

    The clipboard/clipbook application (clipbrd.exe) allows a user to share a page with other users. Access control lists are identical to NTFS ACLs (object permissions) and Lan Manager (share permissions). Access may be granted/revoked to users and user groups.

    Note: I don't really see what use this is, except that users can share information without sharing file systems. 

    Filesystem Access Control

    The access control on a file system level depends on the type of filesystem (FAT, HPFS, DOS) and whether it is shared (and with what share permissions).

    • Use NTFS where possible (avoid using FAT or HPFS).
    • Use NTFS for all filesystems.
    • NTFS files/directories can have the following permissions: No access (N), Read (R), Write (W), Execute (X), Delete (D), Change Permission (P), Take Ownership (O) and All.
      • Any number users or groups can be given a mixture of the individual permissions for a particular file/directory. These lists of users/groups + permissions are called ACLs (Access Control Lists). The command line utility cacls or the file manager can be used to view/change these permissions.
      • Files have the standard permissions N, RX (read), RWXD (change), All (full control).
      • Directories have the standard permissions of files as above, plus: RX (list), WX (add), RX (read and add).
      • Default permissions are inherited from parent directories. Note that copy and move commands are very different in their effect on permissions.
      • Recommendations: avoid giving Take Ownership permission to non administrators. Limit full access to creator-owner. Avoid using everyone to give access to files.
    • Alpha Hardware: The boot filesystem must be FAT for Alpha machines, since the boot firmware does not understand NTFS filesystems. To minimise the security risk, install a small FAT boot partition (1MB or larger) to hold HAL.DLL and OSLOADER.EXE. The rest of the disk can be partitioned as NTFS.
    • Consider allowing only administrator to use the floppy drive:
      instsrv FloppyLocker d:\reskit35\floplock.exe
      Then open the Control Panel -> Services -> FloppyLock -> Startup: select "System account",
      confirm, quit control panel, logoff and log on as a normal user.
    • The following is a complete list of files and directories that are writeable by Everybody on a newly installed NT 3.51 server:
    File Permission Comment
    C:\  RWXD Should be read only?
    c:\users\default\  RWX OK
    c:\WINNT35\repair\  All Bug?
    c:\WINNT35\system32\*.fts RWX Bug?
    c:\WINNT35\system32\PASSPORT.MID All Bug?
    c:\WINNT35\system32\config\default  All Bug?
    c:\WINNT35\system32\config\default.LOG  All Bug?
    c:\WINNT35\system32\config\SAM All Bug?
    c:\WINNT35\system32\config\SAM.LOG All Bug?
    c:\WINNT35\system32\config\SECURITY All Bug?
    c:\WINNT35\system32\config\SECURITY.LOG All Bug?
    c:\WINNT35\system32\config\software All Bug?
    c:\WINNT35\system32\config\software.LOG  All Bug?
    c:\WINNT35\system32\config\system All Bug?
    c:\WINNT35\system32\config\SYSTEM.ALT All Bug?
    c:\WINNT35\system32\config\system.LOG All Bug?
    c:\WINNT35\system32\os2\dll\netapi.dll  All Bug?
    c:\WINNT35\system32\ras\  RWXD Bug?
    c:\WINNT35\system32\spool\drivers\w32x86\1\ All Bug?
    c:\WINNT35\system32\wins\ All Bug?

      Everybody access is restrictive, but is it tight enough?. It needs be documented whether all the above are really necessary (Microsoft support in Zurich say they do not know!).
    TBD: Can the system32 entries be made read-only to Everybody? When replication is installed, the Import & Export directories are also RXWD for Everybody, read-only is sufficient.

    • Ensure correct privileges on user / data directories, especially ensure that only administrators can write to root, WINNT, REGEDT32.EXE and SYSTEM32.
    • Make sure that logon scripts can only be modified by administrator or the user concerned.
    • Guest should not have access to CONTROL.EXE.
    • Separate data and system disks. 
    • TBD: Fun for trojans? \winnt\notedpad.exe is writeable by everyone

    Secure system startup

    NT services tend to run under systems accounts instead of specific blocked user accounts (i.e. like UNIX) with minimum priorities. This could open future holes if bugs are found in the system services. 

    Object reuse

    N/A

    Secure data exchange / communications

    NT uses the following network interfaces/protocols:

    • Lan Manager 3.0 over TCP/IP & NetBEUI.
    • Novell IPX/SPX (not discussed here)
    • Apple talk (not discussed here)
    • TCP/IP is the only routable protocol and is therefore use by NT for all WAN links. In terms of speed, IPX is normally faster than NetBEUI, which is normally faster than TCP/IP.

    Specific TCP/IP applications (e.g. lpr, lpd, ftp, tftp, telnet, ftp, rcp, rsh, rexec, DNS and DHCP) and Netbios applications (most other networked apps.) are included in NT, but others (such as NFS, NIS) aren't.. 

    Network Peer entity authentication

    NT uses Lan Manager to authenticate peers. See also the user identification section. 

    Trusts (NT3.5, NT4)

    Lan Manager domains are not hierarchical and Microsoft recommends a maximum of 5'000 users per domain. Trust can be setup between domains to allow users from one domain to log on to another domain, effectively increasing domain size. Trust is non-transitive, so if A trusts B and B trusts C, it does not mean that A trusts C. Trust can be setup in one direction or in both. Each trust is protected by a password. Trusted domains accept users from trusted domains without requiring the user to authenticate himself again.

    Domains can be set up in several ways depending on the number of users, masters and independence required between domains. A detailed discussion is to be found in [nt4]. In general there are four models:

    1. Single domain
    2. Master domain: all (resource) domains trust one master domain. This is quite easy to manage.
    3. Multiple master domain: to increase the possible numbers of users, several "master" domains can be set up which "trust" each other completely (i.e. in both directions). The resource domains trust each of the masters (but not vice-versa)
    4. Complete trust: all domains trust each other. This is complex, error prone and difficult to manage.

    In general resource domains have one-way trusts to logon domains (logon domains do not need to trust resource domains).

    • The administrator on the trusted domain can see all user accounts and their details on the trusting domain but cannot change them. Seeing them alone is enough to perhaps find open of weakly configured accounts. TBD: check for NT4 & later.
    • Trust can be stopped by either domain, however the trust is not actually broken until the machine is rebooted. TBD: check on NT4 & later.
    • Domains should only trust each other if the corresponding administrators (people) trust each other!
    • For large organisations, use the (multiple) master domain concept as opposed to the complete trust model, since the number of two-way trusts is minimised and administration is simpler.
    • Use trusts rarely and never to less secure domains. 

    Network Data integrity

    Guaranteed by the network protocol used. 

    Network Data confidentiality

    Passwords are not sent in clear text during Lan Manager authentication with newer Microsoft clients (Win95/NT). Older LM implementations such as Windows3 and UNIX's samba prior to V2, send passwords in clear text (like ftp and Telnet).

    In NT4 a cryptographic API is provided (CryptoAPI) which allows application to encrypt or digitally sign data. See also www.microsoft.com/intdev/security/cryptapi.htm . The cryptographic functions are performed by modules known as CSPs (Cryptographic Service Providers). NT 4.0 has one CSP (Microsoft RSA Base Provider) bundled. This is a very interesting development, as it should allow plugging in of other cryptographic tools which conform to the API, however these CSPs have to be signed by Microsoft and will not be signed if they don't conform to the export restrictions.

    => In theory, this may allow Europeans to plug in strong cryptographic routines (such as those used in the international PGP version) without being hindered by the U.S. export policy on cryptographic products.
    => In practice, the CryptoAPI is restricted in Europe.

    Non repudiation of origin / receipt

    Not directly supported. 

    Network Access control

    RPC

    RPC has little in the way of access control or authentication, this must happen on the application layer. RPC is used extensively by NT system tools. In fact, when trying to harden NT for firewall usage, it's almost impossible to disable RPC.

    Remote configuration/ access

Several utilities allow remote configuration of a system: Registry editor, User manager, server manager, Event Viewer etc. There doesn't seem to be anyway to prevent remote access, except by removing the users access rights in the domain, or disable the "Access this computer from the network" right for all users.
If you don't trust your domain admins, then don't log into the doamin, just log on locally and authenticate for individual resources, otherwise the Domain Admins will be added to the Local Admin group and hence have full access. One reason to log onto the domain is to change passwords, this can now be done without logging onto the domain, thanks to a tool from Alexander Frink wwwthep.physik.uni-mainz.de/~frink/nt.html.

    NT File Sharing

    NTFS allows ACLs to be set for files & directories. These ACLs can contain users and groups. Lan Manager can then export these directories. In exporting, NT allows a further share ACL to be set, specifying which users/groups can mount the shared directory in what mode (no access, read, change, full access).

    Note: host names are not included in the share ACL i.e. it is not possible to share to specific hosts. The net use and net share commands are use to mount, respectively share directories. E.g. to share a directory: net share pubic=d:\ or to mount a directory: net use x: \\SERVER\MYDIR. The net file command can be used to monitor/close shared files on a server.

    • Only share NTFS filesystems (i.e. not FAT or HPFS). If a FAT system is exported, the entire directory tree is exported according to the share permissions, since FAT does not have any permissioning itself.
    • Do not share (the disk with) NT system files, only data disks.
    • Share restrictively: read only where possible, avoid giving Everybody read and especially (!) write permission.
    • Only a user should have write access to his home directory.
    • If a server is used to share the WfW 3.11 security file wfwsys.cfg, a null session share is needed. Set HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionShares and enter the WfW security files share name.
    • Shares can be hidden from curious browsers by adding a "$" to the end of the share name.
    • It is possible to hide a server from browser lists and to disconnect idle connections automatically:
      net config server /hidden:yes /autodisconnect:120 

    NFS

    NFS is not included with NT, but many 3rd party products exist. An NFS server (Diskshare) and client (PC-NFS for NT) from Intergraph were briefly tested (Oct `95). They seem stable and are well integrated into the NT GUI, although a little slow with large files (NFS is generally slower than SMB). Chameleon 5.0 was also briefly tested in March 1996, but it is not integrated into the standard NT GUI utilities.

If NFS is used, ensure that the pcnfsd has been securely installed on the server (UNIX) side. See the "Securing UNIX" chapter.  Don't rely on NFS for high security.

    RAS

    RAS is Microsoft's Dialup networking solution, with support for Netbios, NetBEUI, IPX, TCP/IP (PPP) and SNA. It may be used for creating WANs with gateway and routing functionality and for allowing "roaming employees" to access the corporate network. POTS Dial-in, ISDN and X.25 types are supported. RAS can be used to enable Internet access (!).

    RAS does have technical problems (especially with ISDN), so you may find that it's not suitable for a large user group.
    General:

    • Avoid using RAS (it can extend the corporate network with little control).
    • Do not use RAS.

    Identification/Authentication:

    • RAS passwords should be different from Lan Manager passwords.
    • NT4/SP3: consider enabling CHAP MD5 authentication support for small user groups handling sensitive data. In SP3, the keys have to manually added to the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\CHAP\MD5.
    • Consider using callback, a token identification mechanism (such as SecurID) or a challenge response system.

    Access Control:

    • Use a dedicated server for RAS. Don't allow users to login from the inside to the RAS server. Don't use or share resources from the RAS server.
    • Don't allow clients to request a specific host address (avoid IP spoofing).
    • Consider activating RAS only when needed. e.g. use the at scheduler and the net start remoteaccess command to start (and stop) RAS at particular times during the day.
    • Consider restricting access to the dial-in server only (not the whole network).
    • Configure "Preset to Call-back" for incoming calls and call back from a different telephone line. (Select Remote Access Admin -> Users menu -> Permissions -> select a user -> Preset To -> enter user's telephone nr). This increases security and decreases the caller's (often an employee at home) phone bill.
    • Enable automatic disconnection after 30 minutes idle time. Set HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AutoDisconnect to 30.

    Encryption:

    • Use CHAP to negotiate best type of encryption: RC4, DES (Microsoft clients), SPAP (for Shiva) or PAP (cleartext).
    • Avoid use of clear text login.
    • Consider the use of a third party system for either IP level or application level encryption.

    Accountability & Audit:

    • Don't hard-code passwords into Dialup scripts (on the client side).
    • Enable PPP logging to root\system32\ras\ppp.log, set HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\RasMan\PPP\Logging (last digit) to 1.
    • Enable RAS logging to root\system32\device.log, set HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\RasMan\Parameters\Logging to 1.
    • Monitor the RAS logs regularly. 

    SNMP

    An SNMP client is delivered as standard with NT (see Control Panel->Network->snmp). Unless you have a central management team monitoring the network via snmp, disable it. If you want to use snmp:

    • Define a standard for the use of snmp in your organisation and install all clients accordingly.
    • Consider allowing read-only access to clients. Configure to accept requests only from named computers/IP addresses.
    • Consider not configuring snmp traps or alerts.
    • Consider sending alerts if requests come from unknown computers.

    FTP server

    The ftp server is configured during NT installation or via:

    • The ftp server icon in the control panel.
    • The "ftp service" in the Network settings box.
    • The ftpconf.exe utility in the resource kit.
    • The registry \SYSTEM\CurrentControlSet\Services\ftpsvc\parametrs:
      Variable name Sample value for anonymous ftp
      AllowAnonymous 1
      AnonymousOnly 1
      AnonymousUsername Guest
      ExitMessage Report problems etc. to root@my.domain
      GreetingMessage Welcome to R&D's NT Server. For Administrator use only.
      HomeDirectory E:\ [anonymous disk]
      LogAnonymous 1
      LogNonAnonymous 0
      MaxClientsMessage Maximum number of users exceeded.
      MaxConnections 0xA [hex=10 decimal]
    • Disable the ftp server if not needed (Don't enable it during NT installation or disable the service in Control Panel->Services).
    • Use a machine as either an anonymous or normal ftp server, but not both (AnonymousOnly,AllowAnonymous).
    • Log normal usage to event log (LogNonAnonymous=1).
    • Avoid using ftp servers for "normal users", since passwords traverse the network in clear text form.
    • If using anonymous ftp, put the Home directory on a separate disk so it won't cause problems if it becomes full.
    • Log anonymous usage to event log (LogAnonymous=1).
    • No class  data should be available via anonymous ftp.
    • Ftp is not to be used for privileged accounts (e.g. Admin).
    • Consider running the ftp server under a special user (e.g. ftpuser), not Guest.
    • If it is necessary for an application to use ftp
      • log all actions (LogFileAccess=2) to root\WINNT35\SYSTEM32\FTyymmdd.LOG.
      • restrict file access severely (home directory).
      • restrict access mask severely (in control panel) 

    Routing

    On an enterprise network, only routers should route data, i.e., workstations should not route between subnets. On small company networks, the new dynamic multiprotocol routing (MPR) offered by NT3.51 Service Pack 2 or NT 4.0 may be an economic alternative to routers. However, allowing hosts to route data can degrade the network availability and allow accidental routing by hosts which (happen) to have two network interfaces.

    ==>It is recommended to configure static routing to a default router:
    Configure the "gateway" to be the IP address of the router in Control Panel-> Network -> TCP/IP.
    It is possible to define multiple default routers for each network interface. 

    Availability

    Backup and restore

    • Keep index of backups on paper or on an off site machine.
    • Account for all media.
    • Encrypt data backed up to tape.
    •   Backup media should be stored in locked safes or locked rooms.
    • Backups should only be transported by secure methods (like money transport).
    • A backup and restore policy must exist for each server. A primitive example would be to use ntbackup and the scheduler winat to:
      do a full backup each weekend:

    ntbackup backup c: d: e: f: /a /v /d "Server1 full" /b /hc:on /t normal /e /l e:\full_backup.log

    and an incremental backup each day:

    ntbackup backup c: d: e: f: /a /v /d " Server1 incremental" /b /hc:on /t Incremental /e /l e:\inc_backup.log

    If you have Exchange server installed, don't forget to stop the servive before backups (using net stop) otherwise the files will be skipped.

    Simple backups of directories can be made with xcopy (the /v option means verify, the /d option means copy files which have changed since the last backup).
       xcopy c:\mydata z:\backupdir /d /v
    An even more interesting alternatve is the robocopy utility in the resource kit, which only copies files that have changed, can even delete files for true replication and gives a summary at the end of the operation. I use this for syncing backup disks at night and remote syncing to laptops:
       c:\reskit40\robocopy f:\ v:\ *.* /E /R:2 /PURGE

    Registry Backups:
    The registry should be an integral part of tape backups.
    The registry should be backed up daily to another server :
    regback \\other_serv\backups\myserver_name.reg 

    Prevention of Resource Abuse

    A quota manager is not delivered with NT. Third party products exist, but I have not yet heard hearty recommendations for any of them. 

    Change/release management

    Server installation / reconfiguration

    • When reconfiguring the server, disable server services and logons:
      net pause server
      net pause "net logon"
      => To reenable the server:
      net continue server
      net continue "net logon" 
    • To examine an NT configuration:
      net config workstation
      net config server
    • NT can be installed /booted from CD-ROM without creating installation disks. Mount the CD and execute winnt32 /b . It is useful to have all methods of manually booting & repairing NT written down on a piece on paper beside servers!
    • To upgrade a DOS machine to NT over the network, try
      winnt /s:\\SERVER_NAME\MYPATH /t:c /I:\\SERVER_NAME\install\dosnet.inf /x/f/c.
    • NT workstations can be added to the domain via net computer \\COMPUTER_NAME /add and removed with the /delete switch. 

    Change log

    A (manual) log should be kept of all changes to the system. A record of who did what, to what files, on what machine, when, is necessary (particularly when more than one person administers a machine). 

    User notification

    • Administrative alerts can be controlled for a group of machines via the Server Manager.
    • Make sure the alerter service is started.
    • Alerting on-line users:
      Send a message to all users in a domain:
      net send /DOMAIN Warning: Server alpha1 will be down from 21:00-23:00.

      Send a message to all users attached to a working server:
      net send /USERS Warning: This server will be down from 21:00-23:00 tonight.

    • Email is still probably the best way of notifying users.

    Patches

    • Patch management is very weak on NT. As problems arise, Microsoft simply releases fixed binaries "hot fixes" (e.g. on the Technet CD), as opposed to installable packages. These hot fixes are rarely officially supported.
      The exceptions are the "service packs" which are normally a bundle of fixes and are published about once every 6 months. These updates cannot be backed out . Sometimes the service packs add new modules, not to mention bugs too. Be conservative, especially on SQL servers.
    • The Technet CD and Knowledgebase is the best source of bug descriptions / patches.
    • NT V3.5: use service Pack 2 have been tested and are recommended
    • NT V3.51: use service pack 5 (MPR, RAS fixes, Exchange, WINS fixes) or later.
    • NT V4.0: use service pack 3 or later (SP5 can affect Laptop power management tools, and mess up SQL server). 
    • To ensure a minimum of problems with hardare drivers (which are a classical cause on NT instability), consult the approved driver list at www.microsoft.com/hwtes before buying new hardware on installed new drivers aon high availability systems.

    SMS (Systems Management Server) 1.1

    SMS has the following functionality:
    1. Inventory management and collection of installation HW and SW information on a network of machines.
    2. Centralised distribution and installation of (SMS packaged) applications.
    3. Remote diagnostics and help desk functions.
    4. Network monitoring functions (basic, not a replacement for systems like IBM Netview or Sun NetManager).

    Modified logon scripts are used for 1. and 2. above.

    • An SMS server should be configured as level  security.
    • Configure the SQL database according to the chapter "Securing Databases".
    Access Control
    • The SMS administrator account should have no special privileges on the NT level.
    • A user must explicitly give control of his PC to a Helpdesk, before remote troubleshooting is possible.
    • Only authorised administrators should be able to use the Helpdesk function (configured in the database).
    • It is recommended that the network monitor (a network sniffer) be deleted, except where really necessary.
      If it is needed, the executable should only be accessible by persons, who's identity are known to Central Security and who have signed a document acknowledging responsibility for use of this tool.
    • Administrator levels for central, primary and secondary sites should be defined and the access rights for each SMS objects for each administrator type defined. All rights should not be attributed to all administrators.
    Integrity

    An SMS administrator could access the database directly, not just via SMSVIEW. This could lead to database corruption (since the SMS consistency checks are bypassed).

    • If any data access utilities other than SMSVIEW or .MIF files are used, they should be used only in conjunction with read-only accounts.
    • If possible standard .MIF files should be developed.
    Communications Security

    SMS servers communicate via Senders. A Sender is simply one of three methods of communication: SNA, RAS or LAN.

    => Avoid using the RAS sender.
    If the RAS (Remote Access Service) sender is used, RAS configuration should be specified, otherwise RAS should be disabled.

    Availability
    • No redundancy is built into the SMS architecture
    • Backup & restore policies should be written for SMS: both NT files and SQL database. 
    SMS Open Questions
    1. Is it possible that another PC could take control of a Helpdesk client during trouble shooting? (session hijacking)
    2. Is MS-SQL the only database usable with SMS?
    3. No troubleshooting for non windows clients (NT, Unix). 

    Remote Consoles

    NT servers can't be managed form the serial port (like some UNIX machines), however many commands can be executed on a remote machine (e.g. the User Manager can be used to manage the users on another machine, if the user is authorised. Other examples are the server/printer manager, event viewer. Some of these are available as WfW or Win95 clients).

    I Server trouble-shooting may be enhanced by sending debug messages to a terminal on a COM port. In boot.ini, the [operating systems] section, the switches /NODEBUG, /DEBUG and /DEBUGPORT=COMx, /BAUDRATE=xxxxx, /CRASHDEBUG, /SOS can be used. 

    Remote Installation (TBD)

    Redundancy

    NT directly supports RAID, Mirroring and Duplexing (separate disk controllers).

    • RAID 5 or Mirroring is recommended for file and printer servers.
    • It is recommended that hardware (i.e. not built-in) RAID 5 be used. If two disks in a RAID 5 set fail, the recovery time can be very long - so mirroring (or even better duplexing) is preferable.
    • Hot spares should be available if possible.
    • See [nt6] chapter 7 (page 155) for details on NT mirroring, duplexing, striping with parity (RAID 5) and UPS control. Recovery procedures are also described.

    NTFS allows expansion of volumes and volume set sizes, but not mirrored or stripe sets. If volumes are expanded, all users are logged off the system (but data is preserved). 

    File Replication

    Each NT server can have an import and (only one) export directory for receiving files replicated from another NT server or for replicating to other NT servers. NT workstations only receive replicated files.

    • Create a replicator account, assign a password and start the replicator service under this account name (control panel->services->directory replicator->startup).
    • Be very careful about which groups can write replicated directories (be VERY restrictive i.e. allow the replicator account read-only access to export and full control to import directories. Don't allow everyone full control).
    • Don't use replication as a backup mechanism for large data directories (such as user home directories), it may saturate the network. Use only for data that rarely changes.
    • Do not replicate sensitive data (lock data directories). 

    Disaster Recovery

    • Last known good configuration, a standard NT service, allows simple rollback of invalid registry configurations. [I've not found this to be of much use so far, though].
    • Keep your 3 NT boot/install diskettes handy, you'll need them to restore setting from the emergency repair diskettes. Emergency repair diskettes:
      1. keep in a locked, fireproof safe.
      2. To be useful they need regular updating (especially after creating/deleting user accounts). The rdisk.exe /s utility from the resource kit allows simple updating of this diskette. (don't forget the /s option).
      Even if you lose the emergency repair diskette, NT has a copy of important registry files in \winnt\repair, so try to restore particular registry branches from this directory if you have nothing else to fall back on.
    • Disks are cheap these days, it is recommended to used RAID or mirroring, or simply copy your boot disk regularly to an second disk and adjust boot.ini so you can boot from either. To copy the boot disk you'll need to use a tool such as Driveimage. Recommended.
    • The disk configuration should be backed up to a floppy disk each time the configuration is changed. (Choose: Disk Administrator -> Partitions -> Configuration -> Save). This floppy disk should be kept with the emergency repair diskettes.
    • Additional troubleshooting diskette: The emergency repair diskette will work for certain situations but not for others. It is also recommended to have a bootable diskette with registry backup/restore utilities and chkdsk. Format the diskette, how to make it bootable?? (no sys command) TBD: instructions (R276)
    • After a system crash, NT will behave according to the options set in "Control Panel->System-Recovery". These options allow: an automatic reboot, a dump of memory to disk before rebooting, writing an entry to the event log and sending an alert to the administrator. These options may also be set in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl.
    • The system diagnostics tool winmsd.exe can also be useful in trouble shooting. It provides information of hardware, drivers, interrupts, DMA, memory etc. A command line version winmsdp.exe is delivered with the resource kit.
    • Power failures: High availability systems need to be attached to a UPS or protected power source. NT can directly interface to a UPS and allow graceful shutdown in case of power loss. The UPS interface is configured in the "Control Panel->UPS".
    • The NTFS filesystem offers excellent recovery after sudden power loss of software crashes, since it uses journalling.
    • When NT software components produce an error message, an error number is also often included. The NT CD contains a tool which allows online viewing of the messages database (winntmsg). If this database is installed, the command net helpmsg MESSAGE_NUMBER can provide more detailed information on a particular error.
    • To search a disk for raw data try ntdt02.zip from ftp.winmag.com (not yet tested). 

    Footnotes:

    [1] See [nt1] page 80-81.
    [2] See [nt1] page 83.
    [3] NT resource kit.
    [4] See [nt2] Chap.3, customising setup.
    [5] The Everyone & Administrator groups have the right `Access from a Network'.
    [6] Account operators cannot modify accounts of Administrators, Domain Admins global group or the local groups: Administrators, Servers, Account Operators, Print Operators, Backup Operators.
    [7] Only if a user has the log on locally right, or access to the User Manager for Domains program.
    [8] See [nt6] page 87.
    10] See [nt1] page 110.

Share this article

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on WindowSecurity.com! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update.



Receive all the latest articles by email!

Receive Real-Time & Monthly WindowSecurity.com article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample

Become a WindowSecurity.com member!

Discuss your security issues with thousands of other network security experts. Click here to join!

Community Area

Log in | Register

Solution Center