Buttoning Up Your System

Windows NT is known for its good security, and despite the odd fuss over holes discovered through some obscure access method or utility, on the whole Windows NT has an excellent security record. The problem with security is that it is only as good as the weakest link, which, unfortunately, are usually the users. Keeping tight tabs on administrative security issues is important, but encouraging your users to keep security in mind when they work and set permissions on their files is also vital.

There are several components to a good security installation. These include, in no particular order, the physical security of the system, software security, and user security. The physical security of the system is obvious: if you leave the machine in the open and readily accessible, it will probably be accessed. Locate your machine where it can’t be picked up and walked off with, especially the servers. These machines have not only your data but also all the network access information on them.

Software security covers issues such as viruses and Trojans, the most common of which these days are embedded in macros. Many NT applications like Word and Excel run macros which can call other files, such as .HLP and .DLLs, which can harbor viruses. Some virus checkers don’t examine these files, dealing only with the executables. When the help file is opened, it can call a DLL, and the virus is loose from either one of them. Some software packages have in-built security regimes, too, especially the more expensive toolsets for CAD, program development, and accounting. These should be used to augment the NT security system.

The most important level of security on an NT system is the user security, and that’s what we focus on in this article. User security applies not only to the user and group permissions, but also to all the peripherals and drives on your system.

C2 or not C2

Windows NT is touted as being C2 security complaint, which puts it in a high security classification. C2 systems, when properly implemented, impose restrictions on what you can do with the system and the user accounts that reside on them. Maintaining C2 security on a Windows NT workstation is pretty much impossible unless you keep the NT system off a network, and few NT servers can be C2 compliant at all. You can, however, keep the highest security possible on your system by making sure of a few simple steps.

First, remove any multiple boot potentials for the machine. If you have dual boot into DOS, Windows 95, or other operating system, your machine is vulnerable. The NT filesystem can be accessed from the other operating system with surprising ease, and that immediately violates C2 security (and lesser levels, too). Remove dual boot for all servers without a moment’s thought. Workstations may need to be dual boot, depending on the user’s requirements, but be careful of the potential for network access from a dual booted workstation.

Make sure all drives on NT systems use the NTFS filesystem. The FAT filesystem is wide open for intrusions. You do not need to keep FAT filesystems unless you have dual boot, and as just mentioned, that’s a really bad idea from a security point of view. You can convert existing FAT filesystems easily enough through the Properties window of the drive. (NTFS filesystems can be read from DOS and Linux, but it’s much harder than a FAT system.)

Security Rights and NT

Windows NT handles security with a simple yet powerful method. Every Windows component, from files to devices, is treated as an object by the system and has properties associated with it. Users, too, have properties associated with their logins. Windows NT’s security subsystem uses a set of descriptors for every object and user, one a security descriptor that contains a set of flags and access control lists (ACLs), and the other an access token which cover a user’s rights on the system.

The security descriptor for every object on the system is made up of a number of sections, the first of which is a set of flags for the revision number, format of the entries, and an access control list status. The next two fields hold a security identifier (SID) number for the owner or the owner’s group. The SID is used to identify the user or the group throughout the network. When the group SID is filled out, multiple people own the object. Following the two SIDs for owner and group are two Access Control Lists, one called the security access control list (SACL) and the other the discretionary access control list (DACL). The SACL is used by the auditing system, and when auditing is on, entries are recorded in the logs. The DACL explicitly defines who can use the object the security descriptor describes. The DACL is filled out when the administrator uses the User and Group permissions or the User Rights Policy, which are discussed in a moment.

The SACL and DACL are laid out in the same manner, starting with a header that lists the number of entries in the ACL, the size, and a set of flags. These entries are called access control entries or ACEs. Each ACE defines the object’s rights for either a user or a group by using three fields which differ in use depending on the type of permissions and the object the ACE applies to.

Windows NT is smart when it uses security descriptors for operations that may be canceled. If a group of objects have the same rights (such as when you are or copying files), only one full descriptor is used for one of the objects and the rest have temporary pointers to the full descriptor until the objects are saved, copied, or written to some device, in which case the full descriptors are written. This saves time and memory when NT is checking access rights.

A user’s access token has a bunch of fields associated with it including a security identifier (SID), all of the group SIDs that the user belongs to, and a set of privilege fields that show special rights. The first field of the privilege section is a count of the number of privileges, followed by two fields for each privilege. The privilege fields are a locally unique identifier or LUID which is a pointer to an object on the system, and the other field is a mask that sets the exact permissions. Every user on the system has an access token and they are shared across networks between clients and servers. The LUIDs may not apply on other machines, though.

Managing User Accounts

One of the biggest problems with NT security is wide-open user permissions. Some administrators assign each user with full permissions on the system, able to do anything and go anywhere. The logic for this type of arrangement is that it removes the need for the user to hassle the administrator for permissions every time they need access to protected areas of the system. While the short-term hassling by users may be solved, the potential for complete disaster is increased astronomically, really saving the administrator little in the end.

NT has a very simple-to-use user account management routine. It is far simpler to use than other operating systems like UNIX, for example, in that creating users, assigning them to groups, and changing their permissions in the future is really just a few mouse clicks away. This ease of use is often why administrators forget the basic principle of allowing users access only to what they need, and locking everything else up.

To manage user accounts you should be logged in as Administrator. Ideally, there should be only one login with the ability to manage user accounts, but many systems have several administrators assigned. The logic behind multiple access is sound: in case of one person not being available another can complete required tasks, and there is the remote chance of the person with the sole administrator’s account forgetting the password, leaving the company, or sustaining some injury. However, the spreading of administrator rights should be carefully restricted. On most systems, the recommended method is to have one person who is primary administrator, and a single backup person with access in case of problems. More than two people with wide-open access to the system starts to present more opportunities for mischief.

Managing users properly begins with setting up logical groups. Groups are a concept taken from UNIX, where multiple logins can share access permissions. NT is shipped with a number of default groups, which will suffice for many systems without modification. The key groups that have to be limited in the number of members are Administrators (which has no limits on access or actions) and Backup Operators (which has access to the backup and restore capabilities). The Power Users group can present a problem when in the hands of someone who wants to abuse their rights as they have the ability to perform functions such as remote shutdowns. The Power Users group should be given to people who are very trustworthy, and not just users who think they are heavy-duty system users.

Most users will fall into either the Users group (which can’t alter any system settings) or Guests (who can only log on and off). Creating other groups with special permissions is often necessary based on application access. For example, you may need to create an Accounting group with access to an accounting package and its files (which you want to keep everyone else away from). Similarly, if you have project development under way, you may want to create a group for that project’s members with access to tools and file systems that others can’t get to. Creating groups is simple, but take care to set the permissions carefully to ensure abuse is not possible.

All administrators and backup operators should have two accounts, one for the admin or backup login used only for system work, and another for their regular work. Use the admin and backup logins only when needed for system work. Otherwise, use a standard Users group login for day-to-day operations. Since the Administrator account is the one most often used for break-ins, make sure the password is very tight. An even better trick is to create another group which has all the administrator group’s permissions, then disable most of the permissions on the Administrator account and enable auditing. You’ll be able to see when someone tries to access your system with that login.

Adding users to an NT system is also simple and the most critical step is assigning a group for the new users. As mentioned above, make sure they get only the permissions that need and no more. Along with permissions, use the Policies system to set parameters like how often the user must change their passwords.

One of the keys to maintaining good group and user security is to clean up occasionally. When someone leaves the company, immediately remove or lock out their account. This removes any chance (however unlikely) of that person or someone else using their login remotely. Even if someone goes on vacation for a while (especially if they have special access rights), lock out their account for the duration of the absence. With NT, you can set the lockout to expire automatically, simplifying the whole procedure.

One of the most forgotten tools in the user security component of NT is the User Rights Policy dialog, which allows you to set different access rights for users and groups. This can be used when a particular user needs more access or permissions that the normal Users group allows. For small numbers of users, it is easier to modify their rights individually with the User Rights Policy than to set up a new group. These changes affect their SACL and DACL security descriptors.

Make sure the Guest account has a password, or even better remove the account entirely. By default, there isn’t a password on the Guest account and if your machine is attached to a network or the Internet, anyone can log in as Guest and have immediate access to any shared directories, files, or drives. Using the Guest account, a knowledgeable person can even access the Registry and trash your machine, all without special permissions. Either disable the Guest account, add a very tight password that is given out to only a few people on a short-term basis, or button up your sharing system completely. (If you think this is not a problem, a quick scan of the Internet will show several hundred different programs that allow someone to access your NT server with the Guest account and try logging in with password guesses thousands of times a day. Eventually the password has to break. Set a low number of failed login attempts for the Guest account which then disables logins for several minutes to help foil this type of attack.)

How should you best set up user passwords on your NT system? C2 security sets certain practices, but every system should impose passwords that are not simple to crack. Make sure the passwords expire after a certain amount of time. Three months is a good interval, frequent enough to foil those who snatch passwords and yet not too annoying for users. Set the password length to at least eight characters, but ten or more is better.

One of the most common tricks users use to get by remembering new passwords is to change the password then immediately change it back to the old password. NT gives you the ability to prevent this in two ways. You can set a minimum amount of time that the password must be in force (a week is usually sufficient) and you can set the number of passwords the system remembers and forbids reuse of them. By default, NT remembers five passwords, and that should be adequate for most systems.

While in the User Policy areas of the system, set the lockout after bad login attempts to three or four. If a user can’t type their login name and password properly after three times, they have a problem. To avoid too much hassle, set the reset count field to about 20 minutes to avoid perpetually-locked-out users.

Finally, one security aspect most administrators forget: set the system to log users off the server whenever logon hours expire. Since most intrusions over the Internet occur in the early morning hours, prevent logons between midnight and six AM, for example. Even the most dedicated worker at home should be finished by then, and few people need the system before six in a typical work environment. Of course, you will have to tailor these times to your workplace’s requirements.

Where the Potential Problems Lie

Windows NT is a complex operating system, and there are a number of issues that an administrator must bear in mind when buttoning up the system. The issues depend to a large extent on the connections the NT system has to the network and Internet, as well as the type of applications the NT system is running, but a few generalities can be pointed out as targets for you to consider.

The biggest security hole in most NT systems that are on a network are the TCP/IP services such as FTP, Telnet, SMTP, and HTTP. Buttoning up your system for standard services like FTP and Telnet is simple (not allowing anonymous FTP logins is probably the simplest step you can take) and there are dozens of books that cover the security aspects of these services. If you don’t need a service such as FTP or TFTP, disable it. It does no good running if you don’t need it, and a wise intruder can exploit the service’s holes.

If you do allow FTP and Telnet on your system, remember that the passwords associated with logins to these services are transmitted with no encryption whatsoever. Anyone can read the packets and pick up the username and password. It is good practice to set up specific FTP or Telnet accounts that have restricted access. Don’t encourage users (especially those with high permissions) to log in over the Internet with their normal account logins.

The biggest problems to most systems are SMTP (Simple Mail Transfer Protocol, the protocol used to transfer mail messages around a network) and HTTP (Hyper Text Transfer Protocol, the protocol used by the World Wide Web). HTTP is the biggest problem of all, and few administrators realize the problems HTTP poses. For a number of years, the subset of HTTP that was used by Microsoft in their Web server products before NT 4 provided basic security, but that was all. Any knowledgeable person could break the system. With NT 4 and the latest versions of IIS, these problems have disappeared, but you should make sure the Web server software you are running is secure.

The biggest problem with most modern Web servers is not the HTTP server software itself by the CGI scripts written by the users of the system to enhance the Web pages. CGI has the potential to be exploited with catastrophic effects, with full access to the network possible if the CGI script is not written properly. Knowing how to write a good CGI script is vitally important if you use them on your NT system, and since CGI scripts are portable you should consider reading any good book on CGI scripts (most are for UNIX but apply fully for NT) to find out what not to do. Avoid letting users load their own CGI scripts to your server until you have checked them out thoroughly, or find someone who knows what to look for before opening up your system.

While on the subject of TCP/IP and the Internet, watch out for Server Message Block (SMB) services. These are usually enabled by default on all servers and can be easily exploited. SMB is used for NT (and other Windows operating systems) file and print sharing systems, names pipes, and RPC (Remote Procedure Call). There is not a lot of information about SMB available as few people seem to understand it properly, but a few books do cover it. To prevent problems with SMB access, don’t put a server with file and print sharing active as the gateway to the Internet.

Summary

There’s a lot to consider when it comes to security, and we can only scratch the surface in this article. For information on filesystems and user security, consult any good security book. The principles apply even if the examples are for another operating system. Above all, take care when setting up your system to ensure the users and groups are properly set, and sharing is only as necessary. Set all permissions on an absolute need-to-have basis and not on a wide-open policy.

By far the biggest problems with security for NT systems are networks and the Internet. Although most servers for NT are secure, there are many that have problems. A search of the Web for information about a particular product will often find warnings from users, as will the Usenet newsgroups. The Web is especially problematic as it is difficult to button up an NT system. A little patience, research, and frequent checks of the system should help solve the majority of the problems.