John Kozubik - john_kozubik@hotmail.com

(permission is granted to circulate this document freely as long as no changes are made)

Preface

The critical mass that Windows NT has achieved in the consumer and commercial markets all but guarantees that a modern Systems Administrator (SA) will, at some point, be faced with configuring and securing Windows NT servers and networks. The current race to expose security holes and design flaws in this Network Operating System (NOS) has achieved great success - and has even tarnished the faith that many users and professionals alike have in NT. At the same time, it has made it dificult for the many charged with implementing and securing NT. As stated above, as a network professional, it is likely only a matter of time before being faced with this challenge.

This article contains the basic ingredients for securing Windows NT. For beginning users with little or no experience with networks and NOS's, this article contains step- by-step instructions for completing every objective. For network professionals who may not have a complete mastery of Windows NT, more complex explanations and rationale are given. Finally, for those professionals whose mastery of Windows NT equals or exceeds the information provided here, further comparisons and contrasts will be put forth spanning multiple versions of the NOS and references will be provided for further study.

Introduction

Windows NT is not secure after the initial, default installation. This document will examine the following four areas of concern: security in terms of system architecture, security in terms of permissions and rights, and security in terms of actual people (users).

Security in Terms of System Architecture

Step 1: Do not use trust relationships between Windows NT domains

GartnetGroup, in the first part of 1998, concluded in a conference titled "Windows NT: Strategies for Success" that the complex and confusing nature of Windows NT domains makes it undesirable to use the domain structure at all. This is one way to avoid the security pitfalls of domains, but I disagree that they should be dismissed altogether. I would lessen the severity of the GartnerGroup solution by simply not using multiple domains, or not creating trust relationships between them when they are necessary.

Establishing multiple domains is almost impossible without receiving user requests for information or resources on other domains. These requests are inevitably fulfilled by establishing trust relationships between separate domains. In addition, simply administering the multiple domains is made much simpler by creating trust relationships (replicating logon scripts, files, and directories). The problem with maintaining disparate domains is that the act of creating trust relationships is not intuitive, and the act of maintaining the rapidly increasing permissions and trusts between them becomes confusing (and an annoying chore). Therefore, it is not the simple presence of multiple domains and trust relationships that creates a security problem, it is their use in practice and the dificulty of keeping track of all the information necessary to keep things secure. Don't use them.

Some NT professionals in the audience may be scoffing at such a recommendation, but I would ask that they consider that a full understanding of local and global user groups, file and resource permissions, and a simple, complete foundation of organization makes multiple domains, their different configurations, and their difficulty in securing and administering unnecessary. I will certainly admit that very large organizations, especially those involved in providing third party system administration to other client firms - like Digital, Unisys, IBM, etc. will most likely not function efficiently without multiple domains. Most of us, however, are involved in securing networks with less than 1000 seats, and therefore can get by without multiple domains. In my opinion, the GartnerGroup, in recommending the dismissal of domains in general, overestimates their complexity - I am a firm proponent of the domain model, and use it in almost all situations.

GartnerGroup can be found at http://www.gartner.com.

Step 2: Install the Service Packs and Hot Fixes

Although all installations of a NOS are vulnerable to persistant attackers bent on compromising system integrity, the security of the Windows NT NOS is significantly improved by installing the free service packs provided by Microsoft. Many of the more gaping holes found in Windows NT were fixed with the release of Service Pack 3. In addition, by keeping up to date on the service pack hotfixes, one can fix problems that arise between service packs. As of this writing, Service Pack 4 is available. I would recommend installing Service Pack 4, unless you are running the Windows NT Option Pack, or other complex arrangements of Transaction Server, IIS4, etc. There have been reports of nasty non-cooperation in those instances. Service Pack 3, at least, is highly recommended.

Service Pack 4 can be found at:

http://www.microsoft.com/windows/downloads/contents/Updates/NT4SvcPk4/default.asp

Service Pack 3 can be found at:

http://www.microsoft.com/windows/downloads/contents/Updates/NT4SvcPk3/default.asp

Post Service Pack 3 Hot Fixes can be found here:

ftp.microsoft.com in /bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3

Finally, for a list of security flaws fixed by Service Pack 3:

http://www.winntmag.com/Magazine/Article.cfm?IssueID=23&ArticleID=477

Step 3: Remove All Other Operating Systems and Mount Only NTFS Partitions

Windows NT systems which have more than one Operating System installed (such as a machine that dual-boots to Windows 95 and Windows NT) are not secure. It is not recommended that any other operating systems be installed, and only one instance of Windows NT be installed.

Security breaches could occur in this configuration because when the other operating system is booted and run, the Windows NT executive, and its complementary services and policies cannot prevent this other OS from reading/writing/deleting and otherwise tampering with the file system.

Windows NT allows the creation and use of NTFS (New Technology File System) and FAT (File Allocation Table) partitions on which to store data. NTFS partitions are able to use and store security information that prevents and allows access depending on permissions set by the system and SA (usually in Windows Explorer). All of this functionality is lost when using a FAT partition. Therefore, all data that requires access control should reside on an NTFS partition.

The HPFS method of formatting should also be avoided.

Step 4: Do Not Install the OS/2 or POSIX subsystems

I will concede that it is possible to run a secure Windows NT installation with one or both of these components. However, these components add a great deal of additional complexity to any installation, and because of the lack of attention paid to these features, there may be many security holes waiting to be discovered.

Networks that require these packages are few and far between. If you have no intention of ever using these, do not install them for any reason.

Step 5: Disable Simple TCP/IP Services

Simple TCP/IP Services is a network service that enables such tools as Quote of the Day, daytime, echo, etc. These services are not generally needed, and by having them running, a SA makes himself vulnerable to Denial of Service (DOS) attacks that may target these resources.

Disable this by going to the control panel and starting the network applet, choose the services tab, highlight 'Simple TCP/IP Services' and click the 'Remove' button. It is recommended that the SA restart the system after performing this change.

Step 6: Remove FPNWCLNT from the Registry

The FPWNCLNT registry key resides in:

\\heky_local_machine\system\currentcontrolset\control\LSA\notification packages

Just delete 'FPNWCLNT'. This is a notification package that is used strictly for integrating with Novell NetWare. It is not needed, and further, could undermine the cooperation of other notification packages as well as interfere with whatever security plan you are implementing.

Do not remove this notification package if you are, or plan to integrate with NetWare in any way.

Step 7: Protect Your Passwords

The user password is the cornerstone to day to day security on a NOS. Windows NT, in its default configuration, presents a number of challenges to SA's. The following steps should be taken to ensure proper password selection and security.

A. In User Manager, under the 'policies' menu, select the 'account' option. Set password expiration to 30 days, set password length to at least 14 characters, remember 3 passwords set account lockout after 3 bad attempts. reset count after 30 minutes, lockout duration is 30 minutes. and forcibly log off anyone not in the hours of usage.

Although many people will complain about using 14 character passwords, there is a reason for doing so. Due to a peculiar nature of the hashing mechanism for Lan Manager passwords (which is beyind the scope of this document), 7 and 14 character password hashes are actually more difficult to break than passwords of character lengths 8-13. Because a seven character password is inadequate, 14 is the only number left to choose from.

B. Install passfilt.dll. Passfilt.dll was included with Service Pack 2 and 3, and is designed to check the quality of passwords. In fact, it is possible to build your own password filtering DLL. These password filtering DLL's check new passwords being entered into the system, and if they do not meet the requirements set forth in the DLL, they will be rejected. passfilt.dll is certainly not a cure-all, but it disallows some weak passwords that Windows NT would otherwise allow.

passfilt.dll can be installed by following these instructions:

Start the registry editor (regedt32.exe) and move to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Double click on "Notification Packages", and add PASSFILT on a new line. Close the registry editor and reboot the machine.

After installing passfilt.dll, you will still be able to set passwords that do not meet its requirements in User Manager. In all other areas, however, its rules will be enforced.

Please see the Microsoft Knowledge Base for information on creating your own password filtering DLLs to be used in this manner. These dll's can be used simultaneously. Also, make sure you add any such DLL's to your backup domain controllers.

C. Try to use extended characters in your passwords. Extended characters are produced by holding down the (alt) key and typing a three digit number between 000 and 255. The nature of the most mature Windows NT password cracking program (L0phtCrack) is to attempt to decrypt passwords with only alphanumeric characters, then with alphanumeric characters and punctuation characters, and finally with those two and extended characters. When a user runs L0phtCrack, an estimation of the time needed to crack the passwords is given - by changing from simply alphanumeric to all three, the time will be multiplied by many orders of magnitude. This causes most users to run L0phtCrack with only alphanumeric characters. In the future, the strength of 14-character alphanumeric, punctuation, and extended character passwords will continue to thwart any further developments in the brute force password cracking world.

Step 8: Don't Display the Last Username to Log On

As all users of Windows NT know, the default behavior when you press 'Control- Alt-Delete' to log on is to display a logon box with the name of the last username showing. This way the user need only input their password to log on. This is convenient, but is a security hazard, as this is 50% of the knowledge necessary to guess a logon/password combination. Therefore, it is advisable to not show the last successful logon at the logon screen.

This is done by changing a binary value in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DontDisplayLastUserName

Change the value from '0' to '1'.

Step 9: Avoid Running Services in the Context of a User

When a Windows NT Service is run, it is either run in the context of the system, or in the context of a particular user. Most services running on a default installaton of NT should be running in the context of the system. However, many third-party software packages, etc., require new services to be added, and new users to be created under the context of which the service will be run.

Sometimes this is unavoidable, but it is recommended that a SA do his best to avoid this. Have services run under the context of the system whenever possible.

The reason for this is that when a regular user is used for the context of a service, the password information for this user is stored in plaintext in the LSA. Because we want to avoid storing or transmitting plaintext passwords as much as possible, this is undesirable.

Step 10: Services for Apple Macintosh

Allowing clients with Apple Macintosh computers access to shares on the Windows NT domain is fairly easy to do - the problem is that the recommended method involves having the Macintosh log on as guest to access the shared resource. This is not desirable because in a secure Windows NT environment, there is no 'guest' account, or it is permanently disabled. Another big problem is that, even if the Macintosh user does log on as a normal user, the Macintosh, by default, only allows an 8 character password to access the shared resource it is trying to connect to. Because we want to use 14 character passwords (and use Windows NT authentication) this is undesirable.

Here are the steps that should be taken on the Macintosh to make sure that it is using Windows NT authentication and not something else:

First, connect to the microsoft UAM volume that has already been shared on the server (consult your Windows NT documentation, as 'File Manager' is required to share this UAM volume, in addition, services for Apple Macintosh will need to be installed in the network applet of the control panel). You will most likely be connecting as a guest. In the UAM volume, find a folder called 'appleshare' and drag a copy into your system folder. Now when you try to log in you have a choice of whether to use Microsoft Login Style or Macintosh Login Style. Choose Microsoft style. Now you will be able to type in a 14 character password and log into the resource just like anyone else accessing a shared NT resource. At this time, you can go back to the server and restrict access to the UAM volume to a specific set of NT users and groups (and not the guest account).

Step 11: Miscellaneous

A. Do not leave backup media or Emergency Repair Disks (ERDs) unprotected. In my opinion, backup media should be stored in a fire-proof safe, and older copies should be stored off-site (at a safe-deposit box, for instance). Backups and ERDs contain sensitive security information that is normally protected in the registry. Any intruder that has access to backups or ERDs has the ability to mine them for logon credentials.

B. Do not allow users to run machines without setting password protected screen savers. This can be accomplished on Windows NT clients by running a certain registry key addition during the login script with the follwing command:

regedit /s \\MY_PDC\netlogon\scrn.reg

The 'scrn.reg' file should look like this:

[HKEY_CURRENT_USER\Control Panel\Desktop]
"ScreenSaveTimeOut"="1800"
"ScreenSaveActive"="1"
"SCRNSAVE.EXE"="c:\winnt\system32\logon.scr"
"ScreenSaverIsSecure"="1"

By adding the above command line to your Windows NT login scripts, and by making the above scrn.reg file available to users logging in, you will be setting a password protected screen saver that starts after 30 minutes of inactivity. This way, users can get up and leave their desktops without logging off, and security will not be compromised.

Doing this in Windows 95 is trickier, as it requires the login script to examine win.ini and make changes there - it is possible, however.

For more information on Windows NT login scripts, consult:

http://www.networkcommand.com/NTSEC/scripts.html

C. Obscure potentially harmful utilities

At any time a new bug or glitch could make it possible for users to remotely run commands on your Windows NT system. It is impossible for a SA to know at all times what combinations of Transaction Servers, Web Servers, etc. could possibly open a hole that would allow the running of remote commands.

If such a bug is discovered and distributed throughout the internet, it is possible that the machines the SA is responsible for could be exploited before the SA has a chance to patch them.

To minimize the extent of this damage, set aside any dangerous command line utilities and rename them so as to obscure their existence on the server. For instance, rename 'format.com' to something like 'a97rq5.com'. The 'AT' command, 'instsrv', etc. are all examples of commands that could be used maliciously. By slowing down potential attackers, you increase the odds that the attacker will consider other easier targets.

In addition, after renaming the potentially harmful utilities (such as format.com) create new utilities with the old names that run notification scripts. For instance, if you rename format.com to xgft35.com, then compile a new program or batch file that sends off an email to a sysadmin pager and logs an event to the log.

D. Turn Off the Automatic Sharing of Logical Drives

By default, Windows NT will share the root of any logical drives on the system as X$, where X is the drive letter. If you manually unshare these drives in explorer, they will only be shared again when you reboot the machine. Because it is well known that all Windows NT machines do this, and because these shares can be remotely mounted by a user who knows an administrative username and password, it is unwise to continue sharing these resources.

To disable this sharing permanently, use REGEDT32 and look under "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters" for a DWORD named "AutoShareServer" or "AutoShareWks" and change the value from '1' to '0'. If the value does not already exist, you will need to add it for yourself.

What Not To Do

I have seen several Windows security papers put forth the idea that installing in a directory other than c:\winnt will obscure your system and slow down attackers. Further, a new c:\winnt directory (a dummy) can then be created and audited - if anyone ever tries to use it, you are then alerted. This is a good idea in theory, but a bad one in practice. The reason is that Windows programmers are lazy. If you _only_ run Windows NT on your system, then this _might_ work for you. If you plan on installing any third party packages, and even a lot of Microsoft packages, you will cause a lot of confusion by having a non-standard installation directory. You are opening yourself up to a lot of headaches and strange system behavior by doing this.

Security In Terms of Permissions and Rights

Step 1: Do not let anyone log on to the local console

In a secure Windows networking environment, users should perform their tasks on their local machines. It is irresponsible to allow anyone except for the SA to log on to the server locally (that is, sit down at the actual server and log on). Remember that infiltrators will view the server as a target, and the more opportunities they have to either use the target directly, or witness others using the target directly (i.e. watch a user using the server) the more opportunities they will have to uncover a weakness.

In fact, I would go even further and suggest that although the SA should always have the ability to log on locally, the SA should try to avoid doing this whenever possible.

The 'User Rights' option in the 'policies' menu in the 'User Manager' utility will allow you to change who can and cannot log on locally.

Step 2: Do not let Administrators log on over the network

Most intrusions will occur over the network - especially if the servers are physically secured. Therefore, by disallowing the administrator account the ability to log on over the network, the potential damage of such an intrusion can be minimized.

Step 3: Other Rights and Permissions for Users

Carefully examine the 'User Rights' option in the 'policies' menu in the 'User Manager' utility. This will show you what righs each group of users have. Make sure that only the minimum amount of rights necessary to complete thier assigned tasks is given to each group.

Step 4: Miscellaneous

Remove unnecessary user groups. As you examine the user rights under the 'policies' menu, you will note that many advanced rights are given to groups such as 'power users' and 'account operators'. In a small or medium Windows NT network, it is doubtful that all of these groups are needed. To avoid possible confusion and accidental granting of rights to incorrect groups, get rid of any unneeded user groups.

Security In Terms of Users (actual human beings)

Step 1: Organize their passwords well

Users will get lazy if they have 18 different 14 character passwords - help yourself out by helping them out and make sure they treat their passwords with care.

Step 2: Add a Legal Notice to your Server

Add the following line to your login scripts:

regedit /s \\MY_PDC\netlogon\legal.reg

where legal.reg should look like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon]
"DontDisplayLastUserName"="1"
"LegalNoticeCaption"="Important Notice!"
"LegalNoticeText"="This is a private computer system"

After this is implemented, users logging in will be confronted with your 'LegalNoticeText' and will need to press 'ok' to continue logging in.

A good example of what your LegalNoticeText should be is:

This is a private computer system on a private computer network. access is logged and monitored - you should not log on if you object to this policy. Unauthorized users are not allowed, and any attempt to enter the network or this system without permission will result in civil and criminal liabilities.

Summary

By implementing the above procedures and fixes, a Windows NT network can be made much more secure than it is in it's 'out of the box' state. Certainly none (or all) of the above fixes represents a panacea that will except the SA from doing further work to keep their systems secure, but by studying what is presented here and the methodology that it presents, one can transcend the actual step by step procedures and develop a philosophy of network security that will allow for continuing security.

References

The following references should be checked regularly, as they contain up to date Windows NT security and risk information:

http://www.networkcommand.com - the location of my regular NT security column

http://www.antionline.com - a collection of current news and security holes for NOS's

http://www.ntfaq.com - The NT faq - all Nt administrators should read this entire web site

http://www.infowar.com - The Bible for workers in the InfoSec field

http://www.l0pht.com - The source for many of the NT security flaws that are published