|
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 chose the Ctrl+Alt+Delete was that because it usually resets MS-DOS machines, it would make it more difficult for someone to use a DOS-based computer to impersonate an NT logon process and thereby capture a user's password. I personally don't think this really played much of a role in the decision, because it is easy to trap Ctrl+Alt+Delete on DOS-based computers and use the keystroke for other purposes. The only caveat here is that if someone has had access to the NT-based computer, it is possible that they could have installed a DOS-based program that appears to be the Windows NT logon service—deleting NT from the machine if necessary—and captures your password, denies you access, reporting some bad-password error. The program could even then be written to trash the hard drive to remove evidence that it had been there. Sound unlikely? It happens. You might not think it could happen to you, but this is why your network is only as secure as the physical security precautions that guard it. Hiding the Last User NameIf you've ever used UNIX before, have you ever gone up to the console and had it tell you at the login prompt who the last person to logon was? Or have you ever used Telnet to connect to a computer and had it tell you that JohnD was the last user. I don't think so. Most people, even anti-UNIX bigots, would think such a thing would be absurd. Then shouldn't it also be considered absurd that Windows NT tells you the name of the last person to logon to the console? Personally I think so. However, Microsoft did it this way for ease of use, not to mention the tradition of all Microsoft network products that have always done it this way. It is actually quite easy to prevent NT from telling the world the name of the last user. I always recommend doing this, for two reasons. The first reason has nothing to do with security and is more geared for administrators of NT Workstations. Let's go back to the previous UNIX example. Could you imagine a UNIX user not knowing his or her logon name? Under certain circumstances when the user logs in with scripts, yes. But people who use the system on a daily basis for work? Seems strange. However, for some strange reason users in the Windows world seem to have problems remembering their user names. I can't count the number of users who are accustomed to having their user names already filled in and only have to enter their password. If you dare to logon to their system and your user name appears there, they will be totally lost and unable to figure out why they cannot login. What's worse, if you have the account lockout feature enabled, you might get your account locked out before they figure out what's going on. I've had more than one irate user call to grumble and ask how I could expect them to remember both a user name and a password! If you're running for no other reason, disable this feature so that you users learn their user names. If the first reason has nothing to do with security, the second reason has everything to do with it. If someone walks up to your server, they should not be able to get any useful information from it without authentication. Your user name can be considered important information, especially if you don't want people discovering the renamed administrator account. I had a user get upset when I disabled this feature. In addition to complaining about how much extra work it was for him to have to type his user name every time, he wanted to know when other people had been using his computer. If there is a concern about who is logging in to a computer, use the audit logs for tracking this. In fact, I highly encourage you to audit these logons and periodically review them. This audited information, unlike the last-logged-on-user information, is restricted to privileged users. To prevent Window NT from displaying the last logged on user name, use the Registry Editor to assign the following Registry key value:
Display Legal NoticeI highly encourage everyone to use this feature. Displaying a legal notice has long been considered an important feature to assist in the prosecution of people who attempt to gain illegal access to a machine. Many hackers have been set free because it was determined that the "Welcome" message displayed when they tried to logon was an indication that it was acceptable for them to logon. When deciding on what kind of text to put in this box, the most appropriate is usually some simple text that states that the computer system is for authorized use only. An additional statement that all use of the system is subject to various monitoring techniques without the user's permission might be a good addition. Typically, you'll want to refrain from making any threats about what might happen if users attempt to use the system without proper authorization. Of course, in a sensitive environment, you might want to consult a lawyer to assist with the actual text of the message. Many larger organizations and government agencies have developed stock messages that traditionally were used on mainframe or other multiuser systems, such as UNIX. The legal notice includes a title for the legal window, which is usually something like "Warning!" that is followed by a body of text that is displayed in the pop-up window. This window will appear during logon, immediately after the user presses Ctrl+Alt+Del. The user must then click on the "OK" button, which signals their acceptance of the terms in the legal warning. They cannot logon without clicking "OK." Figure 25.7 is an example of what the legal warning windows looks like. You can set a warning that appears when a user tries to log on at the console.
To implement the legal warning feature, you must make modifications to the Registry. There are two Registry entries that should be set. One is for the caption and the other is for the text. Both of these entries should already exist, but the strings are empty by default. If the keys do not exist or have been accidentally deleted, they can be created using the Registry definitions listed in the following example.
For instance, follow these steps to create the legal warning shown in Figure 25.7.
Time-out when Entering Bad PasswordsWhen a user tries to logon locally to a Window NT machine and fails five times in a row, the system will wait for 30 seconds before allowing the user to try again. This is very similar to many UNIX and other system that allow console logons. It is intended to make password guessing at the console a painfully long process. This time-out only occurs during an interactive logon attempt. Use an NT System for ManagementI keep talking about how security is a major element in Windows NT. Windows 3.x and Windows 95, however, do not provide anything approaching the level of security that Windows NT does. Despite the fact that Microsoft offers NT management tools for Windows 3.1 and NT Workstation, if you want to ensure the security of your system, you should only administer it from another NT machine. Because we've already agreed your server should be somewhere in a locked room, which is not always convenient to run to all the time, you should consider using an NT Workstation for your regular administrative duties.
Aside from getting NT's standard security features, which we've already discussed, there is another benefit from using an NT system for administration. Windows NT is often billed as a "multiuser" system. Many UNIX traditionalists have fought this point, but try as they might to discredit this claim, NT is truly a multiuser system—it just depends on what definition you use. The difference in views as to whether or not NT is a multiuser system comes from a difference in perception of what multiuser really means. For many people, a multiuser system is that which is capable of having multiple people logged into it at the same time, often through some form of terminal, and each performing individual tasks. Windows NT doesn't strictly adhere to this definition. However, what's probably more important to use as a definition for a multiuser system, is a system that is capable of running multiple processes simultaneously, each in its own user context, and each protected from the others. In this definition, NT excels. So what's the difference? Obviously the first definition is from a user's point of view, while the second is from a system's or process's point of view. Because of NT's architecture is fully capable of supporting the first classification, as well as the second classification. If Microsoft would have simply shipped a Telnet server with Windows NT, no one would have argued that NT is not multiuser. However, Telnet servers are available for NT, and actually, they are quite simple because they are merely extending the hooks that already exist. One of the benefits that you get from using NT as your primary workstation is the ability to logon to different network resources with different user names. What does this mean? It means you can be logged onto you local workstation as an unprivileged user, and connect to and administer other systems using privileged accounts. This eliminates the need to log off and back on as another user to perform administrative functions. For more information on why you should use a nonprivileged account for you routine work, see the section Rename and Don't Use the Administrator Account, earlier in this chapter. Administering from Windows 3.x and Windows 95If you use a Windows 3.x or a Windows 95 machine for administration, you run into a number of potential problems. These other operating systems do not provide mechanisms to prevent other processes from grabbing your password as you type it. This opens up the possibility of Trojan-horse applications stealing your password. To help protect yourself, you might want to consider avoid logging into non-NT systems with a privileged account. If you need to log into other computers using this account, you should be sure to take precautions. For more on using Windows 3.x and Windows 95 machines to administer NT Servers, see Chapter 9, Working with Clients.
Use Microsoft's User Authentication Module for MacintoshThere are good security reasons to use Microsoft's User Authentication Module (MS UAM) for the Macintosh, and there are compelling user-oriented reasons not to use it. First, the pros. Although Macintosh AppleShare clients support an encrypted password for connecting to AppleShare servers, Windows NT does not support this password encryption method. Without the MS UAM, a Macintosh client would be required to send its password in clear text over the network. As we've already discussed numerous times, this is a big problem. Microsoft provides the UAM that can be installed on the Macintosh clients to provide a secure password transport between the client and Windows NT Servers running Services for Macintosh. By default, users can connect from Macintosh clients using clear-text passwords. However, you can require that users only connect using the MS UAM. This can be done from the MacFile icon in the Control Panel as shown in Figure 25.9. You can require Macintosh users to connect using encrypted passwords instead of clear-text passwords.
By checking the "Require Microsoft Authentication" option, Macintosh users must install and use the MS UAM to connect to your NT server. Now for the bad news. By doing this, you have a very good chance of upsetting quite a few Macintosh users. If you're not a Macintosh user, bear with me and try to see it from their side. Why? In MacOS version 7 (actually back then it was called System 7) Apple introduced file aliases. These are very similar to shortcuts in Windows 95-interface jargon, except that Macintosh aliases keep better track of their targets. When you were attached to a file server you could create an alias to a file and place it on your desktop, much like you can with the new Windows 95-style interface. If you then removed your connection to the file server and tried to open the alias, the Macintosh would automatically go through the proper procedures for logging you onto the server so it could open your file. The only problem is that when the alias tries to open the file server, it will only use the default Apple UAM, not the MS UAM. Not to point fingers, but this is a problem with the MacOS. It also occurs when Macintosh users try to access NetWare servers using Novell's UAM. You can get around this by telling people not to create aliases to items on the file servers, but I don't recommend this approach. This might not get too good of a response. Or you can tell people that they need to manually logon to the file server before opening the alias. Unfortunately, there is no acceptable workaround that will make everyone happy. Use Password-Protected 32-bit Screen SaversWindows NT gives you the ability to have the workstation or server automatically secure itself after it has been idle for a specified period of time. This feature is implemented through the screen saver option. There are some important points worth mentioning here. The console can be set to lock after a specified number of minutes without mouse or keyboard activity. This option is adjustable on a user-by-user basis and should be set through the Desktop icon in the Control Panel as shown in Figure 25.10. Screen savers with passwords can be used to protect your data when you step away from the computer.
By checking the password protected option box and setting an appropriate delay time, the security of your console can be increased. The delay can be set in single-minute increments from 1 to 99 minutes. (Actually by using Registry Editor to change the ScreenSaveTimeOut entry in the users ../Control Panel/Desktop subkey, you can set the delay in seconds, though this level of granularity should not be necessary.) The length of the delay that should be implemented will vary from environment to environment. I typically set all of my systems, including my primary workstation, to one minute. I do this primarily to ensure that if I am logged in with a privileged account and get distracted, the system is not compromised. For many environments, this might seem a little draconian. However, I find that it works rather well now that I'm used to it. I'd prefer to take precautions up front rather than clean up later after carelessness.
When choosing a screen saver, there are a couple of factors that need to be addressed. The first is ensure that you have picked a 32-bit screen saver. When choosing a 16-bit screen saver, Windows NT will gray-out the password protect check box. The first reason this is done is because the 16-bit applications cannot use the Win32 API calls necessary to interface with the security subsystem to check the validity of a user's password. Second, even if you were allowed to enter a password for 16-bit screen savers, as with other 16-bit applications, they run in a shared memory space. Because this memory space is not protected, it's not too difficult to write a program that snatches the password from the screen saver when the user enters it, thus compromising your password. The lesson here is to only use 32-bit screen savers. Additionally, you might want to avoid using third-party screen savers unless you are sure of their quality and have specific reasons for using them over the standard Microsoft-supplied ones. The code for the Microsoft screen savers has been checked by numerous sources to ensure that there are no holes that would allow the system to be compromised. One other concern when choosing a screen saver is the performance degradation caused by running the more complex screen savers. I mention it again here to emphasize how important this is. Choosing a complex screen saver for your server, especially one of the OpenGL ones, can literally cripple your entire system. Again, for more information on this, please refer to Chapter 19, Performance Tuning and Optimization. Allowing Only Logged On Users to ShutdownBy default, in order to initiate a restart or shutdown, Windows NT Server requires that a user be logged and have the appropriate user rights, typically granted by group membership. For more information about user rights, see the section on user rights earlier in this chapter. The default installation of Windows NT Workstation, however, permits the system to be shutdown or restarted without a user first logging on. I would recommend that you disable this in any environment. As for why exactly Microsoft chose to set this as the default option, I can only guess that it was merely designed for convenience. If someone approaches a machine and is determined to shut it off, the power switch is always a last resort. Perhaps the reasoning is that by putting a shutdown option on the logon screen, maybe the person will safely shut the system down first. Go figure. I'm sure all the readers out there with UNIX backgrounds are probably saying that you would never find such a strange option on a UNIX workstation. To require users to be logged on before shutting down a system, change the following Registry key value:
Changing the value to 1 would allow the system to be shut down without a user first logging on. Caching Account Credentials on Windows NT SystemsWindows NT caches the account credentials for the last 10 users. This is intended to allow a user access to the system even if all domain controllers are offline. In most environments, caching the credentials should not be a problem, because they are stored in the system's security database and cannot be compromised the same was as cached account information on a Windows 3.1 or Windows 95 system. It is fully possible, however, to abuse these cached credentials. Consider the following situation. I am the administrator of a network of Windows NT Workstations connected to a Windows NT Server. Security is a concern and we have chosen Windows NT for the desktop because of its robust security system. User JohnS has been fired and I have been asked to disable his logon account to prevent him from accessing any of the computer systems and accessing any sensitive information. The problem with the cached user credentials is that although I disabled his user account, he still can logon to his local NT workstation and access files using his cached credentials. To do this, he would simply disconnect his computer from the network and log on. Windows NT will tell him that it cannot find the domain controller, but will log him on using cached credentials. You can check to see what user profiles are currently cached on your system. Simply right-click on the My Computer icon in the NT Explorer and choose the Properties option. Then choose the User Profiles tab. This screen displays the profiles currently stored on the system and allows you to delete cached profiles. Files, Directories, and SharesThis section covers implementing file system security features to help secure your Windows NT Server. It does not include a detailed description of the features of NTFS and how to assign permissions. This information is covered in Chapter 6, File System Management. Instead, I have tried to focus more on warnings about what you should and should not do to make your system as secure as possible. Use NTFS for File- and Directory- Level PermissionsNTFS is the only file system in NT that supports file- and directory- level permissions. This alone makes it considerably more secure than either FAT or HPFS. The capability to set permissions, fault-tolerance, and access speed are all good reasons to use NTFS for all partitions. If you choose not to use NTFS, make sure you fully understand the security limitations that this will create. NTFS does not provide an encryption facility. If a disk containing an NTFS partition is removed from a machine and installed in another machine, it is fully possible to extract data from the disk. NT, by default will not allow you to read an NTFS disk made in another system. However, there are other means of accessing the information. The fact that other systems cannot easily read the data should be seen merely as a deterrent, not a means of protection. Unlike most other operating systems that support the concept of ownership of objects, ownership of objects in Windows NT cannot be given away—it can only be taken. What does this mean? It means that each file and directory on an NTFS volume has an owner. By default the owner of a file or directory is the person who created it. By stating that ownership of objects cannot be given away means that even if you want to give someone else ownership of a file, you cannot—even if you are the administrator. What you can do, however, is give a particular person Full Control on the file, and then that person can voluntarily take ownership of the object. For instance, I log onto my NT system using a non-administrative account, jgarms. I then create a file called MYTEXT.TXT. Naturally, this file is owned by my account jgarms. This can be confirmed by right-clicking on the file in the Explorer, choosing the Security tab, and clicking on the Ownership button. Now, let's say that I want to give ownership of this file to jsmith. There is no mechanism in NT that will enable me to assign ownership of this file to jsmith. Even if I logged in as the administrator, I would be unable to assign ownership of that file to jsmith. This is by design. What I can do, however, is allow jsmith to take ownership of the file. Although nobody can forcibly assign ownership of an object in Windows NT, the owner of the object, in this case a file, can grant someone permission to take ownership of it. So, although I cannot give jsmith ownership of the file, I can allow him to take ownership by granting his user account Full Control of the file. Once I've given him Full Control rights to the file, he can choose to take ownership of the object. Remember, if you create an object, you are the owner. If you copy a file, you become the owner of the copy. Additionally, ownership is not inherited from the directory into which you copied the file. The access rights are inherited, but you will be the owner. This is an important concept because it is closely related to NT's security structure and concept of accountability. When using NTFS, the owner of an object has the ability to remove rights from it so that no one else can access it, even the system administrator. However, if a user removes all access permissions from a file, the administrator can elect to take ownership of the file. This is an administrative right. Once the administrator has ownership of the file, the access permissions can be changed appropriately. However, the ownership of the file cannot be returned to the original owner. This creates a trail of accountability. For those of you familiar with UNIX, this idea of not being able to give ownership of a file might seem a little odd. In UNIX, you can simply use the CHOWN command and assign ownership of a file to anyone you want—given adequate privileges. However, as you've seen, it doesn't quite work that way in NT. However, you can get a CHOWN command for NT, but don't expect it to work the way you might expect it. CHOWN.EXE comes with the Windows NT Resource Kit and runs in the POSIX subsystem. While this command can be used to check the ownership of a file, and even to take ownership of a file, if you have the appropriate permissions, it cannot be used to grant ownership to a specific user, as it can be used in UNIX.
Securing Your %SystemRoot%Among the files and directories to be protected are those that comprise the operating system software itself. Microsoft has changed the default security permissions in NT 4.0 and the standard set of permissions on system files and directories provide a reasonable degree of security without interfering with the computer's usability. However, you might want to make the following changes immediately after Windows NT is installed. Be careful not to apply these permissions to subdirectories. %SystemRoot% Administrators: Full Control (All)
%SystemRoot%\FONTS Administrators: Full Control (All)
%SystemRoot%\HELP Administrators: Full Control (All)
%SystemRoot%\INF Administrators: Full Control (All)
%SystemRoot%\PROFILES Administrators: Full Control (All)
%SystemRoot%\REPAIR Administrators: Full Control (All)
%SystemRoot%\SYSTEM Administrators: Full Control (All)
%SystemRoot%\SYSTEM32 Administrators: Full Control (All)
%SystemRoot%\SYSTEM32\DHCP If you're not running a DHCP server on this system, you should delete this directory. %SystemRoot%\SYSTEM32\LOGFILES Administrators: Full Control (All)
%SystemRoot%\SYSTEM32\OS2 If you don't run any OS/2 programs you should delete this directory. %SystemRoot%\SYSTEM32\RAS If you don't use RAS, you should delete this directory. If you do use RAS, you should restrict this directory to the RAS users. %SystemRoot%\SYSTEM32\VIEWERS Administrators: Full Control (All)
%SystemRoot%\SYSTEM32\WINS If you're not running a WINS server, delete this directory Additionally, on Intel-based systems you should modify the access permissions on the following system files: \BOOT.INI Administrators: Full Control (All)
\NTDETECT.COM Administrators: Full Control (All)
\NTLDR Administrators: Full Control (All)
\AUTOEXEC.BAT Administrators: Full Control (All)
\CONFIG.SYS Administrators: Full Control (All)
The \BOOT.INI and the \NTDETECT.COM are hidden files. To use the NT Explorer to change permissions on these files, you will need to open an Explorer window and choose the Options item under the View menu. Then choose the View tab and select the Show all files button. Now that you can see them, you can make changes to their permissions settings. Moving Versus CopyingBe careful to set the permissions properly when you move files. Remember that when you move a file, it keeps its permissions, whereas when you copy a file, it inherits the permissions from its destination directory. When copying or moving sensitive information, you should always verify the access control lists (ACLs) after copying the files. SCOPYThe Windows NT Resource Kit provides a utility called SCOPY, which is intended to enable you to copy files and preserve their permissions. SCOPY only works when you copy files from an NTFS volume to an NTFS volume. It will not work with FAT or HPFS partitions, because these other file systems do not support security settings. Additionally, SCOPY requires that you have backup and restore user rights on both the source and destination computers. The SCOPY command is just an example of how user rights can be used to circumvent security features. You need to make sure that you only give the backup and restore rights to users who really need it. Furthermore, because NT does not audit the use of backup and restore user rights by default, tracking the usage of the SCOPY command is difficult. For more information on how to force NT to track the use of backup and restore user rights, see the section "Auditing Backup and Restore Rights," later in this chapter. The only other way to track usage of the SCOPY command is to track access to files about which you are concerned. For example, if you wanted to secure E:\CLASSIFIED, you could audit all read access to the directory by administrative users. Then if an administrator were to use SCOPY to copy files from the directory, it would show up in the security event, as shown in Figure 25.11. A read audit generated by SCOPY indicates that the file was accessed using the Backup user right.
The syntax for the SCOPY command is SCOPY source destination [/o] [/a] [/s] /o copies the owner information. /a copies the auditing information. This option requires you to have the Manage Auditing user right on the source and destination computers. /s specifies that all files and subdirectories should be copied. Note: Parameters must be entered in the order listed.
File Delete Child PermissionTo provide POSIX compliance, Windows NT supports a hidden permission called the File Delete Child (FDC) permission on NTFS volumes. Users who have the full control permission to a directory also have the FDC permission. Having FDC permission enables a user to delete files that are located at the root level below a directory, even when he or she has no permissions on the file itself. The FDC permission only gives a user the ability to delete files at the root level of a directory to which he or she has full control. It does not grant them the right to delete a subdirectory, or delete files that are nested within a subdirectory. The FDC permission is useful because it's based on the concept that if you own a directory, you should be able to remove files that reside in it, even if they don't belong to you. For most people, the FDC permission is not a big deal. It was really only included to provide an equivalent of the UNIX directory write permission for the POSIX subsystem. In UNIX, if a user has write permission to a directory, he or she can delete any file in the directory, regardless of the ownership or assigned rights of that particular file. If you don't want to grant the FDC permission to a user, you need to avoid granting full control to the directory. Instead, you can use the special permissions option and assign all permissions except full control. To illustrate the use of the FDC permission, let's look at the default installation of Windows NT. When NT is installed, most of the files in C:\WINNT (or whatever your particular %systemroot% directory is) are given the following permissions: Administrators: Full Control (All)
However, the actual directory C:\WINNT is given Everyone: Full Control (All)(All) The problem is that since everyone has full control of this directory, anyone can delete any file that resides directly inside C:\WINNT folder. An example would be the file C:\WINNT\WINHLP32.EXE, which has the default permissions: Administrators: Full Control (All)
From the looks of things, only a member of the Administrators group, the Server Operators group, or the SYSTEM account itself would be able to delete C:\WINNT\WINHLP32.EXE. However, because of the FDC right, anyone can in fact delete this file. If you have the Guest account enabled, even the Guest could delete this file. This is why it is important to understand how the FDC right works and the consequences of giving someone Full Control access to directories. Share-Level ProtectionWhen you create a share, it will default to granting Everyone full control to any file and directory accessed through the share. Remember, this is just a filtering mechanism. If you are using NTFS file- and directory-level permissions, the share-level permissions cannot give you more permissions than granted by the NTFS permissions. It can only reduce the level of permission. It does provide you, however, with a simple mechanism to help protect your system if the NTFS permissions are improperly set. Here are a few points to remember:
Hidden Shares Are Not Sufficient Protection In ThemselvesWhen you browse a Microsoft network, shares that end in a $ are not displayed. This is a useful feature because it enables you to hide administrative shares so they don't clutter the browse list. However, you can usually use the Net Watch program to view the hidden shares on most NT computers. Additionally, anyone can still connect to a hidden share if they know it exists.
Logon Script SharesWindows NT Server domain controllers automatically create an administrative share called NETLOGON that is used to store a users' logon scripts. By default this share allows everyone read-only permissions. To provide an additional level of security you should take the following two steps:
For more information about configuring the logon service and creating login scripts, please refer to Chapter 9, Working with Clients. ServicesWhen you are looking at the security of an NT system, it is also important to look at the services that run under Windows NT. One of the places where Windows NT differs greatly from Windows 3.x and Windows 95 is that different processes can run on the system simultaneously as different user accounts. You learned this earlier in this chapter as being part of Windows NT's multiuser nature. Because these processes usually run as a user account that is different from the logged-on user, it is important to understand what services are running on a system, what user accounts they run as, and how they interact with the rest of the system.
Win32 ServicesBy default most services under Windows NT run in the context of the local SYSTEM account, as shown in Figure 25.12. Most Windows NT services run using the SYSTEM account.
This gives these services special permission to certain parts of the system. Some services, such as the Alerter, Computer Browser, and Event Log, cannot be made to run in anything except the SYSTEM account. If you try to configure the service from Control Panel/Services, the Log On As section is grayed out. Other services, like the Clipguide Server, Directory Replicator, and Schedule services, can be configured to logon using an assigned user context. For most environments the default way Windows NT configures most services is sufficient. However, there are certain processes that should not be run using the SYSTEM context because of the possibility of someone hijacking the process and making it do things it is not supposed to be doing. You can go about assigning user contexts to these services using one of two methods. First you could create a single nonprivileged user account to configure all of your services to run under. Or, you could create one user account for each service. As we've already discussed, Windows NT can handle almost any number of accounts that you want to create, so there is no reason why you should not create an account for each service. This enables you to grant each service's account only the permissions necessary to do its job. The following are services you might want to consider running with a limited user account:
Replicator ServiceThe Replicator service needs to be run in the context of a user more for practical reasons than for security reasons. The default SYSTEM account is prevented from accessing the network, so by creating a special user for this service, it can do its job. Scheduler ServiceOnly members of the Administrators group can submit jobs to the Scheduler service. It is important that you create a limited user context for this service to run in. Because it's the specific job of the Scheduler service to spawn other programs, you need to ensure that programs that are run by the Scheduler service are secure. Imagine scheduling your daily backups by using a batch file that calls the NT Backup program. If someone were to replace that batch file with something else, the Trojan program would be run with a privileged account. The severity of damage that could be done using this method is limitless. To help reduce this risk, assign the Scheduler service to run as a user other than the SYSTEM account. Assign this user the minimum rights it needs to get the job done. The exact limit of these rights will depend on the needs of your individual environment. Additionally, when calling programs from the Scheduler service, ensure that any files you call are safe and that no one could tamper with or replace them. Also, be sure to use fully qualified path names when calling programs from within a batch file that is run from the Scheduler service. Third-Party Apps that Run as a Service on NTYou should always be careful when installing any program that runs as a service on your NT server. By creating a user account to control the service, you can help to protect yourself from malicious Trojan-horse-style programs. Additionally, you can reduce the impact of potentially serious bugs caused by poor programming. If there is a bug in the service and it is running as the SYSTEM user, it could have serious consequences. However, if it only had limited system access, the risk is lessened. To illustrate this point, there was a major software vendor that made its name in the Novell world. A few months ago it introduced its best-selling backup software to the NT market, but a critical bug was found. The backup software installed itself as a service and created a privileged user account with which to run the service. The mistake that was made—and hopefully this is one that was popularized enough that other software vendors have learned from it—was that the password for this user account was static and easily determined. This meant that virtually anyone could access your system using this privileged account. In all fairness, the software vendor quickly produced a patch to fix this problem. But this is a perfect illustration of why it is important to understand what services are installed on your system and what rights their associated user account have.
Internet Information ServerOne of the major new features in Windows NT Server 4.0 is the inclusion of version 2.0 of the Internet Information Server (IIS). IIS enables you to publish content to the Internet—or to your intranet—through an FTP service, a gopher service, and a WWW (HTTP) service. Although this increased functionality can help to increase the usefulness of your NT Server, it can also have severe negative impacts on the security of your server. IUSR_computername AccountWhen you install IIS, it creates an account called IUSR_computername, where computername is the name of the computer (for example, on my system it is called PRIMUS; the user is called IUSR_PRIMUS). This account is created with a randomly generated password and is intended to be used for guest access by the IIS FTP server, gopher server, and WWW server. You should understand which permissions are given to this account by default, and how that might affect your security equation. The IUSR_computername account is given membership in the Domain Users and local Guests groups. Additionally, the account is given permission to log on locally. That means that if you are installing IIS on a domain controller, the IUSR_computername account will be able to log on locally to all domain controllers. Because the password is generated randomly when IIS is installed, this probably won't be a concern. However, to make you feel even more comfortable, you might even want to change the password in the User Manager. If you do this, don't forget to tell IIS about the changes by using the Internet Services Manager.
FTP Publishing ServiceThis section discuses the general security-related issues surrounding the file transfer protocol (FTP). The FTP server service that shipped with NT 3.5x was difficult to set up properly, and many people ended up compromising the security of their systems without realizing it. However, the new FTP server included with NT 4.0 as part of the Internet Information Server (IIS) has made dramatic improvements that enable it to be configured in a more secure manner with relative ease.
When you install the IIS FTP service, the default is to only allow anonymous connections. Even though to some people this might seem to be a security problem, in fact it is not. Because the FTP service integrates with the NT user database, you could easily enable users to log on with their standard NT user name and password. However, the FTP transport mechanism itself is not secure because it sends passwords in clear text over the network. As you've already learned, this is a problem because clear-text passwords can be easily intercepted and viewed without your knowledge. The only real use for FTP service where it won't compromise security is as an anonymous file repository. This way users can come to the FTP site and log on using the name anonymous, enter any password, and the system will allow them access. With the IIS FTP service, when a user logs on using the name anonymous, they are really authenticated using the account specified in the FTP setup portion of the Internet Service Manager, as shown in Figure 25.13. "Anonymous" FTP users are really authenticated using the user account and password entered in the Internet Service Manager.
If you uncheck either the Allow Anonymous Connections or the Allow only anonymous connections buttons, NT will warn you that what you are doing will compromise the security of the system. This error message is shown in Figure 25.14. The FTP server service warns you that FTP sends passwords in clear text across the network, allowing them to be captured by a packet analyzer.
Do not take this message lightly. If anything it's understated. It is intended to scare you into thinking about what you are doing, and to prevent people from complaining that Microsoft didn't adequately warn the users about the security risks of FTP. WWW Publishing ServiceThere are two major security issues you should be aware of when you run the IIS WWW server on your system. The first has to do with permitting clear text authentication, and the second is the method that IIS uses to provide user-level discretionary control over documents it provides through the WWW server. By default, IIS uses the IUSR_computername account for processing WWW requests. The WWW service is restricted as to what files on the system it is able to access. Normally this restriction is limited to the WWWROOT directory created when you installed IIS, and to any subdirectories. If this directory structure is located on an NTFS partition, you can deny the IUSR_computername rights to access any files you want. Then, if a user tries to access the file using a WWW browser, they will be required to enter a user name and password for authentication. The problem is that unless you're using Secure Sockets Layer (SSL), WWW browsers send their passwords across the network in clear text, much like FTP clients. These passwords can be intercepted. So by default, IIS does not accept the standard user authentication methods from WWW browsers. However, it does support client authentication using the Windows NT Challenge/Response authentication, which encrypts the user's password before sending across the network.
This means that if you want to provide secure authentication of WWW clients without SSL, you should use only WWW clients that use the NT Challenge/Response authentication. If choose to permit Basic authentication using the Internet Service Manager, you will be warned that this could compromise the security of your system, as shown in Figure 25.15. If you enable Basic authentication, passwords will be sent in clear text across the network.
The second problem with IIS's WWW server is how it handles user-level authentication. As we already touched on when talking about the IUSR_computername account, IIS requires users who will access WWW pages with user-level access restriction to have the Log on Locally user right. When you install IIS, the IUSR_computername account is given this permission, which is not a problem because the password is unknown. However, if you need to begin using IIS to restrict access to WWW pages for different users, then you need to give all those users rights to log on locally to you NT Server. This can be of particular concern because as we've already discussed you shouldn't allow people to log on to your NT Servers. The only suggestion here is that if you must give user-level access permissions for people, then make sure your NT Server is physically locked away where no one can gain access to it. Hopefully, Microsoft will get enough people complaining about this that it will change its authentication method in the next version of IIS. This is really a plain and simple design flaw. The DomainThe domain structure used by Windows NT provides considerably more than a simple method of logically grouping together resources, like its workgroup counterpart. It also provides the foundation for a robust and secure networking environment. The domain contains a user account database that can be used across all resources in the domain. Additionally, the domain provides a guaranteed trust relationship, not only with other domains, but also among NT systems within the domain. This trust permits one NT machine to validate the identity of another computer system, instead of simply identifying the identity of the user on that system, which is all that is permitted with Windows 3.x and Windows 95 systems. Joining a DomainUnlike Windows 3.x, Windows 95, and Macintosh computers, Windows NT Workstations and NT Servers configured as member servers have the option of participating in security structure of the Windows NT domain itself. This is done by having the NT Workstation or NT Server join the domain. However, before they can join a domain, a workstation trust account must be created in the domain. This can only be done by a member of the Administrators group. This account is used to perform pass-through authentication for users who logon to the system. You can use the Server Manager to create a machine account for an NT system and you designate if the system will be a workstation/server, or a backup domain controller (BDC). When you create the computer account, no password is initially assigned. When you bring an NT system to life and assign it the name of the account you just created, it will negotiate a "password" with the domain controller. This password is used to create a secure channel between the NT system and the domain controller, as well as to authenticate the system itself so that it cannot be impersonated. The NT system will regularly negotiate new passwords with the domain controller. Because of this, it is essentially impossible for another computer to impersonate an NT system once it has joined a domain.
There is a security concern created whenever you create a computer account and then don't use it immediately. Someone could use that abandoned computer account to join your domain. Worse yet would be if you had created a domain controller account and forgot about it. This means that someone could bring an NT Server to life and join your domain as a BDC, thus obtaining a copy of your user database and other potentially damaging information. For this reason, you should never create unused computer accounts. Furthermore, you should use Server Manager to periodically review your computer accounts and delete any old accounts that are no longer necessary. Domain Trust RelationshipsOne of the greatest misconceptions about domain trusts is that by establishing the trust, you have given away some level of administrative rights. In fact, this is not true. Creating a trust between domains merely provides a guaranteed path between the PDCs of each domain that allow the trusted domain to certify a user's credentials to the trusting domain. When you create a trust between two domains, there is no immediate change in administrative privileges. An action such as this must be explicitly done by the administrators of each domain. TCP/IP FilteringOne of the new features of Windows NT 4.0 is its capability to use TCP/IP to set up security filtering at the protocol level. This permits you to grant and deny services based on either the TCP or UDP port numbers. This provides an effective packet filter somewhat similar to simple firewall systems. This functionality is particularly useful if your server will be serving limited functionality on the Internet. For example, if you have a server with a network interface card that is connected to the Internet and you only want it to be able to act as a web server, you could enable the appropriate port addresses. Or if you have a SQL database that you want people to access, you could include only the port addresses for the database.
You can modify this setting on an interface-by-interface basis, and it is done through Network Control Panel. After you open the Network Control Panel, select the Protocols tab and double-click on TCP/IP Protocol. This brings up the Microsoft TCP/IP Protocol Properties page. Click on the Advanced button, and then click on the check box Enable Security. Finally, click on the Configure button to configure the ports you want to filter. The TCP/IP Security window is shown in Figure 25.16. You can select what TCP or UDP port addresses or IP protocols you want to permit your system to listen to.
You will have to restart your system in order for these changes to take effect. Well-Known PortsThe following is a list of the more well-known port addresses in an NT environment. Because the port filtering feature in Windows NT only permits you to include ports on a port-by-port basis, instead of permitting you to deny them on a port-by-port basis, you must be aware of these well-known ports before you enable port filtering.
Remote Access ServiceThe remote access service provides a powerful tool for creating multiprotocol, dial-up and virtual WAN connections. However, this utility comes with a potentially hefty security cost. If you are going to implement a RAS server on your network, it is important to understand the security implications and how to protect your network from outside attack. This section covers some of the RAS server settings that affect your network's security. The RAS server is discussed in more depth in Chapter 20, Implementing the Remote Access Service. When you install the server portion of the Remote Access Service, you are prompted with some options that will affect the security of your RAS server. Those options are shown in Figure 25.17. When you set up the Remote Access Service server, you can specify different options that will impact the security of your system. Password EncryptionThe RAS Server in Windows NT supports three types of password authentication for dial-in clients. The first, "Allow any authentication including clear text," is intended to support any third-party dial-in clients that employ the Password Authentication Protocol (PAP) method of authentication. With PAP, the passwords are exchanged in clear text and can be easily captured. This is considered the least secure authentication method. Regardless of which option is selected, Microsoft clients will always negotiate the most secure password-negotiation method supported by both client and server. Selecting the "Require encrypted authentication" provides support for more secure password authentication methods including SPAP, DES, CHAP, and MS-CHAP. Shiva Password Authentication Protocol (SPAP) uses two-way encryption to ensure password security when communicating with a Shiva LAN Rover client. DES encryption for password authentication is supported on the RAS server to maintain backward compatibility with older Microsoft clients, such as the Windows for Workgroups RAS client. The Challenge-Handshake Authentication Protocol (CHAP) uses a challenge with one-way encryption on the response for secure authentication. One of the features that makes CHAP secure is the capability to periodically verify the identity of the client by issuing a challenge, which changes every time. If the client does not respond properly to the challenge, the server disconnects. An additional feature of CHAP is the ability to use different encryption algorithms. MS-CHAP is Microsoft's variation of CHAP, which implements RSA Data Security Incorporated's MD4 encryption standard to provide the highest level of password authentication on NT's RAS server. The only clients that currently support the MS-CHAP authentication method are the Windows NT and the Windows NT RAS clients. These two systems will always use MS-CHAP when negotiating passwords with each other. RSA's MD5-CHAP encryption method is one of the most popular authentication protocols supported by most third-party PPP clients and servers. It is supported by Windows NT's RAS client, but the Windows NT RAS server will not negotiate using MD5-CHAP. MD5 is considered to be a strong encryption method, but it requires passwords to be stored on the server in clear text, which Windows NT does not permit. The option "Require Microsoft encryption authentication" will only authenticate users with MS-CHAP. Data EncryptionTo help ensure the security of your data when transmitted over public carriers such as the standard phone systems and X.25 networks, Microsoft has provided the capability to encrypt the data stream. If you use MS-CHAP, you will also have the option to require data encryption. This option will be grayed out unless the "Require Microsoft encryption authentication" option is selected. When this option is selected, RSA's RC4 encryption algorithm is used to secure all data sent over the RAS line. This implementation uses a 40-bit key that is negotiated at call setup. RAS Dialin PermissionsWhen you install the RAS server on Windows NT you must still assign the right for users to dial in on an individual basis. This can be done using the User Manager or the Remote Access Admin program. Using the User Manager to configure a user's ability to dial into a RAS server is new to NT 4.0. In prior versions you had to use the Remote Access Admin. In the User Manager, the Dialin option appears as a tab on the properties page for each user. When you select this tab, you can set the user's ability to dial in and be authenticated by this domain. You can also set the user's call-back options, as shown in Figure 25.18. The User Manager can be used to permit users to dial in using the Remote Access Service.
You can use the RASUSERS utility from the Windows NT Resource Kit to obtain a list of all users who have been authorized to dial in with RAS. You should check this list regularly to ensure that you know who is able to dial in to your system. Call-Back FeatureI suggest you consider using the call-back feature to provide added security. For most users who dial in from home, it should not be a problem to preset RAS to call them back at their home phone number. This makes it almost impossible for someone to impersonate other users. You should definitely implement the call-back feature if you need a more secure means for authenticating a user. Restricting Network AccessIf you have decided to grant users Dialin access, RAS permits you to limit the extent of their access. You can specify that users can connect to the entire network, or if you want to provide higher security, you could limit their access to only the RAS server. You do this when you configure the RAS service setup in the Network Control Panel. You can specify the level of restrictions as shown in Figure 25.19. When you set up the RAS server, you can specify that dial-in users can only access resources on the RAS server, but not on the rest of the network.
Unless your dial-in users specifically need access to network resources, you should limit their access to the local machine in order to reduce the consequences if there is a security breach. Third-Party Security HostsMicrosoft designed an open interface into Windows NT Server's RAS service that enables you to integrate a third-party security host. The capability to seamlessly integrate with additional security hosts enables you to enhance the security of your dial-in connection. The security host is a device that provides an additional level of authentication before allowing the user access to the RAS server. When using these security hosts, authentication is provided by a hardware key in the possession of the user. Without the code generated by this key, the user will not be authenticated by the security host and cannot gain access to the RAS server. Windows NT currently supports a number of external security hosts. The cost of installing a third-party security host is fairly expensive, so unless a high degree of security is a must they are probably unnecessary.. As mentioned previously, the call-back feature provides a level of protection that should defeat most intruders. However, the third-party security hosts provide the added benefit that they don't require the user to dial in from a pre-set location. Using the Point-to-Point Tunneling Protocol for Increased SecurityWindows NT 4.0 introduces a new feature called Point-to-Point Tunneling Protocol (PPTP). PPTP is an extension of RAS that permits the creation of virtual private networks (VPNs). There are two major areas where PPTP can dramatically improve your security. The first scenario would be if you need to communicate with another site across the Internet. You could use PPTP to set up an encrypted tunnel across the Internet, which can guarantee the privacy of all data. The second scenario would be if you dialed into your corporate network through an independent Internet service provider (ISP). You could use PPTP to guarantee the security of your data between your dial-up location and your NT network. The PPTP VPN uses RAS's built-in bulk data encryption method to ensure privacy of the VPN channel. This is based on RSA Data Security Inc.'s RC4 algorithm with a 40-bit key. The key is negotiated when the VPN connection is established. PPTP makes secure network communication across the Internet possible. The RegistryProtecting the Registry is a very important step to creating a secure system. Because the Registry contains the control parameters for the entire Windows NT system, gaining control of the Registry would essentially allow a hacker free run of the entire system.
Protecting the RegistryThe Registry, like everything else in Windows NT, is a set of files that makes up a hierarchical database. These files are stored in the system root area. The Registry does not need to be installed on an NTFS partition to enable you to set permissions and auditing on individual keys. However, if the system root is not on an NTFS partition, anyone with access to the Registry hives, located in C:\WINNT\SYSTEM32\CONFIG, has the ability to directly read and modify the hives. For this reason, you should always ensure that the system root is located on an NTFS volume. Sensitive Information in the RegistryWhen determining your need to secure the Registry, you should consider the sensitivity of the information stored in the Registry. Remember, by default any user that can access the system, locally or remotely, has access to read large parts of the Registry. Unfortunately, securing the Registry is something more of an art than a science. You need to be especially careful when making changes to the Registry because various programs need access to read data from certain keys in the Registry, and blindly modifying the permissions on the hives would almost certainly cause unidentifiable problems with your system. The flip side is that the Registry provides a wealth of information to which most users do not need access. The Registry permissions are set, by default, to prevent unauthorized users from changing things that should not be changed. However, they make no real attempt to prevent users from seeing information that they really have no business seeing. For instance Everyone has read permissions to the entire HKEY_LOCAL_MACHINE\HARDWARE hive. This enables anyone to gain access to the complete hardware inventory of the NT machine. They can find out what kind and how many processors, how much RAM, what kind of network cards, what type of drive controllers, the make and model of all storage devices, and the type of video card. Additionally, the SOFTWARE and SYSTEM hives show the same lack of read security. From these hives a user can discover how the networking is configured on the server, including the protocols and bindings, what services are running and how they are configured, and a wealth of other information. This is the kind of information that can be used to discover and take advantage of security flaws in a system's configuration. Unfortunately, securing this problem with the Registry is not very easy. Often, various software and services need access to this information and thus, changing the access can cause unpredictable results. If access to this information concerns you, you should carefully consider removing Everyone/read access from some of these hives. As of yet, Microsoft has provided very little information as to how to properly secure these keys. The following is a method I use to secure keys that concern me. In the Registry Editor, enable full auditing for a select hive area, for instance HKEY_LOCAL_MACHINE\HARDWARE, as shown in Figure 25.20. You can use Windows NT's auditing facility to determine who, or what, is accessing specific Registry keys.
For the auditing to take effect, you must use User Manager to ensure that the File and Object audit events are turned on in the system's Audit Policy. You can use the Event Viewer to monitor the Security Log and discover who or what is accessing the keys and decide what level of permission you need to assign them. If you choose to use this method, you need to make sure that the Security Log is large enough and you should definitely disable the CrashOnAuditFail feature discussed later in this chapter. A slightly more risky, but thorough approach would be to restrict Everyone/read access on keys that concern you and then enable auditing on failure to access these keys. This is certainly a more thorough approach than the method mentioned previously, but is not as safe. Restricting access to certain keys can potentially cause processes to crash when they are not able to access them. If you use this method, you should keep a very close watch on the Security Log. Securing the RegistryIf Registry security is of concern to you, there are a couple changes you can safely make that will increase the overall security of the Registry.. You could change the following keys so that Everyone has only Query Value, Read Control, Enumerate Subkeys and Notify access. HKEY_LOCAL_MACHINE\Software\Microsoft\RPC HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion HKEY_LOCAL_MACHINE\SOFTWARE\Windows 3.1 Migration Status HKEY_CLASSES_ROOT When changing the access lists on these keys, be sure to note the permissions on any subkeys so that you don't propagate the wrong permissions. In particular, be careful with the permissions on the keys under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion. PrintersBy default, shared printers created with Windows NT Server are available to any user on the network. Although the capability to print to a printer does not pose a direct security problem, it does create the possibility that someone can flood the queue and deny legitimate users access to the printer. Additionally, unauthorized printer abuse can cost you money. To help curb these problems you should consider adjusting the default printer permissions. Printer PermissionsIn order to create or modify a printer, you must be a member of the Administrators, Server Operators, or Print Operators local group. You can use the Printer Manager to adjust the permission on each printer. The default printer permissions are shown in Figure 25.21. By default, everyone can print to a shared printer.
You should remove the entry for Everyone and replace it with whatever appropriate group of users need to be able to print to your printer. For more on setting printer permissions, see Chapter 9, Configuring and Installing Print Services. TCP/IP PrintersIf you are connected to a large network, especially the Internet, you should carefully consider what protocols you use to print to your printers. If your printer is connected directly to the network, rather than directly to your server, you should consider not using TCP/IP to print to it. The common method of printing across TCP/IP is to use the Berkeley-style print daemons, LPR and LPD, as defined in RFC 1179. LPR/LPD do not support user-level authentication and therefore will accept print jobs from anyone. Thus, if you're connected to the Internet, anyone who knows the IP address of your printer could submit a print job. Of course you can always implement router-level filtering and some LPD implementation built into printers support a rudimentary level of filtering. Rather than going through all the trouble to implement filtering mechanisms, it might be much easier to disable the TCP/IP features of your networked printer and use a nonrouted protocol to talk to your printer. There are other reasons for using protocols such as DLC or AppleTalk rather than TCP/IP for the connection between your NT server and networked printer. For a more in-depth discussion on this topic, please refer to Chapter 9, Configuring and Installing Print Services, and Chapter 16, Configuring TCP/IP Printing. Auditing PrintersIf you are concerned about keeping track of who is printing to your printers, you should use Print Manager to setup printer auditing. In order to enable auditing of printers, you must first use the User Manager for Domains to enable auditing. See Chapter 15, Administering the Server, and Chapter 24, Auditing Windows NT Server, for more details on using the User Manger for Domains to change the system auditing policy. Macintosh ClientsBy default, any Macintosh user can print to any printer regardless of the permissions set on the individual printer. This is because the Macintosh print client has no support for user-level authentication. The Macintosh print service on Windows NT Server is set by default to log on using the SYSTEM account and therefore has access to all local print devices. It is not possible to grant print privileges to Macintosh clients on a user-by-user basis. It is possible, however, to restrict print privileges to Macintosh users as a whole. To do this, follow these steps:
BackupsNow we get back to the fundamental question: How important is your data? No matter how we answer this question, I think it really boils down to this: no matter how unimportant it is, you'd hate to have to do it over again. I think that most administrators would agree that backups are important, but very few organizations take appropriate care to ensure the security of their backup tapes. No matter what protection was assigned to your files and directories, the tape can be taken to a different system and restored without any controls. It is extremely good practice to carefully inventory your media and keep it under lock and key. Backup Tapes are Not EncryptedNT Backup does not encrypt the data when it writes it to tape. For that matter, I don't know of any tape backup software for NT that offers an encryption option. Just realize what this means—anyone with an NT system and a tape device like yours can read your tapes and any confidential information on them. I've had numerous people argue about the usefulness of encrypting backup tapes. I have a couple of problems with this and personally think that encrypting backup tapes is a bad idea. One of the big questions is what would you use as a key for the encryption. Certainly not any system-level data. If you did, what would happen if the system crashed and your needed the backup tapes for restoring your data? If the unique system-level data was no longer available, you'd be out of luck. Likewise, if the user was required to enter a password and this were used as a key, what would happen if that password was lost? It would be terrible if you had a system crash and could not recover the data from tape because the password was lost. Securing Backup TapesRather than encrypt the data, securing the backups under lock and key and keeping copies off site is a more reasonable practice. You should follow a good tape-rotation scheme and keep careful inventory of the tapes. For more information on tape schedules, see Chapter 23, Protecting Windows NT Server. Tapes should not be stored together with the computer system. If the system is stolen or damaged in a fire or other accident, the tapes might go with it. There are numerous organizations that provide off-site data storage services. Usually, for a nominal fee, you can schedule for them to come and pick up tapes on a regular basis for off-site storage. Don't always jump for the cheapest and make sure to check around, because as with any organization, you need assurances that you can trust them with your confidential data. When shopping for such a service, find out in what kind of facility they store your tapes. What security precautions do they take to ensure that your data is safeguarded? Also, in an emergency, how fast will they get your tapes back to you so you can begin cleaning up? Backup OperatorThe backup and restore user right that is granted to the Backup Operators group is one of the most powerful rights in NT. Although NTFS file-level permissions can be used to deny an administrator access to a file or directory, the backup and restore user right can essentially be used to bypass this security. Although a user with this right cannot simply read files, he or she could use this right to back files up to tape, and restore them onto other systems to gain complete access. The problem is that this is not fully auditable. To ensure complete security for these files you must either acknowledge that the person running the backups should have clearance to see all the files contained on the tape, or you must physically separate the backup operator and the tape device. In this scenario, a trusted party would need to be responsible for the tape. I bring this point up only because I've run into a few different environments where people had some very rigid rules regarding the permissions on their files. In one such environment, the administrator was denied access to all user data. This made things extremely frustrating. When I pointed out that if the administrator wanted access to the data, all he would have to do was back it up and restore it somewhere else, they complained that this was unrealistic and should be ignored. I argued that they should either trust their administrator and allow him to do his job, or if they were honestly concerned about security, they should keep the sever and tape backup unit in a locked place and not allow the administrator to have access, except when accompanied by an individual trained to know what to look for. The point here is make policies that make sense. Don't go half way and stop. If there is a loophole, you should reconsider the policy. Don't bet on the fact that people won't notice the loophole. Remember, only give the backup and restore rights to someone you trust! Allocation of Tape DrivesUnder Windows NT, any user on the system can use the tape device. For this reason, you should not leave tapes containing potentially sensitive data in the tape drive. If you want to stick a tape in the device before a regularly scheduled backup, make sure to erase the tape first. Also, you should have the tape eject as soon as the backup is complete. There is currently no way to restrict access to the device, like there is for the floppy and CD-ROM devices. AuditingAuditing is one of the fundamental security provisions in Windows NT. It enables you as the system administrator to identify what users are doing on your system. If reviewed properly, it is especially useful for identifying potential security breaches or break-in attempts. This section briefly looks at the basic guidelines you should follow for using NT's auditing facilities as a tool for increasing your system's security. For a more in-depth look at auditing, see Chapter 24, Auditing Windows NT Server. Implementing Security-Oriented AuditingBy default, Windows NT does not audit security-related actions. This is because auditing these events requires additional processor time and disk storage. You will need to enable your audit policy through the User Manager for Domains, as shown in Figure 25.22. Security auditing can be enabled with the User Manager.
At a minimum you'll want to audit failed logon attempts. This will help warn you if someone is trying to break into your system. Additionally, you might consider auditing successful logon attempts and looking for user logons during your nonstandard times. For example, if your employees don't typically work at night, auditing successful user logons might tell you if someone, the night maintenance staff for instance, is trying to illegally access your system or perhaps even identify if a user is trying to access unauthorized information and hoping not to get caught by doing this during off hours. You should also consider enabling auditing of "Use of User Rights," "User and Group Management," and "Security and Policy Changes." By having NT audit failures on these settings, you can see what people are trying to do on your system. It's natural for people to play around sometimes. Most people are inquisitive and will occasionally attempt to do something they shouldn't be doing. Other times, people do things without realizing what's happening. Auditing failures enable you to identify people in your organization that might need watching, or might just need help. Of course it will also identify major problems, such as attempted attacks. For more detail information on each of these option, please see Chapter 24, Auditing Windows NT Server. By auditing success on these items, you also provide a record of your actions that could prove useful later. Audit logs help to identify problems, but they also provide a true account of what really happened on the system. I once had a user accuse me of changing the permissions on a confidential file of his. The audit logs backed up my claim that I did no such thing. In fact, we were auditing all file and object access and were able to show that he had in fact created the file in a different directory, whose rights mask it inherited, and then moved it to a secure directory. He insisted that he had checked the rights on the file and that it was secure. However, the audit trail doesn't know how to lie. Unless you have a specific need, or if security is of the utmost concern, its not necessary to enable "Process Tracking." On a busy system this consumes a considerable amount of resources. Also, auditing unnecessary actions means there is less room in the security log for more important actions, which means that critical event might get removed from the security log faster than necessary. Auditing File AccessIn terms of security, it can be very useful to know who is trying to access certain files or directories. With Windows NT, you can choose to audit files and directories on a one-by-one basis. In order to implement this, you must enable the "File and Object Access" in the audit policy located in User Manager for Domains. If you don't enable the audit policy here, choosing to audit a file or directory from the NT Explorer or File Manager will have no effect. What kind of files and directories might you want to audit? Imagine that you have a directory, E:\CLASSIFIED, and you want to restrict access to it. Of course it's important to apply the appropriate file- or directory-level security measures under NTFS. But with auditing, you can see when and what people are doing to these files. For instance, if the E:\CLASSIFIED directory is restricted to a very limited number of users. By auditing the access to the directory, you can know what users are doing to files in this directory. This is also a good way to keep administrators clean and ensure that sensitive information is not being accessed without proper authorization. If you have enabled File and Object Access auditing in the User Manager for Domains, you can use the NT Explorer or the File Manager to select which files you want audited. For each file or directory, you can select which actions you want audited for which users. For example, you could set up auditing on the directory E:\CLASSIFIED such that all access failures are audited for everyone, but successful Change Permissions and Take Ownership events are audited for the only members of the Administrators group, as shown in Figures 25.23 and 25.24. All access failures are audited on E:\CLASSIFIED.
Successful Change Permissions and Take Ownership events are audited for the Administrators group. Security LogWhen you implement a security policy as described previously, the audited events will appear in the Security Log, which is accessed by using the Event Viewer, shown in Figure 25.25. You can access the Security Log from the Event Viewer application..
By default, the security event log is only viewable by members of the local Administrators group. You can enable other users to view and clear the security log by granting them the "Manage auditing and security log" user right from User Manager for Domains. As mentioned previously, when you install Windows NT Server, the Administrators local group is automatically granted this right. The ability for members of the local Administrators group to view and clear the security log is inherent in the Windows NT system itself. Even if you remove the "Manage auditing and security log" user right from local Administrators group, they will still be able to view and clear the security log. You should take some time to understand how the security log is organized and what your system's log looks like, so that you can better identify when there is trouble, or you're under attack. You should review this log regularly. For most environments, once a week should be sufficient. You also need to decide how long you want the security log to grow and how often items should be pruned. Ideally, you will review, save and clear the log before it is full. How large the log should be allowed to grow to and how often it should be archived and cleared will depend entirely on what events you're auditing and the amount of use your system receives. The log setting can be set in the Event Viewer, as shown in Figure 25.26. You can set how large the security log is permitted to grow.
By default, the security log is set for a maximum size of 512 KB, but you should definitely increase this amount. A log size of 4,096 KB is typically acceptable for most environments. Rather than making the log larger than this, you might want to consider reviewing and archiving it more often. The amount of log space a security event uses depends on the nature of the event. This means that you can only make good predictions by analyzing your log over time as to how many events it will take to fill it up. For example, it takes approximately 250 failed logon attempts to fill a 64KB log size. To see the current size of the security log, look under C:\WINNT\SYSTEM32\CONFIG\SECEVT.EVT. This is the security event log. You will not be able to open it, because it is open for exclusive use by the system. However, you will be able to check its size. It will always be in multiples of 64KB. By doing this you can check to see if your log is reaching its limit. The security log is set by default to overwrite events older than seven days. For most environments, you should consider changing setting to "Do Not Overwrite Events." By making the log sufficiently large, you will have hopefully ensured that the log will not fill up. Again, you should review, archive, and clear this log regularly. By choosing this option, and properly setting the size of the log, you will most likely capture the more important actions of a hacker who tried to break into your system. If you allow the log to overwrite events, the hacker could simply perform some simple, repetitive action that would fill up your log and wipe out any trace of the damage that was really done. Causing the System to Crash When the Security Log is FullIf you choose either "Overwrite Events Older than x days" or "Do Not Overwrite Events" you can also force your NT Server to crash when the event log is full. I only recommend this in environments where security is of higher concern than the availability of the server. By implementing this feature, you can ensure that no events will go unaudited. If you choose to use this option, be sure to set the size of your security log properly. However, if a hacker tries to generate a series of events in an effort to cover up his or her footsteps, this is a useful feature. In most corporate environments this is really overkill, which is part of why Microsoft didn't provide a simple way to enable it. It is really provided for organizations where the audit logs are vitally important, such as a bank. Although this measure might seem a bit draconian to most people it is the only way to ensure that nothing is accessed without an appropriate audit trail. To enable this feature, you must use the Registry Editor to create the following Registry entry:
Realize that when you implement this feature, the system will literally crash with a blue screen when the security audit log fills up. It will not warn users and gracefully shutdown. This feature will only bring the system down when the security log fills up. The application and system logs have no effect on it. The system treats this crash like any other. If you are using this option to protect the audit log, you should probably consider disabling the reboot on system crash feature. Otherwise the system will automatically reboot. The security auditing is essentially disabled until you make some modifications to the system. When the system crashes, it changes the CrashOnAuditFail value entry to type REG_NONE so that the system can reboot without immediately crashing again. In order to restore a crashed system to a secure state, you must take the following actions.
Policy for Clearing the Security LogNo matter what size you choose for your log, or how often the data gets cleared, you should consider implementing an archive strategy for the old security logs. This is useful because although you might not identify some action as being a problem today, it could be discovered to be a problem in the future. Having those old logs will greatly aid your work. If security is a concern in your organization, you should develop a strict policy dealing with the clearing of those logs. Remember, the security log can also hold information about wrong-doings by the system administrators. Put a statement in your policies and procedures document about when the logs will be archived, when they will be reviewed, how they will be reviewed, who will review them, and for how long they will remain archived. It is also important to make it understood what actions, if any, will be taken for improperly clearing the event logs. Remember this is the security document for your entire system! Archiving the Security LogThe security log contains sensitive information that you don't want other people to have access to. It is very important to make sure that you save the archived security log files in a secure location. Create a directory on your server—under the %SYSTEM_ROOT% is a good location—and secure the directory so that only the administrators have access to it. You might also want to audit access to this directory. When you use the Event Viewer to archive the security log, be sure to save it directly into the directory you created for these archives. This way it will inherit the proper NTFS file-level permissions. Remember if you save the log into some other directory, C:\USERS\DEFAULT for example, the file will inherit its permissions from this directory. When you move it to its archive location, it will retain these permissions. If the Bypass Traverse Checking user right is granted to Everyone (as it is by default) anyone with access to a share that contains that archive directory will be able to access the file! For more on this subject, see the sections on the Bypass Traverse Checking user right, and security considerations when moving files, earlier in this chapter. Auditing Backup and Restore EventsI've heard complaints that although the Windows NT backup program does log its activity, you cannot log the use of the backup and restore user rights. From a security standpoint, this is a potential problem, because it is possible to create a backup program that does not log its events. Without the capability to audit the use of these user rights, you cannot truly secure your system. The problem is when a user backs up files, NT verifies that the user has the Backup Files and Directories user right for every single file. Similarly, when a user restores files, the Restore Files and Directories user right is checked for every single file. Because auditing all these events would quickly flood the Security Log, Windows NT masks these events by default and prevents them from being written to the log. This means that it is merely unfeasible, rather that impossible to audit the backup and restore user rights. If you choose to audit the use of backup and restore user rights, assign the following Registry key value use the Registry Editor:
Unauditable User RightsIf you follow the procedures listed previously and create the FullPrivilegeAuditing key value, you might think that this will actually enable auditing for all user rights. The name of this value, however, is slightly misleading. There are some user rights under Windows NT that cannot be audited, no matter how this key value is set. The following is a list of user rights that Windows NT cannot audit:
Protecting Against Renegade AdministratorsIn many organizations, if someone were to suggest performing an analysis of the damage that a rogue administrator could cause, it would be tantamount to sedition. In some organizations, such as those that fall under certain federal jurisdiction—the banking industry, for example—it is not uncommon for an outsider to be brought in to perform a thorough check of the system to make sure that everything appears to be in order. The decision as to whether or not your company needs to take precautions against treachery from inside, you need to ask yourself the some following questions:
Although it is difficult to impossible to fully protect your system from an administrator with ulterior motives, if your information is of a sensitive nature, you should at least devise a policy for regularly tracking the use of administrative privileges. This can be done using the Windows NT auditing features, discussed in chapter 24, Auditing Windows NT. ConclusionWindows NT Server provides one of the most secure, generally available computing platforms on the market today. The security system is an integral part of Windows NT Server and you can't install NT Server without it. Microsoft has tried to make NT Server as secure as possible by default, but sometimes it has placed ease of use over security. This is why it is imperative that all administrators understand how security works on Windows NT, so they can properly configure NT's security settings to fit their environment. It is, however, such a complex product that it is extremely easy to make changes and not recognize the security-related consequences of your actions. This chapter has not only made you aware of the common, yet not-too-obvious, pitfalls, but also offered you a variety of strategies for ensuring the level of security you really need.
|
