You might think that there is little reason to be concerned about security in an Intranet. After all, by definition an Intranet is internal to your organization; outsiders can't access it. Also, because one of your objectives in setting up your Intranet is to provide your customers with access to a wide variety of public documents, there might seem little need to secure access to them. These are strong arguments for the position that an Intranet should be completely open to its customers, with little or no security. You may not have considered your Intranet in any other light.
On the other hand, implementing some simple, built-in security measures in your Intranet can allow you to provide resources you may not have considered possible in such a context. For example, you can give access to certain Web pages to some people without making them available to your entire customer base by using one of several kinds of authentication. In this chapter, you learn how to use simple security measures to widen the scope of your Intranet.
Intranet security is a multifaceted issue with both opportunities
and dangers, especially if your network is part of the Internet.
This chapter walks through the major issues and provides detailed
information on using built-in Intranet security features.
| Warning |
Except in the sections of this chapter that are specifically devoted to Internet security issues, it's assumed your Intranet is not accessible from outside your organization. If you are on the Internet, the Intranet security measures discussed in this chapter may not be sufficient to secure your system. If you want to make the services and resources of your Intranet accessible from the outside, you'll need to take significant additional steps to prevent abuse and/or unauthorized access. Some of these steps are described at the end of this chapter in the section "Your Intranet and the Internet" and in Chapter 28, "Connecting the Intranet and the Internet." |
Many people view computer and network security in a negative light, thinking of it only in terms of restricting access to services. One major view of network security is "that which is not expressly permitted, is denied." Although this view is a good way of thinking about how to connect your organization to the Internet, you can, and possibly should, view Intranet security from a more positive angle. Properly set up, Intranet security can be an enabler, enriching your Intranet with services and resources you would not be able to otherwise provide. Such an overall security policy might be described as "that which is not expressly denied, is permitted."
This chapter takes the latter approach, presenting Intranet security in terms of its opportunities for adding value to your Intranet. For example, some of your customers may have information they'd like to make available, confidential management or financial information, for example, provided that access to it can be limited to a specified group. Without the ability to ensure that only those who have the right to see such information will have access, the custodians of such data will not be willing to put it on an Intranet. Providing security increases your organization's ability to use the important collaborative aspects of an Intranet.
The more defensive approach, preventing abuse of your Intranet, should also be considered. Organizations' needs for security in an Intranet can vary widely. Businesses in which confidentiality and discretion is the norm in handling proprietary information and corporate intellectual property have different needs than a college or university, for example. Academic institutions generally tilt toward making the free exchange of ideas a primary interest. At the same time, though, the curiosity (to use a polite word) of undergraduates imposes strong needs for security. Keeping prying sophomores out of university administration computing resources is a high priority. For example, students have been known to try to access grade records (their own or those of others) for various reasons. Adolescent pranks take on new dimensions on a computer network.
Before learning about how you can use security to enhance your Intranet, you should know what security features are available to you. These features break down into three main categories. First, you can take steps in your Web server software to set up security. Second, you can take steps with the other TCP/IP network services you've set up on your Intranet to enhance their security. Third, you can secure Windows NT Server as a network operating system irrespective of the fact that it is being used as a Web server. I address each of these categories throughout this chapter.
Another feature worthy of brief mention is that some Mosaic browsers allow you to secure the browser to limit what the customers can do with them. But this feature, referred to as kiosk mode, is not widely available.
Although the main focus of this chapter is Web security, you can and should implement security and access controls in some of the other network services that you learned about in Chapters 8 and 9. The following are some of the steps you can take:
This chapter doesn't provide any additional information about these services. Refer to the documentation for these network packages and to the help files with the NT User Manager application to learn about how to handle access control and other security features in these other network services.
It's your responsibility to determine the level of security you need on your Intranet and, of course, to implement it. Putting most of the security measures mentioned into place, as you'll learn in the following sections, is not difficult. Your primary concern will be explaining to customers how Intranet security works not so much as a limiting factor, but as an opportunity for increased use and collaboration using your Intranet. Assuring decision-makers that they can post information on your Intranet in a secure fashion can go a long way toward making your Intranet a success. At the same time, it's important to make sure both information providers and their customers understand a number of critical aspects of Intranet security, so they don't inadvertently defeat the purpose of it.
There are network security commonplaces, unrelated to Intranet security specifically, that need your attention. All the security precautions in the world can't protect your Intranet from overall poor security practices. Poor user choices on passwords always leads the list of computer and network security risks. If Bob uses his own name as his password, or his significant other's or pet's name, password-guessing is simple for anyone who knows him. Some people even write their passwords down and tape them to their keyboards or monitors-so much for the security of those passwords. You can limit access to a sensitive Web resource based on the TCP/IP network address of the boss's pc, but if the boss walks away and leaves his pc unattended without a password screen lock (a feature in many screen savers), anyone who walks into the empty office can access the protected resources.
In other words, the same good security practices that should be followed in any networked computing environment should also be made to apply in your Intranet. Not doing so negates all the possible security steps you can take and reduces the value of your Intranet. Even in the absence of malice, the failure to maintain any security on your Intranet inevitably results in an Intranet with little value to its customers.
The following list summarizes the wide range of very flexible security features you can implement on your Web server:
You can combine these features in a number of ways, such as requiring a password and limiting access to a group of users who must access your Web server from a specific group of computer systems. Combining two, or even all three, of these methods provides the best overall security.
The first major element of Web server security is user name/password authentication. As you saw in Chapter 7, the IIS Web server provides this basic kind of security. Figure 10.1 shows what the Web browser user sees when he encounters a Web page that requires user name/password authentication for access.
In IIS, a Web page or an entire directory tree under the Web server document root can be protected with just three easy steps:
Figure 10.3: Enabling Password Authentication in the IIS Web server.
Now customers who want to access that directory will be faced with a dialog in their browser similar to Figure 10.1. But why did I suggest that you use all three IIS methods for password authentication? First, you probably want to keep the option for Allow Anonymous checked for the benefit of all your customers who want to access your Intranet home page. Unless, of course, you want to protect your whole Intranet!
Second, the Basic (Clear Text) option is enabled because that is all the page retrieval security that most Web browsers currently support. The Challenge/Response option is a much tighter security method provided by IIS on NT networks, but it is only compatible with Internet Explorer.
If any customers on your Intranet do have Internet Explorer, those
passwords will be passed between the browser and the server in
a more secure fashion if the third option is enabled. For those
customers who don't have Internet Explorer, option two will provide
a basic encoding (called uuencode) that is very simple
to decipher if anyone should stick a packet sniffer on your LAN.
| Note |
Don't confuse page retrieval security with secure transactions on the Web. The former is used to regulate whether a particular Web page is viewable by a particular customer. The latter is used to encrypt the form data that is sent back to the server by the browser after the user is done filling out a Web page that has been viewed. The Secure Sockets Layer (SSL) technology, now supported by many browsers, is an example of the latter. |
Suppose your HTTP server's document root directory contains three main subdirectories named public, management, and personnel. Using NT directory permissions, you can specify that access to the management and personnel subdirectory trees requires user name/password authentication and leave public open for anyone to access without being prompted for user name and password. You can also set up more specific permissions within the protected subdirectories to further limit access to particularly sensitive documents by using user names and passwords.
Unless the access rules change as a user moves around on your Intranet Web pages (as with the personnel/management subdirectory in the example above), he will be prompted only once in his browser session for a user name and password. As long as he continues his browser session, he can access all of the files and directories available to him under the most recent access rule without being prompted again for his password. This situation is for convenience's sake; customers shouldn't have to repeatedly provide their user names and passwords at each step of the way when the access rule hasn't changed.
However, this situation has important ramifications if you follow it out logically. Suppose Anne, having authenticated herself to access the management subdirectory, leaves her browser session running, as most of us do. Her privileged access remains open to all the files protected by that one-time, possibly days-old, authentication. If she leaves her computer unattended when she goes to lunch or goes home for the day, without any sort of active screen or office door lock, anyone can sit down and browse the files and directories that are supposed to be limited to Anne's eyes only. This potential security breach is one that you as Webmaster can do little about and it is one that can be potentially harmful to all your work. This situation is no different from when a user leaves his workstation unattended without logging off. The most you can do is to try to educate your customers about such everyday security matters, even though they have little to do directly with the subject of your Intranet.
Nearly all Web servers, including IIS, provide an additional authentication method that uses the TCP/IP network address of customer workstations or pcs as access criteria. As you'll learn in later chapters in the context of CGI-bin programming, every Web browser request for a document or other Intranet resource contains the numerical IP address of the requesting computer.
An important point about IP address authentication is that the Web server software blindly accepts the word of a requesting computer when it sends its IP address. There is no verification possible of this information. A curious, mischievous, or malicious person can reconfigure his computer to impersonate someone else's by changing his computer's IP address. Although this is an over-all network security issue, not specifically one for your Intranet, you need to know about it because it can affect the security of your access-controlled documents. Security-minded network administrators can use special hardware and software to prevent this sort of IP spoofing, but for your Intranet's purposes, you'll probably want to combine hostname/IP address authentication with user name/password authentication.
You can further enhance security on your Intranet by encrypting Web transactions. When you use an encryption facility, information submitted by customers using Web fill-in forms, including user names, passwords, and other confidential information, can be transmitted securely to and from the Web server.
A wide range of proposed and/or partially implemented encryption solutions for the Web exist, but most are not ready for prime time. Of the several proposed methods, only the Secure HTTP (S-HTTP) and Secure Socket Layer (SSL) protocols have emerged in anything like full-blown form. Unfortunately, the two are usually implemented mutually exclusively, though compatibility is possible. Worse, Web browsers and servers that support one method don't support the other, so you can reliably use one or the other only if you carefully match your Web server and customers' browsers.
Secure HTTP was developed by Enterprise Integration Technologies and RSA Data Security, and the public S-HTTP standards are now managed by CommerceNet, a not-for-profit consortium that is conducting the first large-scale market trial of technologies and business processes to support electronic commerce over the Internet. (For general information on CommerceNet, see http://www.commerce.net/.) S-HTTP is a modified version of the current HTTP protocol. It supports the following:
As with SSL, you must have a compatible Web server and browser that both support S-HTTP transactions in order to use this technology. IIS 1.0 supports only SSL.
S-HTTP seems to have been engulfed in the 1995 Netscape tidal wave. Unwilling to wait for widely accepted HTTP security standards to evolve (as it was with HTML as well), Netscape Communications Corporation developed its own Secure Sockets Layer encryption mechanism. SSL occupies a spot on the ISO seven-layer network reference below that of the HTTP protocol, which operates at the application layer. (See Table 10.1.) Rather than developing a completely new protocol to replace HTTP, SSL sits between HTTP and the underlying TCP/IP network protocols and can intervene to create secure transactions. Netscape makes the technical details of SSL publicly available. In addition, C-language source code for a reference implementation of SSL is freely available for non-commercial use. Microsoft includes SSL support in both IIS and Internet Explorer.
Table 10.1 provides a brief description of each of the seven layers
of the OSI model. Note that layer 1 is contained in hardware and
layers 2 through 7 are implemented in software. The list seems
to be in reverse order. Network engineers generally view the flow
of data as originating at the application layer and moving downward
through the layers toward the hardware. Then the process is reversed
when the packet arrives at the destination.
| Layer | Implemented in | Description |
| Layer 7 | Application | The program's users interact with to initiate network data transfer. |
| Layer 6 | Presentation | Encrypts or decrypts data, packs or unpacks data, and converts data between formats. |
| Layer 5 | Session | Determines when data transmission will start and stop. |
| Layer 4 | Transport | Concerned with the quality of data on the circuit; includes error-checking protocols. |
| Layer 3 | Network | Establishes the network route from the sender to the recipient. |
| Layer 2 | Data Link | Provides for the bundling of several bits into a data frame. |
| Layer 1 | Physical | Includes the specifications for the electrical signals and the transmission of bits. |
Given Netscape's and Microsoft's collective share of the Web browser
market, S-HTTP doesn't seem to have much of a chance of becoming
widely available. With the exception of ncSA Mosaic, most other
Web browsers have-or have promised-SSL support. Some of them are
Spry's Internet in a Box and Mosaic in a Box for Windows 95 and
version 2.0 and 3.0 of Microsoft's Internet Explorer for Windows
95, Windows NT, and the Macintosh. By the time you read this chapter,
all these packages may have completed their SSL implementations.
| Note |
Even though a browser may support secure transactions using SSL or S-HTTP, no transactions are actually secure except those between the browser and a compatible Web server. It's also important to note that most mechanisms for passing Web services through network firewalls (proxying, for example) don't support secure transactions unless both the proxy server and the destination server do. |
The IIS online documentation includes much more detailed information about how to obtain and configure SSL.
CGI is the mechanism that stands behind all the wonderful, interactive fill-in forms you'll want to put on your Intranet. Your customers demand these kinds of Intranet resources, and later chapters of Building an Intranet with Windows NT 4 provide a number of technical tips on creating CGI scripts. You need to be aware, though, that CGI applications open potential security problems.
You can minimize much of your risk for security breaches in CGI scripting by including in your scripts explicit code for dealing with unexpected user input. The reason for this is simple: You should never trust any information a user enters in a fill-in form. Just because, for instance, a fill-in form asks for a user's name or e-mail address, there is no guarantee that the user filling in the form won't put in incorrect information. Customers make typographical errors, but probing crackers, even those inside your organization, may intentionally enter unexpected data in an attempt to break the script. To be secure, your CGI scripts have to anticipate and deal safely with unexpected input.
Other problems inherent with CGI scripts include the following:
Paul Phillips maintains a short but powerful list of CGI security resources on the Web. Check out http://www.cerf.net/~paulp/cgi-security, where you'll find a number of documents spelling out these and other risks of CGI scripting. For an extensive list of general CGI-related resources, go to Yahoo's CGI page, at http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/CGI_Common_Gateway_Interface/index.html.
Is your Intranet accessible from the Internet? If so, all the security problems of the Internet are now your Intranet's problems too. Throughout this book, an implicit assumption has been made that your Intranet is private to your organization. You can, however, connect safely to the Internet and still protect your Intranet. You can even use the Internet as a means of letting remote sites in your company access your Intranet. In Chapter 28, I'll discuss how to set up NT, RAS, and your modem as a simple router between your LAN and the Internet. The following sections cover some Internet security basics.
It's a fact of Internet life that there are people out there who want to break into other people's networks through the Internet. Reasons vary from innocent curiosity to malicious cracking to business and international espionage. At the same time, the value of the Internet to organizations and businesses is so great that vendors are rushing to fill the need for Internet security with Internet firewalls. An Internet firewall is a device that sits between your internal network and the outside Internet. Its purpose is to limit access into and out of your network based on your organization's access policy.
A firewall can be anything from a set of filtering rules set up on the router between you and the Internet to an elaborate application gateway consisting of one or more specially configured computers that control access. Firewalls permit desired services coming from the outside, such as Internet e-mail, to pass. In addition, most firewalls now allow access to the World Wide Web from inside the protected networks. The idea is to allow some services to pass but to deny others. For example, you may be able to use the Telnet utility to log into systems out on the Internet, but users on remote systems cannot use it to log into your local system because of the firewall.
The following are a couple of good general Web resources about Internet firewalls:
If your company is also connected to the Internet, you need to know how to make sure your Intranet isn't generally accessible to the outside world. You learned earlier in this chapter about denying access to your Web server using hostname and IP address authentication, but the fact that IP addresses can be easily spoofed makes it essential that you not rely on this mechanism as your only protection. You'll still want to rely on an Internet firewall to protect your Intranet, as well as all your other network assets. Unless your corporate network is not connected to the outside world at all, you'll probably want to ensure the security of your other Intranet services as well, including not only your Web servers, but also your FTP, Gopher, Usenet news, WAIS, and other TCP/IP network services.
More and more companies with widely distributed offices, manufacturing sites, and other facilities are turning to use of the Internet to replace private corporate networks connecting the sites. Such a situation involves multiple connections to the Internet by the company, with the use of the Internet itself as the backbone network for the company. Although such an approach is fraught with security risks, many organizations are using it for non-sensitive information exchange within the company. Using a properly set up firewall, companies can provide access to services inside one site's network to users at another site. Still, however, the data that flows across the Internet backbones between the corporate sites is mostly unencrypted, plain text data that Internet snoopers can easily read. Standard firewalls don't help with this situation.
A number of firewall companies have recently developed Virtual Private Network (VPN) capabilities. Essentially, VPN is an extension of standard firewall capabilities to permit authenticated, encrypted communications between sites over the Internet. Using a VPN, users at a remote site can access sensitive data at another site in a secure fashion over the Internet. All the data that flows on the public Internet backbones is encrypted before it leaves the local network, and then is decrypted when it arrives at the other end of the connection.
The most mature VPN product comes from Raptor Systems (http://www.raptor.com/) as part of the company's Eagle family of products.Other products are available from Checkpoint (http://www.checkpoint.com/) and Telecommerce (http://www.telecommerce.com/). Unfortunately, the market for Windows NT firewall products is still very young; most products are still exclusively based on UNIX.
When people think about security on the Internet, they automatically think about firewalls, but there is a lot more to security than just firewalls. You will keep away most general pranksters by setting up your site with security in mind. The following are some miscellaneous pointers for running a secure Web site:
This chapter has dealt with implementing security on your Intranet. Although an Intranet is, by definition, internal to an organization, security is important not so much because it prevents things, but because it enables them. Judicious use of built-in security features of Web servers and other Intranet resources can add value to your Intranet by making new things possible. In this chapter, you have done the following:
Part III turns to the setup and use of everyday office applications as Intranet tools.