28 - Implementing Real-World Securityby Don Benage
Many organizations underestimate the risks they face and the importance of security. They either have no formal policy or do not enforce the policies they have. There is no regular risk assessment, no audit, no disaster recovery plan. Too often people are assigned an administrator's role on a network just to avoid difficulties with assigning access permissions. Many organizations leasing space in office buildings don't know who has keys to their facilities and what screening, if any, is done when hiring maintenance workers and janitorial staff. This chapter is intended to provide an overview of the field of security, and to recommend an approach that can be used to evaluate your organization's needs and implement a system that meets your requirements. The needs of different organizations vary widely. Perhaps your organization honestly doesn't need much in the way of security, or perhaps you have already implemented an approach that you feel is adequate. The fact remains that most organizations are more vulnerable than they realize. Although the concepts outlined in this chapter may seem like common sense, in the field of security, it seems that common sense isn't very common. Good security doesn't necessarily imply a lot of security. Security is best when it is suitable for the environment and people it is intended to protect. Applying heavy-handed techniques and policies that are too burdensome when they are unwarranted will only cause the members of your organization to resent the measures and work to thwart their effectiveness. This underscores the need for education and training on the topic for all members of the organization. Everyone has an important role in preserving the effectiveness of the security systems you adopt. This chapter does not review specific products, but certain types of products are discussed. Broad coverage is provided rather than in-depth details, for two reasons. First, the details of the systems and products will change, but a sound approach will continue to provide a strong measure of security. Second, it is ineffective to get so focused on the details of one area that another weakness is overlooked. The adage describing a chain as being only as strong as the weakest link is certainly apt when discussing security. Encrypting a report on your hard disk is less effective if the draft copies you printed and discarded are sitting in a trash bag by the elevator waiting to be removed by a janitor.
The next important step is to analyze what you are trying to protect. What assets of your organization are most valuable? An obvious answer is the tangible assets of your organization such as office equipment, furniture, and cash. There are other less obvious answers also. Your information systems contain vital information that is certainly valuable. What is your customer list worth? What about the other information stored on your computers? If you are a consulting organization, your most valuable asset may be the people you employ. Perhaps a list of every employee with their address and phone number might be the target of a competitor or an unscrupulous placement firm. Clearly, you must provide a satisfactory job experience or your employees will leave anyway. But after analysis you may decide that publishing a master list constitutes an unreasonable vulnerability. This is just one example of the kind of exposed position that can be easily overlooked. If identified, steps can be taken to secure these items. Where are you vulnerable? How does a security problem arise and where is it executed? Only analysis of your individual needs can determine the appropriate level of security for your organization. A problem at one organization may not be a concern for another. For example, a small tightly knit group of people may be well served by tight physical security on the premises and little or no security once inside the work environment, even if their security needs are stringent. An entirely different approach is required for environments that require regular access by visitors and part-time employees or full-time contract help. There are many potential areas of concern starting with the keyboards of your computer systems. Computer systems and networks have been designed to provide easy access to information. One of the most intense areas of research and development has been making computers easier to use, and information easier to access and understand. What were once arcane stacks of reports printed on greenbar paper, so difficult to interpret that even people with training could hardly make sense of them, have been replaced with pie charts, presentations, and in-house publications that make detailed information easy to comprehend. This is a laudable goal, but it makes the job of a security system all the more difficult. Most organizations have ineffective network logon security and no local security on their individual systems. The policies for the management of passwords are generally lax or nonexistent. If your organization supports dial-up access to the network, this must receive careful attention because the potential for trouble is great. If part or all of your organization's private network is attached to the Internet, another potential concern exists. A growing threat also comes from the use of network sniffers or protocol analyzers. These once were expensive devices that were inaccessible to the individual without a corporate budget. Now, sophisticated software-only solutions exist, including the Network Monitor provided with Systems Management Server (SMS), a BackOffice component. This type of software can be installed on a computer with a network adapter that can be placed in "promiscuous mode" and virtually all network traffic can be captured and saved to disk for later analysis and reconstruction. A high level of knowledge is required to perform some of these tasks, but that is little cause for complacency. Finally, although the focus of this chapter is on computer-based issues, a comprehensive risk analysis must also include the front door (and the back door) of your facilities. A particularly vulnerable situation arises when an organization leases space in an office building. Frequently, you no longer have control over the distribution of keys to your premises or the people who receive them. Does anyone check to make sure that the janitor who is alone in your office at night isn't a career criminal? Perhaps even more alarming is the threat from the so-called hacker. An average high-school student with strong computer skills, a part-time janitorial position, and an overactive imagination could be an enormous risk. Should you be concerned about this? If you are responsible for security at your organization, you can conduct an interesting experiment. Spend the night in a quiet corner at the office reading a good book. Make random visits to the office at 11:00 p.m. or 2:30 a.m. You may be shocked at what you discover. All too often the front door that is so carefully locked by your employees as they leave for the day is propped open by a janitor's rolling trash can. The janitor is busy in some area of your suite, or even helping out on another floor of the building, and all your equipment and information is there for the taking. Another related and very common problem is created when you provide 24-hour access to your facility for employees and have locked offices for officers or managers in the company. The lock on the manager's door provides a false sense of security and can lead the office inhabitant to leave the inside of the office unsecured, believing that the lock on the door provides protection. The problem occurs when the janitorial crew comes into your suite and unlocks every door to provide easy access for the vacuum cleaner and the person emptying the trash. There may be an hour or more during which the doors are standing wide open, and no one is watching while the crew moves on to the next suite and the supervisor eventually comes through to lock up. The reason that this is all so important is the concept of the weakest link. If your approach to security is not comprehensive, if you are not vigilant in all areas of potential attack, your system will be open to compromise. The sophisticated, high-technology approaches that are available to safeguard electronic information systems are important and frequently appropriate. But don't forget to lock the back door.
A topic that surfaces from time to time in the public media is industrial espionage, and for many organizations this threat should be scrutinized. Unscrupulous organizations and individuals may undertake the task of trying to undermine your organization, steal your assets, or destroy your information systems. Although it may seem like fodder for a spy novel, the threat can be real, and it happens more often than is usually suspected. Perhaps the biggest threat to an organization comes from the inside - the disgruntled employee. Almost every organization employs someone who is unhappy with the situation in which they find themselves and who blames the organization as a whole, or the managerial staff. Theft or destruction of proprietary information may seem like a reasonable way to strike back. This threat is particularly difficult to defend against because the culprits are so difficult to identify, and they come from the ranks of those who must be trusted with access for the organization to be effective. The threat from hackers has been touched upon already but it bears additional discussion. This potential threat is greatest for large organizations. The local telephone company, defense contractors, universities, and large corporate entities have been the traditional targets of the hacker community. The growth of interest in the Internet, however, raises the stakes a bit. Any organization providing Internet access for their network, and dial-up access to that network, has become a potential target for someone desiring free access. A comprehensive plan to provide protection for your assets and information must also include an approach to managing the threat posed by viruses. There are several good references on this topic. The problem and effective approaches to address the problem are well understood. You must also develop a plan to deal with the threat posed by natural disasters such as fire or flooding. These topics are not addressed in this chapter, but are mentioned for completeness. Remember - the weakest link is the important one.
The crux of the dilemma as you seek to balance access and security is this - you can't lock things up so tight that no one can use them. You must strike a balance between access and control. In addition, you must avoid the situation in which the costs associated with your security system, financial and other costs, are greater than the losses you might sustain without a system in place. If you spend more than you would have saved, you have already become a victim. The rest of the chapter outlines some specific types of security measures and techniques that may be useful in implementing a security system.
E-mail security is really a special case combining the elements of network security and data security, but it is such an important area that it bears special attention. All these topics have each been the subject of entire books, and you are encouraged to investigate the subject matter more thoroughly. This section provides an overview of some of the most important points and suggests areas that need closer scrutiny. Based on the analysis of your own organization's needs and the ideas you may develop as a result of this survey, you can begin to develop a comprehensive approach. A mechanism that is counted on to provide protection in many organizations is ignorance. People generally believe that if they don't know how to defeat a particular system or security technique, it must be secure. This is particularly true of network security, where the general lack of understanding on the part of users is often counted upon to provide some measure of protection. Security by ignorance is no security at all. You should not rely on the public's ignorance of a system's features and weaknesses to keep perpetrators at bay. Although some members of the user population may occasionally be unable to access the network even with a valid account and password, the potential attacker should be counted on to be much more sophisticated and potentially willing to expend large amounts of time and effort to defeat your best efforts at security. Here then is a survey of mechanisms that are effective and should be components of any security system.
Physical security starts with the obvious. You should control access to your facilities. As already mentioned, this can be particularly difficult if the facilities are not owned by the organization. An important characteristic of such an access control system is that it must be flexible. Most organizations experience turnover in the ranks of employees or members. A locked door is meaningless if a conventional key is provided to a large group of people. When the inevitable happens and someone leaves the organization, it is unreasonable to replace the lock and provide new keys to the group - it just won't happen. A big improvement is provided by a variety of systems that allow access to facilities to a group of people, each using an individualized "key." Some of these systems use badges or ID cards that store an identifying number or code in the card itself. The ID can be added or deleted from the group that can enter a door on an individual basis. You can even set the time periods that are valid for a particular ID. Some systems offer the capability to log the time, location, and ID used for each access. If an employee is terminated, the corresponding ID is removed from the system, and all other users continue to access the facilities unaffected. These systems can be used at the entrance to the facility, and internally to control access to machine rooms and wiring closets containing network hubs and other sensitive equipment. Many additional measures can and should be taken to physically secure your facilities, but they are beyond the scope of this book. It is important, however, that you address the issue of physical security carefully. It is the foundation upon which all other measures depend.
Windows NT offers a variety of roles that users may be assigned with different levels of default privileges. The roles are implemented as standard groups that are created when the Windows NT Server system is installed. By assigning a user account to one of these groups, the account will automatically be granted various rights to perform specific actions. In addition, the default roles may be further customized by assigning additional rights to individual user accounts and groups. The standard groups that are created are visible in figure 28.1, which depicts the main display from the User Manager for Domains administrative utility. Fig. 28.1 - The User Manager for Domains allows you to assign account IDs to specific roles for network security purposes. The most important role on a Windows NT network is that of Domain Admin. Be very careful about assigning this role. You should have only as many Domain Admins as you absolutely need and assign this role only to people who you really trust. A Domain Admin can completely disable a network in as little as five minutes or less and can leave it in a state requiring days to recover, if recovery is indeed possible. Even a Domain Admin cannot see the password that a particular user has chosen by opening the properties for a user's account. They can, however, change a user's password and then log on as that user, gaining access to anything that the user has privileges for that is not protected by further means. A Domain Admin can also take ownership of any files or directories in the file system (discussed in more detail later) and reassign permissions to any group or user including himself. These capabilities are essential for an administrator to perform needed maintenance and recovery tasks, to help users who have forgotten their passwords, and to recover information in the event a user is the victim of some calamity or decides to leave the organization. With all this power, however, it is a role that should be used sparingly. Even those who have Domain Admin accounts should create an additional account with standard user privileges that is used for everyday needs and use the administrative account only when actually performing administrative tasks to help avoid accidental mishaps. On a small- to medium-sized network, two Domain Admins should be enough. You must have at least one backup, even if the majority of work is done by a single individual. You should also consider assigning a truly secure password to the built-in Administrator account (which is a member of the Domain Admins group by default), recording it in a sealed document, and storing it offsite in a safe deposit box under the control of a trusted officer of the company. This extra "insurance" could be especially important if the assigned domain administrators ever travel together. In the event that an accident occurs, you will need to be able to regain access to the administrative capabilities for your network. As an alternative to assigning full administrative privileges, you can delegate part of the responsibility for administrative duties by using the operator roles. The four groups of operators are as follows:
Membership in one of these groups confers upon the user the capability to perform specific administrative tasks such as managing a print queue or making tape backups. Account operators can assist users who have forgotten their passwords and can create new accounts, but they cannot change or create administrator accounts. Using these roles is an effective way to delegate responsibilities for large networks, without placing too much power in the hands of a large group of people. Another related issue is the use of guest accounts. During installation of a server, a built-in account named Guest and a group named Guests are created. Allowing someone to use the Guest account, or creating an account and making it a member of the Guests group, confers upon the user the capability to log on to the network and possibly to gain access to other resources. Guest accounts can be useful, but you must beware of privilege creep - the slow addition of rights and privileges granted to a guest account as the current user becomes a more trusted member of the organization. The problem with this situation is the difficulty of remembering to reduce or eliminate the extra privileges at a later time. When the current guest leaves and another user eventually begins using the account, the level of privileges assigned may no longer be appropriate. For this reason, some organizations choose not to use guest accounts at all. If a guest user needs greater privileges, especially if they are using the Guest account, it is best to simply create a new account and make them a member of Users, rather than continuing to add additional rights to the Guest account or the Guests group. Also closely related is the disabling and eventual removal of accounts when employees or members of your organization leave or are terminated. This is a good example of something that sounds like common sense but is often overlooked. In the emotionally charged atmosphere of ending a professional relationship or even an ill-fated trial employment period it is easy to forget to take care of account administration.
A good password policy goes a long way toward securing your network. It is incredible how often this simple capability is overlooked when implementing security. The chief reason that it is underutilized is its impact on users. More than any other security provision, users as a group have difficulty with passwords. They forget them; they select bad passwords; they write them down and tape them to the bottom of their chair; and they generally hate them. Windows NT Server provides the capability to implement a good deal of control over the use of passwords. Figure 28.2 depicts the Account Policy dialog box, which is opened by choosing Policies, Account from the menu. Fig. 28.2 - The Account Policy dialog box is used to set options that affect the selection and use of passwords in a Windows NT domain. As with security in general, a good password policy is not necessarily a stringent policy. It is one that is set at an appropriate level for the organization in question. Setting all the options on the Account Policy dialog box, as shown in figure 28.2, will make you a very unpopular person in some organizations. In general, people do not like to have long passwords that must be changed at regular intervals. If you use the aging and history features, they will be forced to invent new passwords and will not be able to reuse a "favorite" password. Requiring people to change passwords at regular intervals and forcing a length of at least six characters are almost always good ideas. In fact, all these options have their place and will be needed at some organizations. Just be sensitive to the fact that too tight a policy, especially if it is imposed without explaining the rationale behind it and seeking the support of the user community, can have the effect of angering people and causing them to work against you. Some guidelines for choosing a good password are presented in a Note in Chapter 4 and are repeated here for your convenience:
The rationale behind some of these items may be worth explaining. The length of the password is important because it determines the number of possible alternatives an attacker would have to try when using a brute force approach to guessing your password. If you have a single character password it is clearly much easier to guess than if your password is longer. What some users don't understand is the fact that so-called "dialer" programs have been employed in the past, and are still occasionally employed, to gain access to computer systems. These programs will attempt a brute force logon and can be effective at gaining access to systems with poor password policies. They will typically start with a short list of commonly used passwords and then words from a full dictionary (sometimes forward and backward); then they may go through all possible combinations of characters. With a good password policy, this method is completely ineffectual because of the time required to attempt all possibilities. Several options in the policy are specifically designed to combat such a brute force attack. Setting a minimum password length of at least six characters helps. Unfortunately, Windows NT Server does not allow you to require the use of special characters, which is another component of a good password. If you allow an unlimited number of failed logon attempts without locking the account (and without logging the events) your system is a prime candidate for a brute force approach. Windows NT Server does allow you to lock the account after a specified number of attempts. Even if you allow the account to reset after an hour, a length of time that shouldn't present too great a hardship for the hapless user, you will dramatically increase the time required to successfully attack with a dialer program. This will provide time to notice the activity in a log file. Keeping a history of passwords that have been used in the past and setting a minimum password age are designed to prevent users from doggedly using the same password for their entire tenure with the organization. Unless you set these options, a stubborn or uninformed user who doesn't understand or approve of the password policy can simply change the password when required by aging and promptly change it right back to its original value. Using the same password for long periods of time is a bad idea because it increases the likelihood that someone will eventually overhear it, find it written down, or see you enter it on your keyboard. If you don't ever change it, the same password can continue to be used until unusual account activity is noticed in a log file or other evidence of tampering is uncovered. This is a weakness that opportunistic attackers have used in the past to gain unauthorized access to systems. Another password related feature that is popular with users because of the convenience it offers is a potential problem for network (and e-mail) security. Several Microsoft applications and operating systems offer a check box to remember the user's password. This can be particularly dangerous on a laptop computer. It is possible to set up a Windows 95 laptop so that by double-clicking an icon the computer will dial the network (using a stored phone number), log on to the Windows NT domain (using a stored password), and open a user's mailbox (using another stored password). Needless to say, this presents a security challenge. At a minimum, users should be discouraged from using these features. They should also realize that if the computer is lost or stolen they should immediately inform the administration team so that their account password can be changed. Windows NT Server and the components of BackOffice allow you to use the same account and password on multiple systems. This is optional with SQL Server, which offers the capability to use a separate password or be authenticated with your Windows NT account ID. SNA Server uses the Windows NT account to control gateway usage, but you will usually still need to log on to a host computer using a separate password. The rest of the BackOffice components all make use of the Windows NT account for authentication. This is not necessarily a problem and is again a popular feature with users, but it raises the stakes when choosing and managing your Windows NT account password. It is no longer used just to gain access to the network, but may also provide access to database files, e-mail mailboxes, and other shared resources. The user community should be made aware of this potential danger, and a sound password policy should be implemented and enforced.
Windows NT Server provides two distinct types of permissions. You can control access to a shared device at the time a user attempts to attach over the network, and you can assign permissions directly to some of the objects that are being used such as file systems or e-mail mailboxes. Both of these capabilities can be useful, and you should evaluate when these should be used individually, or perhaps even combined. For example, when you share a directory on an NTFS file system, you can set permissions for the share itself and set permissions directly on the file system. Setting them in both places provides additional security, but may be cumbersome to manage. Using both techniques is a little like wearing two seat belts when driving. The only time the second one is needed is when the first one breaks.
The use of auditing and security logs is an important part of the defense system offered by Windows NT Server. If you don't log failed logon attempts, you provide a perpetrator a potentially unlimited amount of time to try to access the system. With enough time, a dedicated attacker will be able to find a weak link in almost any system. It is important, therefore, to detect these attempts quickly and act decisively to stop them. You can enable auditing in two places using Windows NT Server's administrative utilities: the User Manager for Domains and the File Manager. Both of these methods are described in this section. To activate auditing of specific system events, follow these steps:
To enable auditing of specific files and directories, follow these steps:
The individual BackOffice components also contain auditing and logging features as well.
Many organizations are either attached to the Internet or planning to initiate a connection in the near future. This offers some benefits to the organization, but it also adds some challenges in terms of security. Although the desired outcome of attaching to the Internet is to allow users on your own network to view and retrieve information from servers on the Internet, it also opens the possibility of other users on the Internet viewing and retrieving information from your network. If you implement the security measures available with Windows NT Server and are vigilant in their use, you already have a strong measure of protection against unauthorized access. In addition to Windows NT Server's security, you can employ other mechanisms that may be warranted. This list summarizes four of the most commonly employed methods and their primary features. These elements may be used individually or together:
This brings up the topic of data security and very quickly the topic of encryption. Although in one sense nearly all security measures are directly or indirectly aimed at protecting data, the focus of this section is on the use of techniques that are directly applied to the data itself for the purpose of security. The history of code making and code breaking is a long one, and the subject is complex. This section provides a glimpse at the possibilities and current state of this rapidly changing field. The American writer, Edgar Allen Poe, is credited with a quote frequently repeated in this context: "It may be roundly asserted that human ingenuity cannot concoct a cipher which human ingenuity cannot resolve." Recent breakthroughs in the field of cryptography have offered the tantalizing possibility that, while an "unbreakable code" may not be forthcoming, a code that requires more than a million years of processing time on the fastest known computers to decode may be a workable alternative.
One breakthrough that has had a big impact on the field is the development of public key systems. To describe them in very simplified terms, a public key system is based on the development (usually with the aid of sophisticated mathematics) of two related keys. One is kept private; the other made public. These keys have interesting characteristics:
If Suzy wants to send a message to Sam, she can encrypt it with Sam's public key. Only Sam will be able to decrypt the message because he is the only one in possession of his private key. Furthermore, Suzy can encrypt a "signature" with her private key, and when Sam receives the message, he can use Suzy's public key to decrypt it. If the "signature" is valid - that is, if decrypting the signature yields some agreed upon value - Suzy must have sent the message because only she has her private key. To actually implement this concept in the real world requires a number of refinements and supporting techniques. For example, the keys being discussed are generally long sequences of arbitrary characters that are difficult to remember or enter into a computer without error. Some means of managing these keys must be implemented, and yet they must still be kept secure. Also, the algorithms associated with public key systems are generally unsuitable for encrypting large messages or blocks of data due to their relatively slow speed. Other encryption methods can be employed, and the key to decrypt the message can itself be encrypted with the public key algorithm and transmitted to the recipient. It is possible to purchase the source code for computer programs that implement many of the encryption algorithms that have been devised. Be aware, however, that implementing your own encryption schemes is a task with many pitfalls. Professionally developed systems take into account many details that are easy to overlook. For example, after your message has been entered into a computer and encrypted for transmission, it is important to completely erase it from any disk systems on your local computer. Often the operating system does not obliterate a file that has been deleted, but simply marks the space as available in the disk's directory. Good encryption systems overwrite the file with X's or some other suitable value to be sure that any copies of the unencrypted message are destroyed.
To use the advanced security features of Exchange Server, you must have a copy of your security file, which has an EPF extension. With this file, and your "remembered password," you (or anyone else with the file and your password) can encrypt and digitally sign your messages. Exchange Server also allows you to store your messages in a personal folder file on your local hard disk or private directory on a server. This file can be encrypted and protected with an additional password.
A publicly available system that provides encryption and digital signatures, primarily for use with e-mail systems, is known as PGP - Pretty Good Privacy. This system is the product of Phil Zimmerman and many collaborators. It has several characteristics that are appealing:
One of the biggest problems with any public key system is the management and control of public keys. If I want to exchange messages with you, through what mechanism do I originally obtain your public key? How do I know it's from you? Although this isn't too difficult if I know you personally and can arrange a face-to-face meeting, what if we live on opposite sides of the planet? Sometimes it is possible to use a mutually known intermediary, or a trusted corporate entity. This is a difficult problem without any easy answers.
In terms of basic policies, you should implement dedicated servers in all but the smallest organizations involving only a handful of people. If you have a network involving less than ten people, you may choose to have one of them use the server as a workstation. The natural tendency is to have the most knowledgeable "power user" use the server because it is the most powerful machine. This is the worst possible choice. The power user is likely to use more resources in terms of RAM and processing power thereby interfering with its use by the rest of the group. The least active user who perhaps runs only a single application at irregular intervals is a much better alternative. If your network is larger than ten people, you should make the investment to deploy dedicated servers. They should be locked up in a secure environment, with access provided to only a small, select group of people. All servers should be plugged into Uninterruptible Power Supplies (UPSs) to provide temporary backup power in case of a power outage. Windows NT Server supports the use of UPS devices that send a signal to the server through a serial cable that can cause a message to be broadcast to network users to log off and initiate an orderly shutdown of the server. Windows NT Server can be made quite secure, but like all security mechanisms, securing your servers requires care and vigilance. If you are doing everything right, the security you have in place will probably be somewhat inconvenient at times. It should not impede the ability of you or the rest of the organization to get the job done, but it may occasionally be somewhat annoying. This is one of the prices you pay for protection.
Fig. 28.5 - The CONVERT command is used to convert a FAT or HPFS partition to an NTFS partition. The default permissions and access rights applied to Windows NT servers provide you with a good start toward a secure server. For example, the ability to log on locally (that is, at the actual console of the server) is limited to the Administrators local group and the various operator groups, as seen in figure 28.6. Fig. 28.6 - The User Rights Policy dialog box is used to grant or revoke specific rights to accounts or groups. This facility can be used to customize the default settings granted administrators, operators, and users. You can modify the list of people allowed to log on locally to server(s) to include or exclude users and groups based on your needs. Many other rights are listed. Most of these, especially the advanced rights, are rarely used.
The need for auditing and the techniques for enabling logging have already been discussed. A final point regarding logs is to be aware of a technique for breaching security known as flooding the log. Using this technique, a perpetrator, aware that his actions are leaving traces in an event log, performs some action that is unauthorized. Then, he initiates a series of events designed to generate massive logging of relatively benign activity such as attempting to gain access to a resource he is not authorized to use, but for which a plausible excuse is available. Depending on the log settings, the actions he initially performed may be overwritten with the less serious events. Windows NT provides protection against this technique. You can select log settings that will cause the server to shut down if the log becomes full. Of course, this is also an undesirable outcome, but it may be the appropriate thing to do if you are trying to catch an elusive attacker. To change the settings for your security (and other logs), follow these steps:
A useful technique that provides a small additional measure of security is the use of hidden shares. When you share a directory on a server, if you add a dollar sign ($) to the end of the sharename, the share will not appear in any browsing applications (such as the File Manager or the Explorer). You should still apply access permissions as though it were a normal share because anyone who has permissions can manually enter the name of the share and connect to it normally. It just prevents people who don't need to know about it from becoming curious and launching an attack to try to gain access. Finally, an important capability added to Windows NT in version 3.5 is the capability to create a custom logon process. This can be used to provide logon by the use of an ID card, retinal scan, or other hardware-based system, or to make other specific modifications required by your organization. Being able to modify this first line of defense to best match your requirements is a useful option. To implement this capability, you must modify a replaceable Dynamic Link Library (DLL), which is called the Graphical Identification and Authentication DLL, also known as GINA. Instructions for performing this modification, and sample code, are provided in the Windows NT Software Development Kit (SDK).
An implication of this recovery mechanism is the ability to use an ERD to gain access to a server. If a perpetrator is given enough time (perhaps less than an hour), an emergency repair disk created on a machine similar to your server, with an entirely different account database, can be restored to your system. After this has been done, the perpetrator can log on using an account and password with administrative privileges for the local machine and use the capability to Take Ownership of files and directories provided on the Security menu in the File Manager to gain access to all the information on the disk subsystems of the computer. It is important to note that this is not an unplanned back door into the operating system or an accidental error. This is an important safeguard that is required to avoid the potential loss of man-years of effort due to the accidental loss of an administrative password. It does, however, highlight the vital role played by physical security and the potential use of data encryption. You simply cannot allow a server to be stolen or your information is in grave danger of being compromised.
There are two methods to add a workstation to a domain. An administrator can use the Server Manager and add the computer name to the domain in advance. Then the user simply opens the Network icon in the Control Panel, clicks the Change button next to the Domain name, and enters the name of the domain. Because the workstation has already be added to the domain by an administrator, no further administrative intervention is necessary. An alternative method provides the opportunity to maintain control over the local Administrator's group. Rather than adding the workstation to the domain with Server Manager, you can insist that an administrator physically visit the workstation to complete the operation. This is still done in the Network application of the Control Panel. When the workstation is added to the domain, the person performing the operation must enter a Domain Admin's ID and password. As the machine is added to the domain, the Domain Admins global group is added to the local Administrator's group on the workstation. You can then run the User Manager for the local machine and remove any accounts, including the user's, from the local Administrator's group. The only way this can be overcome is to reinstall the operating system, which removes the computer from the domain. You can also use the User Rights dialog box, in a manner similar to that described earlier for Windows NT Server, to determine which accounts can log on locally. In addition, you can remove the rights for all users to Access This Computer From Network. This effectively eliminates the capability to perform peer sharing of resources. For example, the user of a computer with this capability removed cannot share disk directories or printers.
You can take some positive steps to improve the security offered on Windows 95, however. Tools provided in the Windows 95 resource kit allow you to configure and enforce user profiles that are relatively secure. By specifying that each user of the system will use their own profile, you can create an administrative profile that will have full rights and a default profile with very few rights. This profile will be provided to any new user that accesses the machine and creates a new profile, something that essentially anyone with physical access can do. You can also create a profile with rights that fall somewhere in the middle, but the default profile must be very strict because it is so easy to access. This capability is far short of the security features provided on a Windows NT Workstation with NTFS and the rich set of access rights that can be assigned by placing a user in a predefined group or using the User Rights dialog box. Windows 95 does provide a useful level of control, however, and will keep average users from performing unauthorized actions.
|
See "
