|
25Advanced Security GuidelinesThis chapter is not for the faint of heart. However, if you use Windows NT Server for anything more than tinkering, I strongly encourage you to look through this chapter so that you begin to understand how some of the changes you make (or don't make) can have a dramatic effect on the overall security of your system. If you are an advanced administrator, this chapter will definitely interest you. This chapter introduces some of the basic concepts behind computer security, including what it is and why it's important to you. It continues with an explanation of the U.S. government's computer security evaluation criteria, and how Windows NT evaluates against it. In particular, it focuses on what C2-level security is, and how Windows NT complies with the guidelines required for this rating. The chapter then continues by going through all of the major components of Windows NT that impact the security of the system, including what you should do to increase the level of security, as well as the disadvantages of taking these actions. Remember, increased security often comes at a price, either in convenience or performance. Some of the changes described in this chapter are not applicable to every environment. However, if you take the time to understand the implications and logic behind each section, you will end up with a much better understanding of how Windows NT works, as well as an increased ability to secure Windows NT in your particular network. Therefore, let's start at the beginning. Before a practical security policy can be developed, you need to address some important questions. What is Computer Security?Broadly defined, computer security involves the prevention of undesired or unintentional access to any part of a computer system. In an inclusive sense, this would include all aspects of hardware and software, servers, workstations, LAN devices and cabling, as well as computer operating systems, network operating systems, user programs, and the most important element—user data. Of course, this definition is far too expansive a subject to be addressed in a single chapter, so we focus on ways to use Windows NT to its fullest capability and how to lock down the operating system to prevent tampering. What Are We Trying To Protect?If we look back many years into the annals of computer lore, we learn that computer security originally focused on protecting the single most precious resource—the compute cycle. When people communicated with a central, massive computer through punch cards and dumb terminals, the compute cycle—the atomic unit of computing power—was in great demand. This valuable commodity was often the main objective of wayward hackers, who would attempt to find ways to divert a system's compute cycles for their own use. It became part of the job for a computer operator to protect his or her system from being compromised, so that each compute cycle could be accounted for and billed to the appropriate party. Although stealing compute cycles is still a concern for some people today, I would venture to say that the majority of us have other issues that we place higher on our list of worries. Because many people have computers on their desk that can run rings around the mainframes of yesterday, stealing compute cycles is just not something most people worry about.
When computer networks began to emerge—mostly to link universities, research agencies, and the military—the target of computer hackers began to change. These networks presented a new and potentially more interesting subject for their attacks. Because it was widespread in large computing environments to establish inter-system trust relationships (such as rhosts files in the UNIX environment), hackers would try to break into a system, not for the data that was contained on that particular system, but rather to gain access to computers that trusted it. In another words, hackers began to try to steal the identity of a computer. They would ride this spider-web-like trust relationship from computer to computer and sometimes it could lead them around the world. Some hackers would do this just for fun—to see where they could get. Others, however, had intentions other than joy riding. Computer networks opened a new can of worms that was hard for many people to understand. People tend to discount the security-related consequences of computer networks because they represent such an intangible concept. While we've grown used to our electronic toys, such as televisions and radios that communicate in a single direction, we have not quite gotten used to people being able to connect to our computers from across the world and access our files. Up until the proliferation of personal computers, our telephones have been our only two-way communications devices. They were easy to deal with because we had to worry about one person at a time. It was impossible for someone to simply call our homes or offices and eavesdrop on us. With computer networks, this has all changed. The scary part is not that someone can access our computers from across the world, but rather that it happens all the time! Additionally, whatever the chances are that someone is going to worm into your computer system from the other side of the world, the chances are even greater that you'll be attacked by a set of prying eyes from right down the hall. I've heard many people who are connected to the Internet explain with perfect logic that with the countless number of systems connected to the Internet, the chances of someone attacking their system is statistically nonexistent. Unfortunately, these kinds of people are often proved to be flat-out wrong. Security-in-numbers may be a nice concept, but it's not reliable. Who Are the Bad Guys?Often the concept of security begins with "us" against "them." This is definitely a good place to begin. However, as is often the case, the "us" and the "them" are not so easily defined. When developing a security policy, you should consider all possible players in the security arena. You need to ensure that your security policies include considerations for protecting your system from not only the outside intruders, but also from accidental mistakes on the part of the local users and administrators. Additionally, you should consider intentional mischief from within your organization and from the most powerful adversary, a renegade administrator. Although you might not need to or even be able to fully protect your system from all of these, you need to consider that each is possible and evaluate how these kinds of attacks would affect your system. Security and Windows NTIt's hard to have a coffee-table conversation about Windows NT without at least broaching the subject of security. Security is built into the core of Windows NT and represents an integral part of Microsoft's marketing strategy for their NT product line. UNIX has been around for over two decades, and the number of guides written about security from a UNIX point of view is overwhelming. Windows NT, on the other hand, has only been around a few years and there is still little extensive information published that focuses directly on Windows NT-specific security issues, such as the way that NT handles its user security database and network authentication. Reading a generalized treatise on computer and network security is useful for developing ideas that can be extended to the NT environment, but there are critical NT-specific issues that need to be addressed directly. Although there are architectural similarities between Windows NT and various flavors of UNIX, the complexities of computer security are directly linked with the intricacies of the operating system, such as how users are created, where and how the user database is stored, how you access files, and what privileges different processes have. With more than two million copies of Windows NT on the market, coupled with an ever growing migration toward global connectivity through the Internet and other means, accurate information about building and maintaining a secure NT server is imperative. These are the details that are dealt with in this chapter. This chapter is not intended to be an in-depth discussion of the development of security policies or the end-all and be-all of risk analysis. There are numerous excellent guides published on these subjects and they should be consulted for a more detailed and rigorous investigation of the subject. Additionally, if you are concerned about the security of your Windows NT system, you might want to consider getting help from a professional computer security specialist.
I have tried to make this chapter as useful to as many people as possible. I have included basic concepts of security policy for people without a background in computer security. This is followed by a discussion of C2 security evaluation and concludes with a review of areas that system administrators should address to help make their the systems as secure as possible. I have compiled a list of all the security-related problems and warnings that I've encountered while working with Windows NT systems. Windows NT has some wonderfully robust features that allow for very secure installations; however, like any complex system, there are many things that can go wrong. If I can communicate one thing in this chapter, it is that the most secure facility in the world can be compromised if the front doors are left open. Likewise, your NT system can be compromised if you don't fully understand the security implications of your actions, or even in some cases, your lack of actions. Although many users still consider computer security to be something that they don't need to be concerned with, they couldn't be farther from the truth. The increasing appearance of computer networks in today's corporate environment requires that users begin to get more involved with this issue. With a standalone computer it is relatively easy to identify your potential attackers and develop means to protect yourself. However, as soon as you attach that computer to a network, you've just changed the nature of the game. Security Through ObscuritySecurity through obscurity is an important enough topic that I thought it deserved its own section. It's a simple concept that has tremendous significance on the strength of a security policy. Quite simply, the security through obscurity policy is where certain facts are kept secret with the intent that doing so will provide some level of security for the whole system. Unfortunately, this does not work in computer security. Under the principle of security through obscurity, the administrator assumes that just because a user does not have the proper instructions or documentation to perform a certain action, he or she will be unable to perform it. I did some work for an organization where they used a home-grown accounting system for internal use. This accounting system was created in a commercial database package and used a standard text file to determine who would have what permissions in the accounting system. The problem with this file was that it had no security to prevent anyone from making changes to it. It was mixed in with literally hundreds of other files that occupied a dozen-or-so directories, so the likelihood of someone tripping across this one file was supposedly quite remote. This is security by obscurity. If someone had wanted to gain access into this accounting system, they would have merely needed to change that file. When I addressed this concern, the response was, "Well, no one has done it yet, and who's going to go looking for it?" That's a common problem with security. Just because it is obscure and hasn't been noticed yet, doesn't mean that it will not or cannot be done. Another example of security by obscurity is a situation where people feel that because the source-code for their software has not been released, people will not be able to analyze it and find flaws. Many flaws are found entirely by accident. Also, don't underestimate the ability of a dedicated hacker. Another example of something to avoid is developing an in-house security algorithm. Leave encryption to people trained in the subject. Security algorithms developed in-house are rarely secure. Just because you're convinced that it's safe does not make it so. In the case of UNIX, most of the source code is readily available and anyone with the proper knowledge and desire can analyze its security value. The source code for Windows NT on the other hand has not been made public. For some people this is a sign that the security might not be as strong as Microsoft claims. Microsoft has implemented a number of effective encryption algorithms in Windows NT, including Data Encryption Standard (DES) and Rivest, Shamir, and Adleman's public-key encryption method (RSA), which have been proven to be effective. DES is currently a US standard as declared by the Nation Institute of Standards and Technology (NIST), and RSA is the world's most used public-key encryption method. However, just because an algorithm is known to be effective, does not ensure the accuracy of the particular implementation.
For this reason, the C2 evaluation process is an important certification for Windows NT. Although Microsoft's in-house development team worked with many independent, world-class security consultants during the development of Windows NT's security system, this is not enough for some people. There are many people who believe that the only way to test a system's security is to open the source code to public scrutiny. In Microsoft's defense, neither they, nor any other commercially viable company, can afford to release their source-code to the general public. The Data Encryption Standard (DES), originally developed by IBM, was first endorsed by the US government in 1977. The important things to know about DES is that it uses a fixed-length, 56-bit key, is based on a private-key method, and uses a symmetric encryption algorithm. Now what does this mean? That it uses a fixed-length 56-bit key means that there is no way to make the algorithm stronger by increasing the key length. The algorithm used in DES has undergone an extreme amount of scrutiny over the past decade and a half by encryption experts world-wide. Although some people believe the National Security Agency (NSA) might have had a back door built in, no one has been able to find a way to defeat DES except through brute force attacks. That DES is a private key method goes hand-in-hand with using a symmetric encryption engine. Symmetric means that the same key you use to perform the encryption is also used to perform the decryption. This means if someone knows how to encrypt a file, he or she can also know how to decrypt it. RSA (Rivest, Shamir, Adleman) is a patented encryption method developed by Ron Rivest, Adi Shamir, and Leonard Adleman in 1977. RSA is a public-key, asymmetric algorithm that can use variable length keys and can be used for both encryption and authentication. That a cryptosystem is asymmetric means that the key used to encrypt the data is different from the key used to decrypt the data. This lends itself to an approach called public-key cryptography. In a public-key cryptosystem everyone typically has a public key and a private key. The public key is what is used to encrypt the data and can be given to anyone. Your private key must be kept secret and can be used to decrypt information encrypted with your public key. This enables someone to send me a document in a secure way by using my public key to encrypt it. Because you need my private key to decrypt it, and only I have my private key, the transaction is secure. This is not possible in a private-key cryptosystem such as DES. Also, unlike DES, the algorithm used in RSA enables you to increase the size of the encryption key provided and thus gain additional security. So which is better? DES and RSA are actually complementary, not competing cryptosystems. For many applications, DES is faster. RSA, however, provides functionality not possible with DES, such as digital authentication and the capability to conduct secure transactions over an unsecured channel. The important thing to remember is that it's a fallacy to rely on a belief that just because you think that no one knows something, or you think they will not be able to figure something out, it's secure. I met an administrator who used to setup "invisible," administrative shares on his Window NT Server for the computer support staff. He would create shares with a $ on the end of the name, which would prevent them from showing up in the network browser. His belief was that because no one else knew the share names and could not see them in the browser, he didn't need to implement proper share-level permissions. Although securing the shares would have been trivially easy, he was just lazy. Of course he was surprised to find out that it was in fact extremely easy for anyone to get a list of these "invisible" shares. This is security through obscurity. It might be argued that he didn't know that these shares could be seen, so it wasn't his fault. I don't agree. He made two fatal mistakes. First, it's his system—he should make an effort to understand how it works. Second, it would have been simple for him to implement the share- or file-level permissions necessary to protect his resources. He chose to hide them, because it was easier. This is also security through obscurity. Don't do it. Security Policies and ProceduresThe key to today's marketplace is information. The vast majority of our information is now being stored electronically by computers. It's increasingly becoming true that control of this information is what gives an organization the competitive advantage necessary to succeed in the marketplace. It is this competitive edge that we are trying to protect by designing and implementing a robust security policy for our computer systems. Many administrators seem to fall neatly into the two major extremes. The first group of people are those who think that implementing a strict set of computing guidelines is not necessary. They might feel this way because they are in a small company that is not connected to the Internet, or they feel that tight security policy gets in the way of the users. The rationalizations are numerous. Of course you've probably already guessed the second type of administrator that completes my stereotyped pair. This administrator is the one who has security fever. The one that people often call "control freak" behind his or her back. This person often tries to lock down every door and control every aspect of the environment, which often results in an Orwellian style of administration. For most organizations, an appropriate security policy would fall somewhere in the middle of these two extremes. Of course in some situations, such as banking, insurance, medical, and other industries where confidentiality is a concern, a security policy is always better on the more cautious side. I would never recommend any organization to completely neglect the development of a security policy. No network is too small or too unimportant to ignore creating and documenting a security policy. Developing Policies and ProceduresWhen you develop your security policies and procedures document, you should be sure to address all parts that make up and interact with your system. This includes the hardware, the offices and building itself, the network cabling, the operating systems—both on the clients and on the server—and programs that are used on the systems. You should also address any actions relating to the systems, such as what precautions should be taken in the event of a hardware failure or upgrade, how backup tapes should be handled, and so on. Additionally, you should take into consideration the users, the administrators, and any additional facility staff, such as maintenance and housekeeping. Of course it is likely that the greatest factor that will determine the depth of your security policy is the value of your data. If your systems are used primarily for simple office memos and fliers that have no lasting value, your data might not seem important enough to worry about. However, if your data has any lasting importance, or especially if it is of a proprietary or confidential nature, you need to take your security policies and procedures document very seriously. When talking to users about computer security it is important to relate computer security to other security issues in their lives. Many people wouldn't think of leaving their cars unlocked, or leaving the front doors of their houses wide open, yet these same people don't want to protect their computer systems. Many people are afraid that everyone is trying to steal their credit card numbers, but yet they don't admit the reality of people breaking into their computer systems. Also it is important not to alienate users by making them feel that they are not trustworthy or that they are being watched. When you discuss security issues with users, you should be careful not to create an adversarial relationship between the user and the security policy. Focus on the idea that the system is based on the principles that a user only gets access to resources they need for their work. Explain that this helps to avoid accidents as much as anything else. Commitment to SecurityIt's fine for you and me as system administrators to sit around a table and discuss implementing a security policy. If there is no buy-in from upper management, we can preach from here to eternity about the importance of a security policy, but nothing will happen. Upper management must participate during the entire development period. Their input and endorsement is essential. In some cases, you as the administrator might even be part of upper management. In that case you might have an easier job. I've seen too many instances where a well-developed security policy was ignored by all the users because the upper management didn't seem to care. Even worse is when management undermines its own policies by making exceptions for itself. No one should be exempt from the security policy. It should be followed by one and by all. It is there for the protection of the system, and ultimately of your organization's data and resources. Once a policy is developed, you must follow it. Like many other policies, a security policy can succumb to the fate of being nothing more than documentation that fills a binder in the office. No one reads it. No one cares. The policy should be followed with diligence. Users need to be reminded on a regular basis. Furthermore, the policy should be evaluated periodically to ensure its effectiveness and modifications should be made when necessary. Security AuditsIn computer security jargon, a security audit is the procedure of checking all the subsystems of a computer or network to ensure that all known problems have been protected against and that the appropriate security devices have been properly enabled. Additionally, NT provides a means to generate a log of almost all system activity, including when users log on or off, when a file is accessed and by whom, and even when print jobs are processed. This functionality is referred to as auditing. Routine security audits of the entire network are a good idea to ensure that holes haven't accidentally been opened and gone unnoticed. In your security policy document, you should identify items that need to be checked and determine how often they should be checked. As part of this process, you should develop an audit check list for your system. This list should contain information on how your share permissions should be set, how the security on certain folders should be set, what privileges different users should have, and so on. It might not sound like a glamorous job, but it needs to be done. It's all too easy to set up a system and attempt to let it run itself. However, without constant attention, that system is likely to run itself into the ground. I've met quite a few system administrators who claim to have nothing to do, yet wouldn't be caught dead looking through their system to make sure everything looks okay. Be proactive, not reactive. In organizations where the confidentiality of the data is essential, there should be formal policies in place to routinely audit the system to ensure that nothing has been compromised. In organizations such as these, you might want to designate an individual to be responsible for the auditing. This auditor would be tasked with using Windows NT's audit logs to verify the integrity of the data on the system. In financial institutions or other organizations that already have official internal auditors, these people should be trained to work with NT and to be able to read NT's audit logs for identifying potential problems. Of course, the auditor and the administrator could be the same person, but there are many cases in which you would not want this. The first reason is that very often the administrator is confident that things are set up correctly and might tend to gloss over areas that might actually contain problems. A second scenario in which the auditor and the administrator would be different people is if the auditing of your system is mandated by either law or corporate policy. A good example is a financial institution. Many of these organizations are required to provide audit trails that prove the integrity of the data. The audit features in NT allow you to know when the data—or the audit log—has been tampered with. Additionally some organizations might not "trust" their administrators fully. This might especially true in areas where proprietary trade secrets are involved. Also, in the government, for instance, private contractors sometimes perform administrative tasks on servers that contain data they should not be viewing. In this case a government auditor can be assigned to verify what the administrator has done. The most important thing to realize here is that NT allows you to enforce an environment where the administrator is not granted carte-blanche access to the entire system, but rather is held accountable for his or her actions. What is C2 Security?Listed prominently on Windows NT's list of features is that it meets the C2 computer security guidelines set by the US government. As with many matters relating to the US Government and security, it is often difficult to figure out what this really means. In writing this guide, I asked a number of administrators about Windows NT's security features, and they all ranted and raved about how secure of a system it is. Without fail, they all mentioned "C2" somewhere in their explanation about why Windows NT is so secure. However, when asked what the C2 meant, and what it meant to be C2-evaluated or C2-certified, they were stumped. The National Computer Security Center (NCSC) publishes the two definitive texts on computer security. By "definitive," I don't necessarily mean the most complete, comprehensive, or accurate, but rather that these two texts dictate the outward position held by the United States Government Department of Defense with regards to qualifying computer systems for use in various critical environments. Although these guidelines must often be adhered to in many government agencies, there is no requirement that the private sector take any interest—unless they wish to do business with the government. Nonetheless, many people in the private sector do take great notice because the guidelines set forth in these documents is definitely good advice. The Department of Defense's Trusted Computer System Evaluation Criteria (TCSEC)—also called the "orange guide" for the color of it's cover—provides security requirements for automatic data processing (ADP) systems. The companion to this guide—called the "red guide"—extends the interpretations for the evaluation of trusted systems to computer networks. These guides were developed to provide users a metric for determining the degree of trust they can put in their computer system. I don't recommend running off and getting copies of these guides for your guideshelf, as they are certainly not the most interesting bed-time reading material, unless you want something to put you to sleep! Although they might be a little dry, they are very important for explaining the evaluation criteria necessary to meet a specific security level. If you are interested taking a look, both texts are available in their entirety on the Internet by way of ftp, gopher and the World Wide Web. The TCSEC evaluation criteria is broken into four major divisions: Division D, Division C, Division B, and Division A, with Division D being the "least" secure and Division A being the "most" secure. Each division must meet the requirements of its predecessor and include additional features to provide enhanced security. Table 25.1 lists the different divisions. Table 25.1. The divisions of the TCSEC evaluation criteria.
Division D: Minimal ProtectionDivision D, called Minimal Protection, is reserved for systems that have been evaluated, but have failed to meet the requirements necessary for a higher division. Last I heard, no systems have actually been rated as Division D, because having a system evaluated is extremely expensive and most vendors prepare their systems adequately to meet a higher class. Division C: Discretionary ProtectionDivision C, called Discretionary Protection, provides for discretionary control of information, which can be accounted for by the use of audit facilities. This division is further broken into two classes, C1 and C2, with C2 being deemed the more secure. Class C1 is called Discretionary Security Protection and requires that some form of controls are in place to enable users to protect private information from other users. Systems in this class require users to identify themselves by entering a unique identity and validate their identity by entering a password. Naturally the system is required to maintain the integrity of the user/password data by preventing unauthorized access. The system will use the user's authenticated credentials to control both reading and writing of sensitive information. Additional, this class requires that the system within the computer responsible for authenticating the user is protected from external interference, which implies that a user should not be able to run a program to circumvent the security mechanism. The second class, C2, is called Controlled Access Protection. This class includes all of the requirements of C1, but adds additional requirements. C2 class requires that a control mechanism be provided to grant or restrict access to data files on a user-by-user basis. Furthermore, access permission to an object to which a user does not currently have access can be granted only by authorized users. A further requirement of C2 class is that when an object or file is discarded, no part of that data may be retrieved either intentionally, or accidentally. Although systems in class C2 are permitted to allow users access to data based on membership in a group, or access from a particular host, the systems must be able to identify and provide an audit record of exactly what user performed the action. Division B: Mandatory ProtectionWith Division D and C, it was sufficient to provide mechanisms for restricting a user's access to data and to audit any security-relevant actions. Beginning with Division B, however, it becomes necessary to provide mechanisms to label the sensitivity of data and provide mechanisms that ensure that authorized users cannot pass sensitive information—either accidentally or intentionally—to users without a sufficient level of authorization. This level begins a requirement that the system must enforce object control on a mandatory, not merely discretionary, level. Specifically, class B1 requires the implementation of this data labeling, which must be capable of including or excluding users to the granularity of a single user. Furthermore, the integrity of the labels and the capability of the labels to move with data as it is copied from one location to another must be enforced. The system must also mark the top and bottom of all printed, or other human-readable output with sensitivity labels that appropriately identify the output. There are additional and very precise requirements about the capability of the system to authenticate and audit access to data based on multiple levels of security clearance. Class B2 is essentially a strengthened version of B1, where its security system is required to control all aspects of the system environment. The security authority in the system must be designed in a carefully structured way and is subjected to considerably more scrutiny and review than lower-security classes. By way of review, this class is required to provide discretionary access control for all objects to the granularity of a single user. Furthermore, the capability to change access permissions on an object is restricted to authorized users. Objects that have been discarded or deleted cannot either accidentally, or intentionally be recovered by any means. All ADP system resources must be capable of being labeled by the security system, which will provide mandatory access restrictions based on the sensitivity label assigned to the resource. Furthermore, the integrity of the labels must be ensured, even when passing the object over various I/O or other internal or external devices. The beginning and end of all human-readable output must be labeled with the appropriate sensitivity information. The security system must notify an interactive user of every change in security status during the course of the computing session. As with prior levels, B2 requires the security system to maintain a database of authorized users and passwords for authentication, along with a detailed listing of the users security clearance authorizations. What is new in this level is the requirement of a guaranteed trusted path for the user's initial logon and authentication. Like the other levels, class B2 must support extensive auditing capabilities. Furthermore the architecture of the system must guarantee that the security system a protected domain of its own, free from external influence or tampering. Both hardware and software shall be used to enforce this, along with a mechanism for routinely confirming that no breach has in fact occurred in this protected domain.
Believe it or not, there's more. The B3 class system must satisfy the requirements that it mediate all accesses of subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this end, the security system is structured to exclude code not essential to security policy enforcement, with significant system engineering during its design and implementation directed toward minimizing its complexity. A security administrator is supported, audit mechanisms are expanded to signal security-relevant events, and system recovery procedures are required. The system is highly resistant to penetration. Division A: Verified ProtectionDivision A, called Verified Protection, has only a single category, A1: Verified Design. A system meeting this class must go through rigorous formal security verification to ensure that the system in fact functions exactly as intended. In order to be evaluated for this class, the system must be designed in a most exacting way and be presented with extensive documentation. Aside from meticulous testing, class A1 is functionally equivalent to class B3. Windows NT and C2 SecurityI can't count the number of times I've been asked what C2 certification meant. Other questions I've been asked over and over include why NT did not meet a higher level of security evaluation. For the way most people do business, C2 is about the most realistic level necessary—as far as NCSC goes. People needing additional security features should look for their criteria elsewhere, not in any of the rainbow-colored guides. Microsoft designed Windows NT from the ground up to meet the C2 criteria set forth in the Orange guide; the Red guide, an interpretation of the Orange guide for network systems; and the Blue guide, an interpretation of the Orange guide for other subsystems. They began working with the NCSC in 1992 to evaluate Windows NT for the C2 class. In August, 1995, Microsoft announced that Windows NT Server and Workstation 3.5 with service pack 3 passed testing and would be added to the official Evaluated Products List of C2-certified operating systems published by the National Security Agency. However, Windows NT is still being evaluated for the Red and Blue guide interpretations. What does this really mean? It means that the stripped-down and bare-bones operating system of Windows NT has successfully been evaluated at the C2 level. However, the networking systems and other secondary parts of the operating system have not yet completed evaluation. Currently for an NT installation to be C2 compliant, it must not be connected to any kind of network. If you need to ensure that a system configuration meets the C2 guidelines, you should refer to a security expert who specializes in this topic.
If C2 security is important to you, the good news is that evaluation of Windows NT is continuing to advance. The full certification process simply takes time. As of the writing of this guide, Windows NT is being evaluated for additional components, as well as for complete certification under the Red guide interpretations. In each chapter of this guide I have tried to address many of the security concerns about specific systems as they come up in their related areas. In this section, I would like to try to bring all those concerns together and address them in a single place. First I will review the basic features in Windows NT that can be used to help you create and manage a secure system. This will be followed by a discussion of other security-related issues that all NT administrators will want to be aware of. I have tried hard to come up with all kinds of odds and ends relating to security that I have often tried to find in a single place. Furthermore, I hope to persuade those administrators who don't care too much about security to reexamine this extremely important topic. Review of Requirements for Class C2 Security as Related to Windows NTWe've identified that Windows NT is in fact a product that has been evaluated to meet the C2-security rating based on the NCSC Orange guide. Let's review one more time the key criteria for C2 class systems:
Physical ConcernsMost of what we will spend our time on is about how to secure Windows NT from the software side. However, it is important that I first spend some time discussing some of the physical security concerns you might want to address. Remember that no matter how secure you lock down the software, if someone has physical access to the server, there is an increased cause for concern. ServerFor servers where the data is not confidential or business critical, it might be okay not to spend too much attention on the physical security of your server, but basic hardware security is so simple, I encourage you to give it some serious attention. Even if the data on the server is not of value to anyone else, there is still the chance that your office might get broken into and the server stolen just because it will fetch a some money on the street. Even if you are insured, how much will the lost productivity cost? Rule number one: Keep your server in a locked room. It shouldn't be kept in a highly trafficked location. By placing it out of the way, you remove many of the potential accidental problems such as tripping over cables and bringing the network down, spilling a drink or food into the machine, and so on. Furthermore, by restricting access to the computer you can limit the threat of someone gaining access to the power switch and the floppy drive. Most machines today enable you to use the CMOS to disable booting from the floppy drive. You can then password-protect the BIOS. In this way, you have taken a good step toward reducing the chances that someone can easily compromise the system. Remember, the floppy drive is dangerous. By booting from a diskette, someone can use low-level disk utilities to read the data directly off the drive, because Windows NT is not alive to protect itself. An even easier method would be to reinstall Windows NT and replace the security authority. In either case, this risk can be reduced by restricting the ability to boot from a floppy. When buying systems, often the emphasis is placed on things such as the processor speed and memory capacity while ignoring the quality of the hardware itself—including physical security features. It is good practice to buy equipment made from physically strong materials that can discourage tampering. This includes the having a lock that prevents people from opening the case. And if at all possible, a locking door to cover the power switch and reset button. If the case can be opened, the computer can be compromised. Again, remember much of this can be resolved by putting the server in a locked, secure room. When choosing a secure room for the server, also look up and down. The floor and the ceiling are often the easiest ways to break into a locked room. Many computing facilities still have cooling and venting paths that run under the floor. Often these are not secure and it is easy to pull one of the tiles from the floor, crawl under the door and enter a room. The ceiling path, however, is often the easier route. Most office buildings with drop ceilings are not usually planned with single-room security in mind. I did some consulting for an organization that required that the server was located behind two locked doors. The first lock was at the front door to the office suite and the second was on the office itself. However, the server room was located with one wall adjacent to the men's bathroom, with no firewall in between. The building opened to the public at 6:00 each morning, but no one usually came around until after 7:00. It was extremely simple for anyone to enter the building undetected from the basement and take the elevator to the appropriate floor. From there they could enter the men's bathroom, climb over the wall and they were in the server room. Does this sound kind of like the movie Sneakers? Also sounds a little paranoid? Well, I don't think that it would have been a laughing matter if someone were to follow this little plan. To the best of my knowledge, nothing has been done to rectify this problem to this day. I won't say exactly what kind of data could have been compromised, except that it could easily have resulted in a lot of people losing a lot of money. In fact I had a similar experience, where the customer had custody of sensitive social security data for statistical analysis. He insisted that the data could not be allowed to pass over their network of about 100 computers, because this would enable the possibility that someone could capture the data. When I asked what their suggestion for securing the data was, he replied that they would keep the computer in a locked room. When I pointed out the it was much easier to climb over the wall and access the computer than it would be to use a LAN sniffer to capture over 20 gigabytes of data, he refused to even entertain the idea that someone would climb over the wall. I guess that's just different perceptions of the world. Restricting the Boot ProcessYou should use the BIOS to disable booting from a floppy drive. Not only will this prevent people from booting to a different operating system, which could enable them to circumvent NT's security facilities, but if the floppy boot is not disabled, the server will not be able to reboot from a system crash or a remote reboot if someone accidentally leaves a floppy disk in the drive.
The additional benefit of disabling the boot-from-floppy option is the prevention of boot-sector viruses. While Windows NT is up and running it cannot be infected by a boot sector virus. However, if you boot the system off an infected floppy, the virus will infect the system. For more information on how viruses interact with Windows NT, see Appendix ???, Viruses and Windows NT. Also, you should make sure that no other operating system, especially DOS, is loaded on the computer. Some people recommend setting the timeout option for selecting an operating system during boot to 0 seconds. The theory is that this would prevent someone from tampering with the system. For example, if a person can boot to DOS, they could potentially modify the BOOT.INI, NTLDR, or NTDETECT.COM files, which could affect the functioning of your system. Additionally, if you have other system files or data stored on a FAT the partition, booting to DOS would enable someone to tamper with these files. If you set the timeout option to 0 seconds, you should definitely create a fault-tolerant boot floppy to enable you to boot Windows NT using various diagnostic features should a problem occur.
For more information on creating a fault-tolerant boot floppy, see Chapter 23, "Fault-Tolerant Systems." NetworkThe chief concern when putting computers onto a network is the division of sensitive information. The most common Ethernet configuration is an environment where the entire network is made of a single segment. In this environment, you are vulnerable because any other user on the network can tap and monitor all network traffic. If all users on the network are cleared for sensitive information, this might not be a problem, but typically this is not the case. Additionally, it is easy to create unauthorized wire taps for the sole purpose of capturing sensitive data. To help remove these problems, you should consider setting up a routed environment, dividing the network based on the level of secure information. This would prevent sensitive information from traveling the entire network. An additional option would be to run in a switched Ethernet environment. The price of switched Ethernet hubs has come down considerably and in many cases is considered more desirable than a routed environment. Not only do you gain the advantage that your sensitive information does not need to be transmitted everywhere, but the switched environment gives each node a dedicated bandwidth, resulting in better network performance.
If you need to protect against unauthorized wire taps, you should consider using fiber cable. You can then use network management agents to determine instantly if there is a cable break and investigate. However, just running fiber does not necessarily remove the risk of a user monitoring the network from an authorized network drop. If you are running a secure network and the cabling must run through an unsecured area, you should consider using encryption devices to encrypt the data before leaving the secure area and decryption devices it when it again enters a secure area. This is especially important if you are using the Internet to connect WANs. If you are attached to the Internet, you cannot guarantee who is going to have access to your data. To ensure that the security of the data is not compromised, you need to use encryption. Connecting your network to the Internet opens a whole additional can of worms. Not only do you have to worry about the security of data that you transmit across the Internet, but you need to worry about people coming into your network from the Internet. For more information about connecting to the Internet, see chapter 28, Windows NT as an Internet Server. User AccountsBecause Windows NT was designed to meet the C2 criteria, which is based on user-level authentication, any security-related issue in Windows NT must first be looked at from the context of a user account. That makes a discussion of user accounts a good place to begin. All objects have owners, and as we have already discussed in earlier chapters, almost everything in the Windows NT universe is an object. In fact, as future generations of Windows NT are developed, this object-based paradigm will continue to play a greater and greater role. The preliminary feature set of the next generation of NT, called Cairo, currently includes the implementation of an object-based file system. Many administrators are hesitant to create multiple user accounts for a single user. Sometimes they will even create one user account to be used by various people. For instance, creating a single user account for a front-desk receptionist, which is used by three people. The password is then shared among many people and the account is used by anyone sitting at the front desk. The problem with this is that it provides no accountability. If data is erased or something else is done, there is no way to know who was responsible. Additionally, if you want to change the password on this account, you must then worry about informing all necessary users of the new password. Both of these situations should be avoided. Every user should have at least one account. Some users, depending on need, should have more than one account—although rarely more than two. The thing that's important to remember is that Windows NT enables you to create as many user accounts as necessary. If people play multiple discrete roles, there is no problem in giving them multiple accounts with each account having the appropriate permissions for the particular role. Creating multiple accounts with only the rights necessary to perform specific roles is a valuable thing. I personally try to avoid using privileged accounts whenever possible, especially for day-to-day activities. It's too easy to slip in the NT Explorer or File Manager and delete the wrong directory. Slips of the fingers can be costly. To help alleviate this problem, you should consider using an NT Workstation for your administrative tasks. Because Windows NT can operate in multiple user contexts, you can be logged on to your workstation as a normal user but connect to your server as a different user to perform your administrative tasks. This obviates the need to log out and log back on in order to perform administrative functions. For more on this, see the section on Using an NT System for Management later in this chapter. It's also useful for administrators to get a chance to understand what it's like to be a plain, mild-mannered user. It gives them a better perspective of what a user's life is really like, and they can better appreciate when users come complaining that they can't do this or that. Many administrators don't realize the limitations of a normal user's account. On many clients such as Windows 3.x, Windows 95, and Macintosh, these limitations are not very apparent. However, the limitations on a Windows NT Workstation are more noticeable. There are lots of things a normal user cannot do by default. Try playing the normal user and see what it's like. User Accounts for ServicesUser accounts are not just for people. All processes in Windows NT run in the context of a user. As we'll discuss in a later section, many of the processes in Windows NT are set by default to run under the built-in SYSTEM account. This can pose security problems and I encourage you to consider making user accounts for some of these services and assign that account only the privileges necessary for the tasks it will perform.
Good security policy includes a routine audit of all accounts, active and inactive, to ensure that they should still exist and that they have the correct privileges. It might sound ridiculous and time consuming, but I've seen it more than once when a system administrator looked through the group assignments and was surprised to find out who the other domain administrators were! Don't let this happen to you. See the section on Auditing later in this chapter for more information. Rename and Don't Use the Administrator AccountThe Administrator account and the Guest account are two issues that need some special attention. It is often confusing to figure out how to best use these accounts and what, if anything, is particularly special about them. It is very important that you understand what these accounts are for and decide how best to use them. If you are familiar with the UNIX environment, the Administrator account is very similar to the root account, and should be used with as much caution. If you are familiar with Novell's NetWare, the Administrator account is similar to the Supervisor account. Although there are similarities to both of these other environments, there are also differences. The Administrator account is the first user account created when you install Windows NT. It is the ultimate user authority on the NT system. As the name implies, it can be used to perform administrative activities on the system, such as account management, disk and printer management, and security policy administration. Although NT has user rights that can be assigned to any user to enable him or her to perform these activities, the Administrator account can do all of these things. Furthermore, whereas user rights can be removed from normal user accounts, the Administrator account cannot be stripped of its powers. The intent behind this is to prevent you from locking yourself out of your system because you removed administrative rights from all the users. Because the Administrator account holds so much power, and this power cannot be removed, it is often a visible target for someone trying to break into your system. The Administrator account cannot be deleted, it cannot be disabled, but the good news is that it can be renamed. One of the special features of this account is that even if the system policy is set to lock out user accounts after a certain number of failed login attempts, the administrator account can never be locked out.
When you rename this account, you can call it anything you want. Picking a normal-sounding user name is often a good place to start. Also, make sure you remove the comment indicating that this is the built-in administrative account. Because this account is the only account in Windows NT that cannot be locked out—even if the password lockout feature has been enabled—it is an extremely attractive target for hackers. Using the API set that is built into Windows NT, it is not a difficult task to create a program that continuously attempts to logon to the system using a systematic password-guessing algorithm. By renaming the Administrator account, and enabling the account lockout feature, you can make a hacker's job more difficult. Furthermore, the built-in Administrator account is permanently a member of the local Administrators group. You cannot remove the privileges from this account, so you better make sure that you protect it properly. You should refrain from using this administrative account as much as possible, so as to minimize the attention you draw to it. It is better practice to create privileged accounts for each user who needs to perform special administrative functions. Take advantage of the built-in NT groups to grant people varying degrees of access. It is also important to inspect this account on a regular basis to ensure that someone else has not changed the password and that the account has not been compromised. Although the Administrator account cannot be locked out, if someone attempts to logon with the incorrect password the number of times specified by the account lockout policy, Windows NT places a check mark in the account lockout box under the Administrator account in the User Manager for Domain, as shown in Figure 25.1. The Locked Out check box is deceiving because the Administrator account cannot be locked out due to invalid logon attempts.
This is, however, somewhat misleading, because the account has not, in fact, been disabled. To confirm this, simply try logging on as the Administrator. Furthermore, if you audit failed logon attempts you can view the security log, which will confirm that the administrator user has not been disabled.
Disable the Guest AccountThe Guest account is the second built-in account that is automatically created when Windows NT is installed. The Guest account cannot be deleted, but it can be renamed. By default, this account is disabled.. In NT 3.51, the Guest account was disabled on domain controllers, but enabled on member servers and NT Workstations. Naturally, the history of the Guest account is for systems that allow one-time or occasional access. However, there is a more important role that the Guest account plays. When someone attempts to log on to an NT system across the network, the client presents a set of user credentials. If these credentials don't match an account in the NT security database and the Guest account is enabled, the user is logged on as the Guest user. If you want to use the Guest account for this purpose, the password needs to be left blank. If users will only be accessing these resources from the network, you might want to revoke its Log On Locally user right to prevent someone from logging onto local machines with the Guest account.
Personally I think the Guest account should be disabled in all but the most open environments. Creating accounts in Windows NT is so easy and any functionality provided by the Guest account can be easily duplicated in a secure manner by creating a few accounts.
In Windows NT Advanced Server 3.1, the Guest account was a member of the Domain Users global group, which was a member of the Users group. This presented a security problem because any resource that granted access to the Domain Users or local Users groups also granted permission to guests. By default the guest account was disabled, so it was not an immediate security problem. However, by enabling the guest account, the system administrator could create a potentially serious security problem and not even realize it. To help alleviate this problem, Microsoft made some changes beginning with Windows NT Server 3.5. A new global group, Domain Guests, was created, of which the guests account is a member. The guest account was removed from the global Domain Users group and is therefore no longer a member of the local Users group.
Implement Mandatory User ProfilesUser profiles enable an Administrator to customize aspects of a users machine when logged onto Windows 95 and NT machines. The profile is loaded when the user logs onto a workstation and gives the user the same desktop on all workstations in the domain. You can use profiles to restrict a user's access to the command line, or prevent a user from changing certain program groups. If your network has NT Workstations or Windows 95, you should consider implementing mandatory profiles. For more information, see Chapter 16, User Administration. User RightsBefore making changes to user rights, you need to make sure you understand not only the security-related consequences, but also what effect these changes might have on the rest of the system. For most NT Servers installed as domain controllers, the default user rights are adequate for security purposes. Because the default user rights are different for domain controllers and member servers, however, you should consider making the following two changes to any NT Servers that are not domain controllers:
Remember that the security setup on an NT Server that is not a domain controller, also called a member server, is essentially the same as an NT Workstation. By default, these systems enable Everyone and Guests to log onto the console and work. Furthermore, once logged on, these users can execute a system shutdown. Although this might not be such a big deal for an NT Workstation, it is a big deal for an NT Server configured as a member server. At one place I did some work for there was a large multiprocessor DEC Alpha running Windows NT Server that was sitting in a high-traffic area. This machine ran Microsoft SQL Server and served a number of important production databases. The administrator of was familiar with NT Advanced Server 3.1, where all servers were domain controllers. When he upgraded this machine to 3.5, he decided to make it a member server, because he didn't want the overhead associated with making it a domain controller. Unfortunately, he didn't understand the differences between the user accounts domain controller and on a member server, so he did two things wrong. First, he left the guest account enabled, which had been the default (and is no longer the default for an NT Server.) Second, he left the Log on Locally user right granted to Everyone and Guest. For months the server ran this way. One day I reviewed configuration on the server and discovered this problem. Essentially anyone could log onto the server with the guest account, or any user account from the domain, or trusted domain and had almost free access to the server. Because the machine was solely a SQL server, and not a file and print server, he hadn't bothered to make sure the NTFS file permissions were locked down. Essentially anyone who had physical access to the machine could have done almost anything to it. So what is the lesson here? First, know your machine. But that's obvious. More importantly, if your NT Server is a member server, you should make a point to change the permissions listed about to make sure ensure an acceptable level of security at the console. For a complete description of all the user rights, see Chapter 16, User Administration, and Appendix C, List of Default Group Privileges and User Rights. Understand the Bypass Traverse Checking User RightBypass traverse checking is a user right that is enabled for everyone by default in Windows NT, as shown in Figure 25.2. The problem is that most administrators do not fully understand what it does and why its there. By default, the Bypass Traverse Checking user right is enabled for everyone.
Having the Bypass Traverse Checking right tells NT to only check the Access Control Lists (ACL) on the file or directory a user is accessing—not on its parent directories up to the root. Although this sounds like a fairly easy concept, it has some ramifications that should be fully understood. Leaving bypass traverse checking enabled can be a big problem if users are not careful and aware of its security-related consequences. To illustrate what this right does, look at the security differences between moving a file and copying a file, as well as how and when access rights to a file are inherited. This example should give a clearer example of what this right does.
Consider the following scenario:
If you disable the bypass traverse checking user right, and then repeat this exercise, you will be unable to open the file E:\TEST2\MYFILE.TXT regardless of whether you copied or moved it. This is because with this user right disabled, Windows NT checks to ensure that you have the appropriate privileges for every directory beginning with the root. To further illustrate this concept, let's say you have a file E:\USERS\ADMINISTRATION\JGARMS\WORK\FAXES\THISFAX.DOC. Assume the ACL on THISFAX.DOC grants Everyone Full Control. If a user has the Bypass Traverse Checking right (and remember all users have it by default), the user will be able to read, modify or delete this file, regardless of what rights the user might—or might not—have to the parent directories that this file is nested in. If you removed all permissions from C:\, C:\USERS, C:\USERS\ADMINISTRATION, C:\USERS\ADMINISTRATION\JGARMS, and C:\USERS\ADMINISTRATION\JGARMS\WORK, the user could still read, modify or delete this file. However, if you remove the Bypass Traverse Checking right for this user, he or she would need rights to each directory in the path in order to access this file, even if he or she had Full Control permission on that file. The ability to modify the Bypass Traverse Checking right is really included to provide strict POSIX compliance. You should disable this user right for any users or systems that requires strict POSIX compliance. However, one of the downfalls is that enforcing traverse checking can cause some performance degradation since the ACL for each item in the path must be checked whenever a file is accessed.
GroupsThe user account is the most granular level of user identification in Windows NT. Any action can be directly linked back to the user who initiated it. However, having to administer your entire system by assigning privileges to individual user accounts would be time consuming, especially if you have a large user base. Groups provide you a tool for assigning user rights and privileges based on a common set of needs. For example, all users who need access to a certain printer might be put into a single group. That group would then be assigned the appropriate permissions on the printer and anyone who needed to use the printer could be assigned to the group. Aside from the convenience this provides, it actually improves security. By assigning permissions based on group membership, you can see very quickly who has access to what resources. Furthermore, you can quickly validate that the permissions are set properly. Consider this. In the previous example we talked about assigning rights to a particular printer. Say we had 40 users who needed to print to that printer. If you wanted to verify the permissions, you would have to review 40 access control entries (ACE) to ensure they are set properly. If you assigned the resource based on group membership, you would simply verify that that the one ACE for the group was set properly and then review the membership list for the group. By managing your resources this way, the security of your system can be enhanced by providing a much less error-prone way of assigning permissions.
A more detailed explanation of using groups to simplify administration can be found in Chapter 18, Administering the Server. Managing Built-In User GroupsFrom a security perspective, you need to make sure that you understand the rights and restrictions provided by membership in the built-in computer groups. Windows NT creates different default user groups depending on the security role it will play in the domain. Many people think that the built-in user groups depend on whether the system is an NT Workstation or an NT Server. This is only partially correct and a potentially serious misunderstanding. Windows NT Workstation will always have the same built-in groups. However, the built-in user groups on an NT Server depend upon the role of the NT server. If it is a domain controller (DC), it will not maintain its own local accounts database and will inherit the user database from the primary domain controller (PDC). What many people don't realize is that a Windows NT Server configured as a member server—not a domain controller—does not have the same built-in groups and user rights as the rest of the domain. This can be a serious problem. A Windows NT Server configured as a member server has the same default users, groups, and rights as an NT Workstation. For example, they both permit the Guest account, as well as domain users, to log on locally. Consider the following configuration. You install a Windows NT Server as a standalone server and want to use it to run SQL Server. You run the system on a DEC Alpha server. If you don't realize that its local security database looks identical to an NT Workstation (because the NT Server is a member server, not a domain controller), you might not realize that you need to make some changes. For instance, by default anyone can log on to the server console using the Guest account. The level of potential damage is very high. Because this is a RISC system, its boot volume must be on a FAT partition and is therefore vulnerable. The intruder could delete the necessary files from your boot partition, rendering the server incapable of starting up. I actually know of a situation where this happened. Other actions the hacker could perform are equally damaging. For this reason, it is important to realize that a Windows NT Server that is not configured as a domain controller has special needs and should be secured the same way as an NT Workstation. For more detailed information on the built-in user groups, please refer to Chapter 15, Administering the Server. Making Optimal Use of PasswordsThe password is everything. If a password is compromised, so is the account and anything the account has permissions to. Furthermore, an account that has been compromised to someone outside your organization, no matter what permissions the compromised account might have, is a building block that could allow further penetration. Remember, it is always easier to break into a system from the inside. This is why implementing a security policy based on least-needed permissions is a valuable choice. Because most networks rely on shared bandwidth to connect systems, it is not at all difficult to get someone's password if it is sent in clear text over the network. For example, if you connect from your machine to an ftp server or telnet server elsewhere on your internal network, or even across the Internet, do you know how many people could potentially "watch" your password go over the line? Because most people use the same password for everything—although this is not recommended—all their accounts would be compromised if someone got hold of their password. Windows NT enables you to designate password-related account policy through the User Manager. Changes made to the account policy are global in that they affect all users of the computer or domain. It is important to realize, however, that modifying the account policy for the domain does not affect the account policy for local accounts on non-domain controller machines in the domain. Remember, these computers maintain their own local user accounts. Avoid Clear-Text PasswordsIt is important to understand why clear-text passwords should be avoided in all cases, unless there is a very good reason to keep the password in clear text and the repercussions are fully understood. Windows NT does not store users' passwords in clear text and the NT logon service never transmits passwords over the network in clear text. However, there are other things that need to be observed.
You should refrain from entering passwords into batch files, shortcuts, or into Program Manager icons. Shortcut information and Program Manager icons can be easily accessed on Windows 3.x and Windows 95 machines and can also be accessed through the Registry in Windows NT. Any password entered into these places should not be considered safe. There are third-party services that run on Windows NT that integrate with the security account database. If connections are accepted by this service from the network, Windows NT cannot ensure that these passwords are not being received across the network in clear text. One good example is the implementation of Post Office Protocol (POP) services. Under request for comment (RFC) 1225, which defines mailbox retrieval for POP clients, clients send clear-text passwords over the network. For example, the POP mail server created by European Microsoft Windows NT Academic Centre (EMWAC) integrates with the Windows NT user account database and accepts clear-text passwords from clients who connect to read mail. This password, which is the user's domain password, is then sent in clear text over the network. This is not NT's fault. It's not even really the POP server's fault. It's the definition of the protocol. Authenticated Post Office Protocol (APOP), a new version of POP that allows for encrypted password transport, is currently gaining a following. It requires updating both the POP clients and servers. Setting Password Policy Through the User Manager for DomainsPassword-related account policies that can be changed through User Manager include the minimum and maximum password age, minimum password length, password history, account lockout, and enforcement of logon hours. The screen used to control the account policy for the domain is shown in Figure 25.5. Account Password Policy is controlled through the User Manager.
Maximum Password AgeBy default, passwords never expire in Windows NT. However, even in environments with minimal security concerns, it is important to force users to change passwords on a regular basis, because the security provided by a password decreases the longer that password is in use. If you check the maximum password age option, you can set the age to anywhere between 1 and 999 days. The maximum password age must be greater than the minimum password age. I find that 45 days is a reasonable length for most environments, although some people say this is a little conservative. Even if you don't want to be conservative, you should not allow passwords to last longer than 180 days. Passwords can be prevented from expiring on a user-by-user basis by checking the Password Never Expires for the user's account in the User Manager for Domains, as shown in Figure 25.6. Remember, passwords are at the heart of your system's security. The more times a user types his or her password at a keyboard, the more likely it is that it will be compromised. However, if your boss comes to you and says, "I don't give a damn about your security problem, I don't want to have to keep changing my password!" then maybe you should check this option. As humorous as this might seem, it happens. There is also a more practical and common instance where you would want to prevent a password from expiring. If you have accounts created for specific services, such as for the schedule service, you might want to prevent the password on these resource accounts from expiring by checking the Password Never Expires option. Passwords can be prevented from expiring on a user-by-user basis, regardless of the overall system policy. Minimum Password AgeThere are good reasons for implementing a minimum password age. One reason is to discourage users from changing their passwords so often that they forget it. A second, and even more practical reason works in combination with the password uniqueness feature listed next. The minimum password age can be from 1 day to 999 days and must be less than the maximum password age. Minimum Password LengthFor the most part, the shorter the password, the easier it is break. By default, no minimum length is required and blank passwords are permitted. You should use passwords of no less than six characters and encourage you users to use good passwords, containing a mix of uppercase and lowercase characters, numbers and punctuation. If you choose to enforce a minimum password length, you can choose a length from 1 to 14 characters. Windows NT does not permit passwords longer than 14 characters. Of course the minimum password age must be smaller than the maximum password age. Password UniquenessPassword uniqueness is useful for ensuring that a user does not use the same password over and over again, thus eliminating any security gains from making the user change the password. Password uniqueness is effectively used with minimum password age. If you do not enable minimum password age, a user could change his or her password a number of times in a row and end up with their original, again defeating the purpose of password uniqueness. Choosing a minimum password age of even one day would essentially remove this problem. You can set Windows NT to remember anywhere from 1 to 24 passwords. I have heard of no problems setting the number of remembered passwords to a high number, even in sites with thousands of users in their account database. A setting of five to seven should be sufficient for most environments. Implement Account LockoutIt is a good policy to implement the account lockout feature. This prevents hackers from attempting to gain access by trying a sequential password-guessing program. However, unless security is of the utmost concern, you should be careful when implementing this feature so you don't increase the level of difficulty for the user. Many more conservative administrators recommend a setting from three to five. I would recommend a slightly higher setting of around seven, unless extremely tight security is critical. The first reason you might want to increase this number is that when most Microsoft clients attach to other systems, they immediately try to authenticate themselves using the currently logged on user name and password. If the user name you're logged on as is the same as the machine you're connecting to, but the password is different, this will immediately result in one failed logon attempt. If you type your password incorrectly, the system will fail your logon attempt. That's two. If you attempt to logon again, it will try your current credentials again, that's three. If you're lockout was set to 3, you'd now be locked out, although you only typed your password wrong once. Here's a slightly different scenario. I'm working at my NT workstation and am logged on using my standard user account, jgarms. I need to use my administrative account, jg-admin, to attach to the STUFF share on a server called \\PRIMUS to get a file. At the command line I could type net use * \\PRIMUS\STUFF /user:NTDOMAIN1\jg-admin. The problem is, although NT tries to authenticate me using the correct user name, it tries to pass my current password for authentication. This results in a failed login attempt before I ever got a chance to type my password. One bad logon attempt is not a problem. However, If I do this enough times, and within the time period set in the User Manager, then I will lock out the account. I know that there are people out there who are probably saying "If you had typed net use * \\PRIMUS\STUFF /user:NTDOMAIN1\jg-admin * NT would have immediately prompted you for a password." That's correct. However, if you had been performing this action using the Map Network Drive in the NT Explorer, or with the File Manager, NT would have tried your current password first. The previous example is just to show that there are good reasons to carefully consider how you want to set these options. Most problems similar to this example would happen to administrators and power users.
You can set NT to lock out an account after a specific number of failed logon attempts. The number of failed logon attempts before the lockout occurs can be anywhere between 1 and 999. You can also specify the windows of time during which the failed logon attempts must occur in order to lock out the account, as well as the duration for which the account will be locked out. These values can be set to between 1 and 99,999 minutes (almost 70 days), but the duration must be greater than or equal to the reset count. For example, you might set the accounts to lock out after five failed logon attempts within a 60-minute period, and have the account stay locked out for five minutes. This would discourage a hacker from trying to break into a system by guessing passwords, but it will also enable a user to continue working without having to contact the administrator. Forcibly Disconnect Remote Users from Server when Logon Hours ExpireWhen a user approaches the end of his or her permitted logon time, the server automatically sends a message to notify the user. If this option is enabled, the sever will send a couple more notices before finally disconnecting the user. Even for environments where you don't care when your users access the server, you might want to force users to disconnect during the server backups to ensure that all files get backed up. If this option is disabled, users can still work on the server when their logon time ends, they just cannot make new connections. This might be desirable when it is not critical that users log out immediately and you don't want to risk possible interrupting something they are doing. Users Must Log On in Order to Change PasswordNormally when a user's password is getting close to expiring, he or she receives a warning each time they logon that the password will expire in x days. The user is also asked if they want to change the password at that time. If this option is not selected, and the user allows his or her password to expire, the next time that user logs on, he or she will be told the password has expired and will be prompted to change it immediately. However, when this option is enabled, the user will not be able to change his or her password if it is allowed to expire. Instead, the user must go to the administrator to have the password changed. Review of Password PolicyImplementing good password policy is very important. However a good password policy does not end with deciding on the minimum password length, or password uniqueness, or password expiration. There are additional issues that require some attention. It is important to realize how passwords are used and stored—both on your computers and on your network. We have discussed why it is important to decide if users should be allowed to include passwords in command-line batch files, or Program Manager icons. You also need to consider what programs are in use on your network that require passwords. Most people will tend to use the same password for all applications. This is good and bad. The good of it is that it makes their lives a little easier. The bad, however, is that if one program does a poor job passing this password across the network, or storing it, all systems secured by this password are compromised. Another example of where your password might be compromised is if you log in from a Macintosh using the standard Macintosh authentication method. Here, again, your password is sent in clear text over the network. Also, many in-house database and client/server applications use rudimentary login procedures and often send these passwords and user names in clear text across the network. So what's the big deal? Believe me, it's not just paranoia. LAN analysis tools are becoming a dime a dozen—in fact, NT Server now ships with one, called the Network Monitoring Tool. Additionally, anyone can go to their local computer software store and buy a program that will turn their tool into a packet catcher. And the programs are just getting better and better. The hardware on many users desks are already of sufficiently high performance to take advantage of these programs. Furthermore, many smaller LANs are still single segments and many larger LANs often run as bridged environments. This means that any Ethernet tap on the network can be used to tap the entire network. Sounds pretty ugly, right? And it happens. The last rule to remember about passwords is that just because an application uses a password, it's not necessarily protected. This is tied in to what is mentioned previously, but differs slightly. If anything in your network can be trusted, the algorithms in Windows NT's password mechanism can be. For the most part, you have no choice but to trust them. What is important is allow them to do their job, and encourage the users to do their job, which is]taking care to protect their passwords. However, there are many programs that put passwords on your files and some people feel this is sufficient. It rarely is. Unless you know from a reliable source (and the manufacturer is not a reliable source), these password-protection schemes should be considered to be little more than child-proof locks. Many of the algorithms used to "encrypt" files in standard commercial office suites use simple hashing algorithms, which are easily broken. In fact there are many people on the Internet who seem to make it their hobbies to break these "encryption" methods and then post the method on the Internet for all to see. What does this mean? It means I would rather trust a well-secured Windows NT system to keep my data safe than have a false sense of security from these simple password protection schemes. Logging OnLogging on to the system is perhaps one of the most important security-related actions you take. It is during this process that the system compares your credentials to the NT's security account database and either denies you access or grants you an access token, which is used to validate all of your actions during that logon session. Control-Alt-Delete LoginWhen Windows NT 3.1 first came to market, a lot of people had a difficult time adjusting to the idea that you press Ctrl+Alt+Delete to logon to a system. After all, coming from a DOS background, this would do no less than reboot your computer! So why did Microsoft choose this key combination as a logon sequence for Windows NT? The main reason Microsoft used this keystroke is that nothing else ever uses it. They needed a keystroke combination that no other program would want to use as a hot key. The only really safe keystroke to use is Ctrl+Alt+Delete. Trapping for this key combination is performed at a very low level in Windows NT, and no other application is able to trap it. This assures that when a user presses Ctrl+Alt+Delete, the window that pops up is the logon process and not a Trojan horse. I have heard people argue, and even read in many places, that another reason Microsoft cho |
