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 jmhunt@mit.edu.
Thanks,
Jonathan Hunt
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.
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.
Intrusions come in several forms including privilege elevation and unauthorized access. The intrusions can result in something minor like web defacements (see attrition.org for the daily list of defaced web pages), or something more severe such as setting up a trojan or destroying important research data.
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.
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.
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.
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.
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.
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.
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.
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.
Steps in bold are recommended for MIT servers.
Steps in bold are recommended for MIT servers.
| 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 |
| Filename | Description |
| ntio.sys | DOS io.sys equivalent |
| ntdos.sys | DOS dos.sys equivalent |
| command.com | 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 |
| Filename | Description |
| debug.exe | MS-DOS debugger |
| edit.com | 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 |
| Policy Setting | Default Setting | Recommended Setting |
| Minimum password length | None | 14 or 7 characters |
| Password uniqueness | Do not keep a password history | Remember the last 3 passwords |
| Minimum password age | Allow changes immediately | Allow changes after 1 day |
| Maximum password age | Expire in 42 days | Expire in 84 days |
| User must log on in order to change password | No | Yes |
| Account Lockout | ||
| Lockout after number of bad attempts | no account lockout | 5 |
| Reset count after number of minutes | N/A | 15 minutes |
| Lockout duration | N/A | 15-30 minutes |
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.
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.
Be sure to use VNC only with LoopbackOnly enabled and piped over SSH.
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 jmhunt@mit.edu.
Apr 30 , 2001