Securing an NT Server at MIT (DRAFT)

This is the beginnings of a handbook of sorts for securing an NT Server for use at MIT. The eventual location for this work will be in the Network Security Team's site. The goal of this work is not to provide the end all manual that will gaurantee security for your system, but to provide a good beginning.

This work is still being compiled and I welcome comments, corrections and suggestions, just send me email at

Jonathan Hunt

Table of Contents

  1. Foreword
  2. Threats
    1. Intrusions
    2. Denial of Service
    3. Theft of Data
    4. Mis-Use of Resources
  3. Policies
    1. Access
    2. Operations
  4. Setting up the Server
    1. Installing NT
    2. Hardening the System
    3. Auditing
    4. Remote Administration
  5. Footnotes

1. Foreword

Most of the material contained in this page is based on the work of others. The main source is Stefan Norberg's book Securing Windows NT/2000 Servers for the Internet published by O'Reilly and Associates in January 2001. Another source that I used was Hacking Exposed by Stuart McClure, Joel Scambray and George Kurtz. A second edition has recently been published by Osborne Publishers. If you are serious about wanting to secure your system and understand what you are doing, I would encourage you to purchase Stefan Norberg's book. Another book that has been recommended to me, but I have not had a chance to read is Windows 2000 Security Handbook by Philip Cos and Tom Sheldon.

I have tailored the information from the books and from other sites which rely heavily on firewalls and perimeter security to more relevant to MIT or other academic sites at which firewalls are not an option.

2. Threats - TOC

Attacks do not always come from the outside. Actually, one of the most serious threats is from a disgruntled employee, because they have access and knowledge of your systems. It is very important to secure your server from local as well as outside attacks.

There are four main threats that you need to protect against: Intrusions, Denial of Service (DoS), Theft of Information and Mis-Use of Resources.

2.1 Intrusions

Intrusions come in several forms including privilege elevation and unauthorized access. The intrusions can result in something minor like web defacements (see for the daily list of defaced web pages), or something more severe such as setting up a trojan or destroying important research data.

2.2 Denial of Service

DoS is a brute force attack that maxes out some bottleneck on the system rendering the system useless. For example, a syn flood maxes out the number of open connections for a web server preventing any new connections and basically rendering the web site out of service. There is a subset of these attacks which can be particularly devastating called distributed denial of service (DDoS) in which the attacker uses a large number of hosts to target one machine. The machines participating in the DDoS usually are not aware they are attacking someone and are typically not compromised.

2.3 Theft of Data

Login/Password pairs and credit card numbers, are some of the more common things stolen. At MIT one of our big concerns is student data for which there are federal statutes pertaining to MIT keeping that data private.

Sniffing passwords is not just limited to clear text. There are programs out there, like L0phtCrack, that sniff for the NT Password Hashes and crack those.

Once the hackers have passwords, they will either trade these with other hackers or break into the system to use it for possibly an attack against another machine or to get more passwords.

2.4 Mis-Use of Resources

Most of the security attacks we have seen at MIT have been of this form. The hacker wants to use the machine at MIT as a tool to gather information, attack other sites or store files such as pirated software. This is a threat because when they use the machine they may choose to clear some of your data out of the way. We have seen a number of cases of a hacker breaking in to a machine and making it into a Warez server and in the process deleting the web site or that big database that was taking up valuable disk space that the hacker wants to use. Two other uses that hackers have for machines at MIT are to attack other sites and sniff passwords. The connection between MIT and the Internet is huge even when compared with most ISPs. If several machines at MIT started to flood a small ISP or company, it is very likely that the victim would be unable to do anything to stop the attack for some time.

Now that we know what the threats are, let's take a look at what you can do to protect against them.

3. Policies - TOC

The first thing to securing a system, or group of systems, is to develop a policy and have the policy approved by the necessary management folks so that it can be enforced. Without an approved policy, you will get a lot of push back from users who want easier access and more control. Even with an approved policy you will likely get push back, but now you will have the authority to enforce the changes you are going to make.

Your policy should address both access and operating procedures.

3.1 Access

Physical Access

You policy needs to address who has physical access to the machines. Anyone can download a disk image from the internet which boots linux and can change any password including the Administrator password on an NT 4.0 system that has not had the registry encrypted (more on that later). Physical access to a machine is basically game over for a hacker. They can steal the machine, take a hard drive, boot from a CD or floppy, etc. You want to keep physical access to a server limited to only those people who need to maintain the server on a regular basis.

Network Access

Specify who needs to have access and what type of access to information over the network. Is it appropriate for people to be working from home on machines that are not under your direct control, and therefore may be compromised? What level of access do people need to do there job? The rule of thumb is that people should have the minimum level of access needed to do their daily job, i.e., do NOT make everyone Administrators.

3.2 Operations

Another important part of your policy is the operations plan. How are things going to be done? The operations portion should be realistic and needs to be followed. You should specify what is being logged, when the logs are reviewed, how backups and restore are done, where you keep the logs (on the machine or a remote system (more on that later)), etc.

Once you have your policy and it has been approved, it is time to start securing your server. The best place to begin is with a clean installation. If you already have the server setup and running, there is a chance that your server has already been broken into. The biggest concern with previously functioning servers is trojanned binaries, back doors and mysterious user accounts. You can use checksums to check the binaries (it will take a while), NetShield should detect the common backdoors used today, such as Back Orifice 2000 and Sub Seven, and manual review of the existing accounts should be done regularly to purge old accounts. Now it is time to start the installation.

4. Setting up a Secure NT Server - TOC

Below are a list of various things that you should do to secure an NT server. Because servers differ in functionality and needs, some of the steps should not be applied to your particular server. I have marked in bold the steps that I think should be applied generally for servers at MIT. This does not guarantee that your machine will work as expected after you make the changes. Be sure to test each change before putting it into effect on a production server.

4.1 Installing NT

Steps in bold are recommended for MIT servers.

  1. Install a minimal installation of the US English version of NT Server on the machine while it is not connected to the network.
  2. Install the latest Service Pack (SP) and security patches
  3. Install Applications
  4. Install all Application patches (especially for IIS or Apache)
  5. Reinstall latest Service Pack and security patches

4.2 Hardening your Server - TOC

Steps in bold are recommended for MIT servers.

  1. (Advanced) Disable NetBIOS if you can.
  2. Rename the Administrator Account to something unique to your environment.
  3. Disable NULL Sessions Q143474.
  4. Disable Unneeded Services <more to come>.
  5. Disable Weak Authentication.
  6. (Advanced) Remove POSIX and OS/2 subystems and DOS/Win16 if feasible.
    1. Modify the Registry
      SubSystem Value Name Type Recommended Value
        HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Optional REG_BINARY 00 00
      OS/2 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Os2 REG_SZ Remove
      POSIX HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Posix REG_SZ Remove
      WIN16 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\WOW REG_SZ Remove
    2. Remove the following files
      Filename Description
      ntio.sys DOS io.sys equivalent
      ntdos.sys DOS dos.sys equivalent DOS command interpreter
      ntvdm.exe Win16 VDM subsystem
      krnl386.exe Win16 VDM component
      posix.exe POSIX subsystem
      psxdll.dll POSIX component
      psxss.exe POSIX component
      os2.exe OS/2 1.x subsystem
      os2ss.exe OS/2 1.x component
      os2srv.exe OS/2 1.x component
      os2 (directory) Other OS/2 files


  7. Remove the following unused tools so that hackers can't use them against you.
  8. Filename Description
    debug.exe MS-DOS debugger MS-DOS text editor
    edlin.exe Another MS-DOS text editor
    finger.exe Finger client
    ftp.exe FTP client
    nbtstat.exe Shows NetBT statistics
    qbasic.exe MS-DOS Quick Basic
    rcp.exe Remote Copy
    rexec.exe Remote Execute
    rsh.exe Remote Shell client
    telnet.exe Clear text Telnet client
    tftp.exe Trivial FTP client
  9. (Advanced) Turn off system debugging.
  10. (Advanced) Configure Dr Watson (drwtsn32.exe) to only append to the existing file.
  11. (Optional) Disable 8.3 naming.
  12. Require Strong Passwords
  13. (Advanced) Encrypt the SAM database
  14. Setup stronger Account Policies
  15. Do not display last username
  16. Display logon Message
  17. Disable Weak Authentication Q147706
  18. Synchronize time with NTP

Auditing - TOC

It is very important to monitor your servers so that you know if someone has been trying to breakin or has succeeded. NT provides in depth auditing capabilities that when supplemented with some additional tools make auditing less of a burden. If you are not going to review the logs on a regular basis then don't bother turning auditing on. I recommend reviewing logs on a weekly basis so the amount of data you have to look over doesn't take too long and you can respond quickly. Below are steps and settings for auditing.

Steps in bold are recommended for MIT servers.

  1. Increase the log sizes to at least 15MB.
  2. Set the logs to overwrite events older than 30 days.
  3. Turn auditing on.
  4. (Advanced) Set auditing on various critical files and registry keys such as:
  5. (Advanced/Discouraged) Set CrashOnAuditFail
  6. (Optional/Advanced) Change the location of the log files
  7. (Advanced) Use a syslog tool to store the logs on a remote system

Remote Administration - TOC

It can save a lot of time and make it more likely that the logs get reviewed regularly if you can remotely administer machines. Since many of the standard remote NT tools are now disabled by several of the things we did to secure the server, we need to find other ways to securely administer the servers since you don't want to have to go to the server to do things like add a user account or change a password. There are two similar solutions available. One is to go with an off the shelf commercial product such as pcAnywhere from Symantec. The other solution is to use open source software including SSH, TCP Wrappers, Cygwin and Virtual Network Computing (VNC). The open source solution is cooler and can be customized more, but the off the shelf solution should get you up and remotely administering the system securely without much effort.

If you go with the pcAnywhere solution, be sure to not use the defaults when you setting pcAnywhere up. You want to use the Symmetric Encryption and configure IP address restrictions. A much more in depth set of instructions is available in Securing Windows NT/2000 Servers on pages 102 to 110.

For the open source solution there is a very in depth set of instructions in Securing Windows NT/2000 Servers by Stefan Norberg. The various components are linked below.

  1. OpenSSH for WindowsNT
  2. Cygwin
  3. TCP Wrappers
  4. VNC

Be sure to use VNC only with LoopbackOnly enabled and piped over SSH.

Footnotes - TOC

1. The table is taken from an unlabled table on page 55 of Securing Windows NT/2000 Server by Stefan Norberg, published by O'Reilly & Associates January 2001. The labels of the SubSystems have been added.

2. The table is taken from Table 2-3 on page 55-56 of Securing Windows NT/2000 Server by Stefan Norberg, published by O'Reilly & Associates January 2001. The text has been modified slightly.

3.The table is taken from Table 2-5 on page 57of Securing Windows NT/2000 Server by Stefan Norberg, published by O'Reilly & Associates January 2001. The secfixup.exe line has been removed because I am unsure of what this file does.

4. The format of the table is taken from Table 2-6 on pages 58-59 of Securing Windows NT/2000 Server by Stefan Norberg, published by O'Reilly & Associates January 2001. The recommendations have been modified for use at MIT.

Please send comments, questions, suggestion, corrections to

Apr 30 , 2001