Chapter 7 Internet Connections

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Once you have finished this chapter, you will know:

• How to connect your site to the Internet

• What security precautions to take

• How to configure the new Internet Information Server (IIS) and Peer Web Server (PWS) that come with NT 4.0 Server and Workstation, respectively

• How to perform common IIS administrative tasks

• Where to find further information on the Internet

Both the Server and Workstation editions of NT 4.0 come with everything you need to hook up to the Internet, though if you expect your site to function as an Internet server you will need NT Server.

On This Page

Internet or Intranet?
Client-Side Tools
Making the Internet Connection
Internet Information Server and Personal Web Server
Security
Creating Web Content
Conclusion

Internet or Intranet?

If you set up an Internet server but permit access only by people inside your own company, you've created an intranet. There isn't much reason to distinguish between the two situations in most of this chapter, because most Internet technology applies just as well in the intranet situation.

Because an intranet isn't connected to the public Internet, some of the security concerns you might have are reduced. However, if your network is connected to the Internet through a firewall, it's critically important that the firewall not allow access to the intranet server. You can block outside access to the IP address of the intranet server or use a non-standard port for Web services and block that port. The section below on firewalls has more information on this subject.

Client-Side Tools

Both NT 4.0 Workstation and Server include Internet Explorer (IE) 2.0 on the CD. About a week after Microsoft shipped NT 4.0, it released the final version of Internet Explorer 3.0 on its Web site. It's a major improvement over IE 2.0 and includes support for ActiveX controls, so you'll want to download it.

The upside of IE 2.0, other than the obvious benefit of already having it, is that it's small, quick, and responsive. IE 2.0 pops up much more quickly than either IE 3.0 or Netscape Navigator 3.0. And if you're concerned about the security risks of Java, ActiveX, or JavaScript, IE 2.0 lets you rest easy because it doesn't support any of that. It's on par with Netscape 1.2 in terms of support for features like tables and probably can view 80% of what's on the Web with no compromises at all. If IE 2.0 was not installed during NT setup (it normally appears as an icon on the desktop), you can add it with Control Panel/Add Remove Software (where it's called "Internet Jumpstart Kit").

If you're coming from a UNIX environment and are familiar with command-line FTP and Telnet tools, you'll find those in NT 4.0 as well (see Chapter 6). Most people won't have much of a need for these, however, because FTP services are conveniently provided by Internet Explorer, and few will need to log in to a command-line session.

Making the Internet Connection

If your goal is to connect your own server to the worldwide Internet, you'll need a communications line, an Internet Service Provider (ISP), and some basic address and domain information. We'll cover the essential procedures in this section.

Internet Service Providers

If you'll pardon the analogy, the Internet is a lot like an illegal drug network. The people at the top run the Internet backbone, dealing with massive high-speed connections. They sell big chunks of bandwidth to ISPs, who divvy it up into even smaller parcels and sell that to companies needing "large" amounts of bandwidth such as a T1. The bigger ISPs also sell to smaller ISPs, who turn around and break the bandwidth up, selling dial-in services to people with low-speed modems.

The more bandwidth you plan to buy, the closer to the Internet backbone you're likely to be. That puts you at a double disadvantage if you go with a slow connection such as 28.8Kbps modems. Not only is the data rate low, but there are a lot more hops—from your ISP to his ISP to the big kahuna ISP—before packets make it to the Internet backbone where they can speed to their ultimate destination.

Communication Links

Your options for bandwidth are varied, as are the costs. The least expensive option is a plain phone line combined with a 28.8Kbps modem. Because your ISP is probably a local call away and most areas don't meter local calls, the telephone costs are essentially zero. Unfortunately, analog modems aren't a very feasible solution; you can't really serve more than two or three users simultaneously this way before response time becomes ridiculous.

One step up are ISDN digital lines, which offer up to 128Kbps performance and can support around eight simultaneous users with acceptable response times. Beyond that, you can go to a T1 line at 1.5Mbps that can offer decent service to as many as 100 users at once. Some ISPs offer fractional-T1 access to the Internet, but you'll still have to install a T1 to your site. You just won't be using its full bandwidth.

One new development worth asking your local phone company about is an Adaptive Digital Subscriber Line (ADSL). This technology is being touted as a faster, more flexible alternative to ISDN. In essence, ADSL is special short-haul modem technology that works over existing copper wire. One modem is placed at your site, and the other is located at your telephone central office. The modem in the central office is connected to standard Internet router equipment that is separate from the phone system. Because the distances between the modems are small—your central office is often just a mile or two away—ADSL can get speeds up to 5MB per second or so. The phone companies like it too, because, unlike ISDN, they don't need to buy an completely new multimillion-dollar phone switch to provide the service.

If you need more than a simple phone line, you have the added variable of dealing with the local phone company. ISDN has been available for a few years in large metropolitan areas, but it's still common in many areas to have a month's wait before you can have service installed. And when Windows Magazine (in New York) ordered a T1 line in mid-1996, there was a two-month wait before NYNEX (the local telephone company) could install it. Emerging technologies like ADSL are likely to have the same slow ramp-up and long waits for service connection as the phone companies stumble through the learning curve.

One way to circumvent the phone company is to locate your server at the ISP. Many ISPs will offer to keep your server at their site and connect it directly to their high-speed network—for a price. Besides the extra cost associated with this arrangement, there's the additional hassle of not being in physical control of the system. Some ISPs offer trained staff that may be able to help you resolve problems remotely, but make sure you're clear on what they will and won't do.

In every case except the simple dial-up modem (be it analog or ISDN), the connection you get will be connected to some special equipment called a CSU/DSU (channel service unit/data service unit). This equipment acts as a modem, converting the digital signal to an analog form that's sent over the phone line. The CSU/DSU output will typically be connected to an Ethernet router. The equipment you want to connect to the Internet is then plugged into the router's Ethernet segment.

Software and Administrative Setup

Once you've chosen an ISP and selected the bandwidth you need (and can afford), it's time to think about how you'll do the protocol and routing part of the work.

Most likely, you'll want to register a domain name so that your Web site and other services can be accessed as https://www.yourcompany.com. To do this, contact InterNIC (https://www.internic.com) and fill out a form. Domain name registration costs $50 a year, with the first two years being paid in advance. It's worth the cost, because otherwise you'll be using the ISP's domain, like https://www.isp.com/yourcompany. This makes it nearly impossible to change ISPs! Some ISPs will offer to register a domain name for you as part of a bundle deal. If you go this route, make sure that you own the domain name (your name is on the InterNIC form and not the ISP's). If the ISP owns the domain name, it could complicate moving to another ISP if you become dissatisfied.

The next requirement is to get a block of IP addresses. The more addresses you need, the greater the complications. The InterNIC also is involved in assigning and doling out blocks of IP addresses, but for small numbers of addresses you can usually go through your ISP. The catch here is, again, becoming locked into one ISP. The explosive growth of the Internet has meant that the backbone routers have millions of addresses to track. One way to reduce the load on those routers is for the backbone managers to assign blocks of IP addresses to specific ISPs and always route those addresses the same way. The problem comes for you, the customer, when you try to move to another ISP and have to change all the IP address assignments in all your systems.

Firewalls

Any private network that is connected to the Internet should go through some type of firewall. At minimum, a firewall provides the ability to filter out traffic that shouldn't pass between the Internet and your private network, such as messages between two computers within your private network. These are typical packet-router functions, and indeed most dedicated routers can provide basic firewall functions. However, there are benefits to more sophisticated arrangements.

Limited Access Quandary A firewall must balance ease of access with adequate security precautions. If you create restrictions on users that are unworkable given the needs of their jobs, they will find ways around the restrictions. Their workarounds may create security problems that are even worse. For example, most companies have dial-in or dial-out modem facilities, either on individual systems or in a shared modem pool. Users might use a modem pool to create their own dial-in access to the IP network, using their own PC as the router. These "back-door" access paths to your network can let attackers make a complete end-run around your firewall security.

Another balancing act involves the position of your public Internet server. If you place the Internet server outside your firewall, it's open to just about any attack. Yet if you try to place the Internet server behind your firewall, the firewall restrictions must be loose enough for public Web, ftp, and other traffic to pass. One common solution involves a "perimeter network" or "sandwich" approach that uses two levels of firewall. The first level provides basic protection to your public Internet servers, and the second level screens traffic further before it enters your private network.

Packet Filtering Each packet on the network has information that a firewall can use to make decisions about security. First, there are two IP addresses in each message: source and the destination. For both incoming (Internet to internal network) and outbound (internal network to Internet) traffic a good firewall will let you filter by either or both. Skilled intruders can easily forge the source address, so filtering based on it won't always be foolproof.

Another important piece of information in a packet is the port number. When a packet arrives at a system, the port number helps to route the message to the right service on that system. For example, a port number of 80 is usually routed to the HTTP (Web) service. A firewall can block use of the standard HTTP service by blocking port 80. It would still be possible to use the HTTP service on a non-standard port, as long as both the source and destination system agreed on the port number.

One application of filtering is to discard "impossible" messages. For example, let's say a message arrives at your firewall from the Internet, and its source address is that of a legitimate system inside your firewall. How would a message from inside your firewall end up at the front door? This probably indicates that an attacker is trying to get the destination system to accept a message from a supposedly trusted system.

Using NT's packet filtering NT Server includes a limited ability to filter packets, on a per-adapter basis, using the port number, the protocol type, or a combination of the two. You configure this feature in Control Panel, Network, Protocols, TCP/IP Properties, IP Address, Advanced dialog. Check the Enable Security box, and click the Configure button.

One use for this feature would be as a poor man's firewall, where the NT system is acting as a router between two network cards. You might, for example, allow only mail and news traffic through from the Internet by permitting only the TCP and UDP protocols (6 and 17) and further restricting traffic to TCP on ports 25 and 119. The user interface for port filtering leaves a bit to be desired; you must know the decimal values for all the ports, protocols, and services. The most common port/protocol combinations you'll need to know are HTTP (80/TCP or UDP), FTP (20 and 21/TCP), mail (25/TCP), and news (119/TCP). Protocol numbers are 6 for TCP and 17 for UDP.1

NT's packet filtering feature cannot screen by source or destination address. For example, "only allow TCP packets with port 80 (HTTP) and a destination address of 10.124.201.8 (an HTTP proxy server)" isn't possible. And of course if someone manages to break into your system—for example, by exploiting some bug in your mailer software—that person may be able to circumvent the port restrictions you've put here. Given its security and filtering restrictions, NT's port filtering shouldn't be considered an adequate replacement for a dedicated router or complete firewall setup.

Proxy Servers Although packet filtering can provide basic protection, it still leaves a lot of your internal network visible to the outside world. For example, if each user in your private network wants to browse the Web, your firewall will have to let those packets through in both directions. You could try to restrict things a bit by permitting only packets that use the HTTP common port number of 80, but a fair number of useful Web servers use other port numbers. In essence, your firewall can't filter much unless your users are willing to sacrifice some communication ability.

One way around this problem is to add a proxy server. The proxy usually resides on a system that figuratively has one foot in the Internet and one foot in your private network. Instead of talking directly to a Web server on the Internet, for example, the users inside your network talk to the proxy server. The proxy server then forwards the request to the destination Internet server. The destination server sees only the proxy server; to the Internet your entire network appears to be one Web user (a really busy one).

With a proxy in place, the firewall can be much more restrictive. Only the proxy server is talking to the Internet, so a would-be attacker sees only one IP address from your network. All other addresses in your internal network can be completely screened by your firewall and are safe from direct attack. To keep the firewall tight, you need to have a proxy for each type of service that your internal network users want to access. At a minimum, that will include HTTP and FTP, but it may also include news (NNTP), mail (SMTP), or telnet services as well.

At the time this book was written, Microsoft was developing an NT-based proxy server, code-named Catapult for use on NT Server. Catapult can act as a proxy at the Windows Socket level, supporting any socket-based application (which includes most Internet applications). It can also function as a direct Web proxy. The Microsoft Web site should have the latest information on the progress of this product.

Many other vendors are already active in the proxy and firewall arena; one NT-based solution is made by Raptor Systems (https://www.raptor.com), another is part of Digital's Altavista product line (https://altavista.digital.com). Yahoo has a comprehensive list at https://www.yahoo.com/Business\_and\_Economy/Companies/Computers/Software/Systems\_and\_Utilities/Security/Firewalls.

Internet Information Server and Personal Web Server

NT Server includes Internet Information Server (IIS) 2.0, a full World Wide Web, FTP, and Gopher server for the Internet. NT Workstation offers a reduced-function version of IIS called Personal Web Server (PWS). Because the Peer Web Service (PWS) in NT Workstation is a subset of the full IIS in NT Server, the sections here cover both products.

Differences Between PWS and IIS

The basic differences between PWS and the full IIS are that PWS lacks the following features:

• Access control via IP addresses

• Virtual servers (multiple home directories for different domain names)

• Logging to SQL/ODBC database

• Bandwidth throttling

• 128-bit keys in Secure Sockets Layer (SSL), with both versions supporting 40-bit keys for SSL

In addition, PWS lacks a few of IIS's performance-enhancing optimizations such as caching of frequently used file handles. Microsoft also introduced some performance limits on PWS with the assumption that foreground application performance should remain a priority. That keeps the workstation responsive, but at the expense of Internet-service performance.

In practical terms, NT Workstation/PWS would serve perfectly well as a test bed for developing IIS applications or as an intranet Web server for a small group of users. Beyond that, either upgrade to NT Server/IIS or check out a third-party Web server. But before you do that, read the next section.

NT Workstation as an Internet Server?

Although NT Workstation is billed by Microsoft as a workstation operating system, it can easily handle the load that most Internet servers would see from World Wide Web (HTTP) or File Transfer Protocol (FTP) requests. The communication line between the Internet and the Web server is the limiting factor for all but the largest Web sites. This is especially true if your Web site uses anything less than a T1 line (1.544Mb per second) as its communication link. Although NT Workstation/PWS can't handle the load of NT Server/IIS, that's mostly because Microsoft specifically changed PWS to reduce its performance and limit its features.

Third-party vendors of Web servers such as Netscape Commerce Server and O'Reilly WebSite have been able to hold down the overall cost of their products by using NT Workstation as the basis for a Web server. Microsoft hasn't been pleased with this development. Its product strategy has been to bundle its own Internet server product, IIS, on only the higher-cost NT Server product. Competitors have priced their Web servers so that the cost of NT Workstation plus the Web server is hundreds of dollars less than the cost of NT Server.

Microsoft's position is that the use of NT Workstation 4.2 as an Internet Web server violates the NT Workstation 4.0 license restriction that permits no more than 10 inbound connections. The result is that although there are few technical reasons you can't use NT Workstation 4.0 as the base for third-party Web server software, Microsoft says you will be in violation of your license if you have more than 10 connections. At the time this book was written, Microsoft hadn't clarified exactly what "10 connections" means in the context of Internet services.

For the additional cost of NT Server, you do get a good set of extra features, including FrontPage for managing your Web content; it's an excellent value overall. It's probably more rewarding to spend your time creating great Web content than interpreting the nuances of software license legalese, unless you're a lawyer.

Setting Up Internet Information Server

Preparation and Planning Before you actually begin the installation, review the settings here and in the Internet Service Manager (ISM) section that follows. Most of the choices you make at installation can be easily changed later in ISM, but subsequent work will be a lot easier if you do a bit of planning before running setup.

Choosing Services To Install IIS provides three services: World Wide Web (WWW or just Web), File Transfer Protocol (FTP), and Gopher. You can opt to install any or all of these services, and this section outlines the abilities of each.

By far, the World Wide Web is the most popular service on the Internet, mainly because companies like Netscape (and now Microsoft) have spent a lot of time improving the quality of Web browsers. Browsers now include support for FTP and Gopher protocols, so there isn't a need for a separate client-side utility if you decide you want to transfer a file or do a Gopher search. Given the popularity of the Web, nearly every IIS administrator will want to install the Web service.

The popularity of FTP predates that of the Web, but many of the basic duties of file downloading (from server to client) can be done by a Web browser as well. FTP's protocol is more robust and also kinder to network bandwidth than the HTTP protocol used for Web transfers. Bandwidth is an issue primarily if you will be posting large multi-megabyte files for downloading. In these cases, the FTP service is a good choice, as long as you can offer the files for anonymous download. When FTP logs users on for non-anonymous use, it requires that the password be sent over the Internet in unencrypted form, which makes it easy for an attacker to steal the password.

If you want to transfer files securely, the most convenient way is to use a Web browser and HTTP protocol in combination with Secure Sockets Layer (SSL) encryption. Receiving files (server to browser) is easy; just place a link to the file in a Web page, and the browser will download it. Sending files back to the server is a bit more difficult. Both IE 3.0 (but not 2.0) and Netscape Navigator 2.0 or higher support a file upload feature in their forms support. However, IIS 2.0 doesn't provide the CGI/ISAPI program that is required on the server side to receive the file. (One server that does is O'Reilly's WebSite for NT.) Presumably Microsoft will provide an ISAPI3 version of such an application at some point as an IIS upgrade.

You won't find much on Gopher in this chapter, because the Gopher service has essentially been killed off by the popularity of the Web. Gopher's claim to fame was its ability to act as a distributed index to information all over the Internet. However, with Web-based resources like Lycos, Yahoo, and AltaVista now available, Gopher isn't used much. If you're a fan of Internet history, you can get the latest FAQ file for Gopher by browsing the URL (Uniform Resource Locator) gopher://mudhoney.micro.umn.edu/00/Gopher.FAQ in your Web browser.4

File Locations and Permissions Here are some points to consider when you're deciding where to put files on your Internet server:

• Web pages: At this point, you need to be concerned only about choosing the root directory for your Web pages; the sub-structure can wait for later. If multiple people will be responsible for editing and updating Web pages, consider whether you'll want to have them edit the pages directly or do off-line editing on another system and submit the pages in an update procedure. If they edit the pages directly, you'll need to give them write access to the directories they maintain (and only those directories). Because NTFS disk partitions provide file/directory security and FAT partitions do not, all Web pages (and other Internet-accessible files) should be located on an NTFS partition. See the section on security later in this chapter for some of the reasons.

• CGI and ISAPI programs: Only a trusted administrator should be given write access to the CGI/ISAPI programs directory. This administrator should understand the function of any program placed into this directory. By default, the virtual directory name of this directory is /scripts, and the Web-based version of Internet Service Manager has this name wired into all its pages. Some software packages may assume that the scripts directory is named /cgi-bin, but you can easily appease them by adding that as another virtual directory alias for the /scripts directory. Again, CGI and ISAPI applications should be available only from NTFS partitions.

• FTP directories: The FTP directories should not overlap any directories used by the Web services if those directories are writable. If outsiders can upload new Web pages or CGI programs, they can create security holes. If you allow FTP uploads, make sure the disk that holds the upload directory has plenty of room. IIS does not provide an option to limit the size of uploaded files, so this disk may fill up. To prevent a server crash, keep the NT system files and virtual memory pagefile on a separate volume from that used for uploads (which should, of course, be formatted through NTFS5 ).

• Log files: Log files can grow quickly on a very busy server. As with FTP directories, make sure you have enough space on drive to hold them and avoid putting them on the same volume with the NT system and virtual memory page files. (The default setup puts log files in the "C:\Winnt\System32\Log Files" directory, which breaks this rule.) Log files hold information that might be valuable to competitors or attackers, so don't put them in directories that are accessible by the FTP or Web services, and make sure they're protected with appropriate NTFS permissions.

Virtual Directories Both the Web and FTP settings in Internet Service Manager offer you a way to set up virtual directories that create a different-looking file structure for Internet users than actually exists on your hard disk. This is extremely useful, both for administrative maintenance and for security reasons. You'll find these settings inside the Directories tab of the Web and FTP services, in the Directory/Alias/Address list.

One very useful feature the Web server implements here is virtual servers. (PWS on NT Workstation does not offer this feature; it's available only with IIS on NT Server.) It lets you host multiple Web home pages with a single IIS server. For example, your company might have a site with the domain name www.acme.com. You decide to go into two new ventures: selling books and selling specialty foods. Instead of selling both from your existing domain name, you could create separate domains, one for www.books.com and one for www.foods.com. The DNS IP address resolution (see Chapter 6) would direct requests for any of these three domains to your single NT IIS server, but they would arrive at the server with different IP addresses. IIS chooses the home page based on the incoming IP address, which depends on the domain name you use.

If you don't specify an IP address when creating an entry, it's available to every IP address configured for the server. In our example with books and foods above, that means that you could share the /scripts directory and use the same shopping-cart program for both virtual servers. Of course, you could also create separate /scripts directories if you preferred.

URLs are showing up everywhere nowadays—business cards, TV commercials, cereal boxes—and it's good to keep them short so that people can remember and type them. Usually, that means you don't want to give people any more than a domain name and one extra thing tacked on the end of it, like "https://www.winmag.com/reclist." If you make users type "https://www.winmag.com/library/current/reviews/reclist," they'll inevitably type it wrong. From a site administration standpoint, though, the one-level hierarchy can be a nightmare for a Webmaster to manage.

That's where virtual directories come to the rescue. These let you create a directory that appears to be just one level below the domain name when used in a URL, but can actually be located anywhere—deep in a directory tree, on another hard disk, on a CD-ROM, even on another system on your network! Figure 7.1 shows the dialog you get when you create or edit an entry in the directory list.

You should think the implications over carefully before using a networked virtual directory because of its security implications. The other directory choices use the privilege of the default IIS account or prompt users to enter their own account information. With a networked virtual directory, you enter the user name and password that should be used to log into the remote system; the privilege of the browsing user is irrelevant. Note, however, that the system containing the files must still be in the same NT domain as the system running IIS.

User Accounts IIS security is completely integrated into the security of Windows NT. The user names and passwords you use for IIS, including that of the default user, must be defined in NT's User Manager. If you are using IIS for an intranet server, this type of setup is excellent and offers good security with almost no effort on your part.

If, however, you are creating an Internet server that may have thousands of registered users, you'll probably want another layer of software to maintain and validate user logons. Otherwise, the information for thousands of users will be stored in the User Manager database, and whoever manages this database will have to be given administrative privileges for the entire system. Most UNIX-based servers handle Web-based accounts with a file that's separate from system accounts, and IIS will probably get this option in the future from either a third-party vendor or Microsoft itself.

In order to integrate with the standard Windows NT security scheme, the IIS service runs with the privileges of a special NT user account. In a typical Web and FTP server setup, most of the pages will be accessed without the user (of the Web browser) having to identify themselves or know a password; this is called anonymous logon. The installation program automatically sets up a special anonymous user account for IIS, which is named IUSR_systemname by default. Web pages should be readable by this account (and scripts should be executable) if you don't want the user to be asked for a password. For FTP access, users should log in with the name "anonymous." (Web browsers quietly do this for you when you specify ftp as the protocol.)

The username and password you specify for anonymous logon must be for an account (user) that already exists. IIS setup does this for you for the default account, but if you change the anonymous logon information, you'll need to do it manually, using NT User Manager. IIS doesn't define the account; it is used only to log on. Passwords, permissions, and restrictions for the account must be defined in NT's User Manager by someone with administrative privileges, just as for other accounts.

In a higher-security Web server, you can control access to individual Web pages or FTP directories based on the privileges of corresponding NT user accounts. (Note that users who want to log on through the Web or FTP services must be granted the Log on Locally right for the NT Server hosting IIS set in User Manager, Policies/User Rights; this is the default for the account IIS sets up.) If you want users always to log on before receiving any pages from this server, uncheck the Allow Anonymous option under password authentication. This is particularly useful in the intranet situation in which users will already have a valid user account for the domain where IIS resides.

IIS supports two kinds of authentication for passwords. The first is Basic, which sends both the username and password to the network in plain text. Basic authentication is a bad idea on the Internet, because people can attach a packet sniffer to the Internet and capture this information.6 By capturing the logon packet, they can determine the Internet address of your system and a valid account they can use to attack it. Fortunately, basic authentication can be made more bulletproof through use of the Secure Sockets Layer (SSL) protocol, described later in this chapter. SSL encrypts messages so that they can't be easily decoded, even if they're captured by a packet sniffer. If you decide to use Basic authentication, SSL is essential for any semblance of security.

Windows NT Challenge/Response, the second type of authentication, is more secure because it doesn't send the actual password over the network. However, at present only Microsoft's Internet Explorer supports Challenge/Response authentication. If you want Web users who have another browser—for example, Netscape Navigator—to be able to see your pages,7 you must use Basic authentication. For intranet use, where you can control what browser is used, though, NT authentication may be the best approach.

Running the Installation The basic IIS setup is integrated into NT setup; you can just run setup, and somewhere around the middle of the process it will prompt you for the installation locations for the IIS files. If these are new directories it will also prompt you to create them. You can later change just about any of the setup decisions you make here, by either re-running setup or just changing some parameters in Internet Service Manager.

If you want to add or remove parts of IIS after the initial installation, select the "IIS Setup" item in the Start menu's Microsoft Internet Server folder. Unless you have a special need for it, remove the Gopher service to save space (see Figure 7.2).

The final step in your installation should be to go into Internet Service Manager and disable any services you don't plan on using immediately. Because most people plan to use the Web but not FTP or Gopher, disable the latter two if you installed them. Disabling them will prevent any security problems that might arise from having these services enabled but not configured properly.

Internet Service Manager

Microsoft offers two versions of the Internet Service Manager (ISM). The first is a standard Windows application, located in the Start menu's Microsoft Internet Server folder (see Figure 7.3). It lets you administer any IIS or PWS server connected to your network, as long as you have an account with administrative privileges. The version of ISM that comes with NT Server can search for IIS servers on your network; the NT Workstation version of ISM requires that you enter the server name explicitly.

In addition, Microsoft offers a second version of ISM that you access through a Web browser. To start the HTML version of ISM, launch Internet Explorer and type https://servername/iisadmin. (If you're logged onto the IIS server system, use localhost as the server name.) The HTML version of ISM is functionally identical to the Windows version, with a few user interface compromises to accommodate the limits of HTML. Figure 7.4 shows a typical screen from the HTML version of ISM. The remainder of this section shows screen shots from the Windows version of ISM, but the same features are available in the HTML version. The Windows version provides some useful security warnings that the HTML version does not, so you may want to use the Windows version until you're comfortable with IIS.

In this section, we cover the configuration of the Web and FTP services in detail. The Gopher service has essentially become obsolete, replaced by the powerful Web search engines and indexing sites. For in-house indexing of your Web content, see the section on Internet Search Server (Tripoli) later in this chapter.

Web Service Configuration

Service Tab Most Web servers use the standard TCP port value of 80, which is also the port value that is assumed by Web browsers unless you specify another port in the URL. (A URL that specifies port 2000, for example, would look like https://www.server.com:2000/test.) Changing the port value has implications for NT's packet filtering and for router and firewall traffic, so if you decide to use a port other than 80, coordinate the change with the administrator of your network equipment. See Figure 7.5 for the Service tab.

The connection timeout lets IIS clean up connections that aren't closed because of a protocol error. The default value of 900 seconds (15 minutes) is fine in most cases. Similarly, you aren't likely to need to change the maximum connections value from its default of 100,000.

The rest of the information in this property tab is related to user accounts; these issues were covered in the previous section.

Directories Tab You'll find many interesting features inside the directory options dialog box (see Figure 7.6). We focus first on the easy activities.

Usually you will want to check the Enable default document option, which provides a default document name if you specify only a directory. For example, it's more friendly (and easier to remember) if your Web site is "https://www.mycompany.com" than "https://www.mycompany.com/default.htm." If you're moving content over from another vendor's Web server, you may encounter default documents named "index.html." Otherwise, it's probably best to stick with the standard "default.htm."

Most of the time you should leave the Directory Browsing Allowed option unchecked to increase security. If you check this option and there isn't a default document in the URL the browser specifies, the server will return a listing of the files in the directory at that URL. This may include files that aren't linked into any HTML pages, such as backup files, or pages that aren't ready for public viewing. Although it might be convenient to have this feature in a few directories (especially download directories), IIS allows you to configure it only on a site-wide basis, so it's best to leave it off.

The advantages of using virtual directories were discussed earlier in this chapter; here we discuss the settings. The Directory Properties dialog box (Figure 7.7) lets you give the files in a virtual directory Read access, Execute access, or both. But it's a bit more complicated than that. Regardless of how you set these two check-boxes, the privileges granted to people requesting the file will additionally depend on the file's NTFS privileges for the user accounts under which they are logged in. For anonymous access, that will be the default IIS user account, IUSR_systemname.

Let's assume the default IIS user has the appropriate NTFS privileges for files in the directory you're setting up. And let's say a browser (user) using anonymous access requests a file in this directory. If the Execute access box is checked, IIS will first examine the requested file name to see if its extension matches one of the ones it knows how to execute as CGI or ISAPI-DLL applications. If the extension is on this list (say it's an .EXE file), IIS will try to run the associated command. If this file isn't executable (for example, it's an HTML file) and you have the Read access box checked, IIS will read the file and send it back to the browser. Even though the operating system obviously has to read the file to execute it, Execute Access doesn't require you to check the Read Access box!

Because either or both of these boxes can be checked, you can have a directory that is strictly executable, strictly read, or a mixture of both. (You could also check neither of the boxes, but we don't know of a good reason to do that.) The most secure approach is to avoid mixing content files such as HTML with program files such as EXEs and DLLs. This is especially true if many people will be creating content on the server. By having someone responsible for a set of directories exclusively dedicated to program files, it is much easier to track and control them.

Incidentally, the Read and Execute access properties apply not only to the top-level virtual directory, but to any of its physical sub-directories. Particularly in the case of executable files, you can use this feature to help you organize programs in a consistent way. Notice that the default installation of IIS takes advantage of this in the /scripts directory; the IIS administrative scripts are kept in a separate sub-directory.

The final check-box in the Access area is Require secure SSL channel. This option will be available only if you have installed one or more keys for use with Secure Sockets Layer. See the section on SSL and Key Manager later in this chapter for more information. If this box is checked, access to the directory will be allowed only if the browser can establish a Secure HTTP connection to the IIS server.

Logging Tab With the Web service, you have two choices for the format of log files (see Figure 7.8). Microsoft calls the first one standard format, which is compatible with the log files produced by IIS 1.0. The second is NCSA format, and this is the format used by most other Web servers that run on UNIX or Windows NT. At present, there is much more third-party support for NCSA log format than for IIS standard format. IIS uses a different file-naming convention for the two file types, so you'll always know the log file format by looking at the filename. When you switch log formats, IIS will close the old log and open a new one on the next hit to the server; one log file never contains both formats.

It's a good idea to have IIS automatically open a new log every day so that you can take the previous day's log file for off-line analysis and processing. Be aware of one complication, though. IIS doesn't open a new log file until the day has changed and there's a file request (hit) made to the server. So, if IIS doesn't get any hits for an entire day, there won't be a log file for that day. You might see that situation in a company intranet over the weekend, for example. If your server isn't very busy, just be prepared for a day with no log file, particularly if you write scripts to automatically process log files.8

IIS offers the option of logging directly to an ODBC database (PWS does not have this option). Because of the overhead of making a database entry for each hit to the server in real time, Microsoft recommends that this option be used only for lightly loaded servers. As far as flexibility goes, it's usually best to create an ASCII log file. If you want to enter the data into a SQL database later, you can do it with a program that parses the log file and enters the records into the database in a batch. This could be done in the middle of the night when the load on your server would presumably be much lower.

Advanced Tab IIS lets you fine-tune access to the server through the options in the Advanced tab (PWS on NT Workstation does not offer these options). See Figure 7.9.

Typically, you would set the default here so that all computers will be Granted Access. In a high-security network, you could reverse the situation and deny access to everyone but the IP addresses (or address ranges) you list.

Using the IP address as a security filter is less than bulletproof. First, it is possible for someone to forge an IP address, so don't ever use this as your only security mechanism. Second, many sites are using dynamic IP address assignment (see the section on DHCP in Chapter 6, for example). If you try to filter out one particular person's IP address because of some suspicious or annoying behavior on your Web site, that person may have a different IP address by the next day.

There is a way to specify a group of IP addresses. In the exceptions list dialog, select "Group of computers" and enter the IP address and subnet mask for the range you'd like to filter. For example, let's say your competitor was Acme Corporation and you wanted to deny its employees access to your Web site. If Acme had a Class C address of 192.14.30.0, you could enter that address into the exceptions dialog box with 255.255.255.0 as the subnet mask. Remember, though, that this would not prevent Acme employees from reaching your site through a different route, such as America Online.

The second option on the Advanced tab is the Limit network use... option. This option is echoed in the FTP and Gopher dialogs as well, but is really the same number no matter where you set it. It is used to control IIS resource use on a server that is shared with other services. See the section "Performance Tuning" later in this chapter for more information.

FTP Service Configuration

Service Tab The default TCP Port of 21 is typically the value you'll want to use. Changing the port value has implications for NT's packet filtering and for router and firewall traffic, so if you decide to use a port other than 21, coordinate the change with the administrator of your network equipment. See Figure 7.10.

Keep the Connection Timeout at 900 seconds. The Maximum Connections default of 1000 is fine unless you're concerned about excessive load on your server. For more discussion, see the "Performance Tuning" section below.

As with the Web, the most common way to use FTP is through anonymous connections. In this process, a user logs on to the FTP server with the user name anonymous. By checking Allow only anonymous connections, which is the default, you can prevent users from logging on using their NT user names and passwords. This is important because the FTP protocol sends plain-text passwords through the Internet. It would be possible for an attacker to steal this information by placing a packet sniffer on the wire. As mentioned in the Choosing Services section earlier in the chapter, a Web browser is a safer alternative to FTP for authenticated and secure logons.

You can view current FTP sessions by pressing the Current Sessions button. Most connections will be from anonymous logons, so the most useful information will be the IP From address and the connect time. This screen doesn't show what file is being transferred, but the log file will have an entry for each file transferred.

Messages Tab On most browsers, the Welcome Message is displayed before the directory listing at the root directory (see Figure 7.11). You can use this for quick reminder or update messages like "The latest version of DingBat is 4.02. Be sure to check the README file before trying an install." The Exit Message will typically be seen only by people who use a command-line FTP client, so don't put anything there that you actually want most people to see. If you have a busy site, it's good to give some hints in the Maximum Connections Message like "Try us between 5:00 p.m. and 8:00 p.m. EDT, when we're not as busy."

Directories Tab As with the Web service, the directories tab lets you create virtual directories that provide access to other directory subtrees, devices, or network shares (see Figure 7.12). When you create a new directory in this dialog box, it appears to the remote FTP user to be located under the FTP root directory. For anonymous logons—the most common case—the permissions of the default user will determine what access is given to the directory. One exception is when the directory is a network share on another system. In that case you provide a user name and password to log into that system, and its permissions are used.

Remember never to share a writable FTP directory associated with the Web service. That would allow anonymous users to create Web pages on your Web site! This isn't a good idea at all, for reasons outlined later in the chapter.

Although IIS gives you a choice between the UNIX and DOS formats for listings, it's best to stick with UNIX because some FTP clients and Web browsers expect to receive this format and don't work well if you send them another format.

Logging Tab With the logging tab you can set whether activity of the FTP service should be logged and which directory should be used for the log file (see Figure 7.13). It's a good idea to keep a log, because it can tell you what files are most popular at your site. Logs can also be used to detect intrusions. A discussion of log files and how to analyze them follows later in this chapter.

Advanced Tab FTP's options in the Advanced tab are exactly the same as the ones offered in the Web service; you will find them described above.

IIS Administration

Once you have IIS up and running, you'll be dealing with day-to-day embellishments and maintenance duties. This section outlines procedures and tools for dealing with many of these common chores.

Log Files All the IIS services provide the option of logging their activity. Log files can provide valuable information about your Web site because they tell you what data is being accessed. Knowing what data is being used by your visitors, you can concentrate your design and development efforts to improve that data. Or you can encourage visits to the quiet parts of your Web site by placing links on the frequently visited pages. Log files can also tell you who is and isn't coming to get the information you offer.

Log files can also be used as part of a security auditing procedure, which is particularly important if you make use of CGI programs or other server-side applications. Any program executed by the server as part of a URL will be logged, and you can analyze the logs for suspicious-looking queries or program arguments.

IIS's handling of log files for the combination of Web and FTP services is a bit confusing but flexible once you understand it. The locations of log files can be configured separately for each service; they don't need to be the same directory. In the default setup, the Web and FTP services use Standard log format, and both Web and FTP events are logged in the same file, with a tag that tells what service made the entry. Standard log files are named in *YYMMDD.*log indicating the date that the log was started. The format of Standard log files is described in Microsoft's HTML-based documentation for IIS (/iisadmin/htmldocs/07_iis.htm).

If you switch the Web service to NCSA log format, the Web service will write its log entries to a file named NCYYMMDD.log. However, the FTP service will continue to write its entries into the Standard log file; there's no NCSA format for the FTP service. Microsoft doesn't document NCSA format, and a search of the Internet surprisingly didn't turn up a definitive document somewhere. Fortunately, the basics are easy to tell if you look at a few entries. The fields are:

• The requester's IP address

• A dash ("-") for a parameter we couldn't document

• The user name, but usually a dash ("-") for anonymous access

• Date and time of the request, enclosed in brackets

• The HTTP request in quotes

• A status code

• Size of the response packet, usually the size of the requested file plus overhead

  The status codes you're likely to encounter are:

200	OK, successful transmission.
302	Redirection to a new URL. The original page has moved.
304	Use local copy. This tells the browser to use the copy it cached; the server does not send the file again.
401	Unauthorized access. Invalid user name or password entered.
403	Access denied. (For example, trying to read files in the /scripts directory if you have Read access turned off.)
404	Not found. The requested URL doesn't exist.
500	Server error.

If you enable log files, be sure to make enough disk space available for them. On a busy server connected to a T1 line, the log file for a single day's worth of activity can be over 50MB! If you're running a sleepy intranet, on the other hand, you probably won't have log files bigger than a few hundred kilobytes per day. As a conservative guess of the size of your log files, figure that each access to a Web page will generate about 1KB of log file entries. (There's a log entry for the HTML page itself, plus an entry for each graphic, sound file, or Java applet on the page.) If your company intranet serves 50 employees and each loads 20 Web pages over the course of a day, that would equate to a log file of about 1MB.

Once you've created a log file, you'll want to analyze it. Because the files are just plain ASCII, you can do some simple analysis by loading the log file into WordPad and searching for a particular file or IP address. That's a bit tedious, though, so you'll probably want to get a program to parse the file and generate reports. There are plenty of tools for analyzing log files; many are available free on the Internet. For an extensive list, see (https://www.yahoo.com/Computers\_and\_Internet/Internet/World\_Wide\_Web/Servers/Log\_Analysis\_Tools).

Typical reports or graphs that you can derive from log files include:

• Total hits (access to any file)

• Total visits (multiple accesses by the same IP address)

• Hit counts for individual files or directories

• Number of hits from each visitor (IP address)

• Traffic patterns by time of day

IIS/PWS also supports a set of NT Performance Monitor counters, which provide a tremendous amount of detail (the actual number of bytes sent and received, number of connections broken out as anonymous and non-anonymous, how much of the data was kept in cache, etc.). Tracking this information can help in performance tuning and maintaining your server. See the section on performance tuning later in this chapter.

Secure Sockets Layer IIS supports encrypted communication with Web browsers via the Secure Sockets Layer (SSL) protocol. To use SSL, you must obtain a security certificate specific to your server and your organization.

There are multiple steps to the process of getting a security certificate, and it takes at least a few weeks before you have a certificate that's ready to use. That's because the certificate authority (CA) needs to check out your organization to see if it's legitimate and to record information in case there's ever a dispute about the authenticity of your messages that have been encrypted by SSL. The certificates are usually good for one year; there's a fee for both the initial certificate and the renewal. The best-known CA is VeriSign (https://www.verisign.com), but many new companies are coming on-line as the awareness of security issues increases.

We obtained a demonstration certificate free from Nortel/Entrust simply by visiting its Web site (http:/www.nortel.com/entrust). The next day the certificate arrived via electronic mail, allowing us to test SSL without the expense of obtaining a truly verified certificate. New CAs are likely to offer similar deals that let you test out the technology. A good place to check is Yahoo, https://www.yahoo.com/Business\_and\_Economy/Companies/Computers/Software/Systems\_and\_Utilities/Security. If you go to Internet Explorer 3.0 and select Tools/Options/Security, you can find a list of CAs there as well.

Here are the steps you take to create a certificate:

• Run Key Manager from the Microsoft Internet Server group (see Figure 7.14). Select the WWW service and choose Key/Create New Key from the menu. You'll be presented with a dialog box with information about your company and this server; note that the certificate is good for only this server and is linked to a specific IP address. Fill this in, and then create a (good!) password for your certificate. When you click OK, Key Manager creates a certificate request file (by default named c:\new key.req) that is your public key information. It's a text file; you can look at it, but it's just the ASCII representation of your original information, all hashed up.

• Send your key request file along with your application to a certificate authority (CA). The CA will require other information in addition to what you filled out in Key Manager. At minimum it will want to know the name and phone number of a contact at the company and of course how you intend to pay. Then wait a few weeks.

• After the CA has checked you out, it will send you the security certificate. This is simply another ASCII file with the hashed information. Open Key Manager again, select the key you created a few weeks before, and pick Key/Install Key Certificate from the menu. Key Manager will prompt you for the password you entered when you created the key, and the security certificate should now be installed.

Once you've installed a default security key, browsers can access your site via Secure HTTP protocol by typing https:// instead of https:// in front of the URL. Typically, you'd put these references into your page so that users wouldn't need to be bothered with remembering the difference. If you want to absolutely require that SSL be used with some or all of your pages, go the Directories tab of the Web service in Internet Service Manager. For each directory in which you want to require SSL, edit the properties of the directory and check the "Require secure SSL channel" box.

Perl and CGI Many day-to-day tasks involve repetitive work like changing information in some large set of files at your site or looking for certain patterns of usage in log files. It's certainly possible to write Visual Basic or C++ programs to do this kind of work, but it often takes nearly as long to write the program as it does to do the work by hand. What's needed is a programming language that can handle these tasks without a lot of lengthy setup and tedious programming work.

Perl is that programming language. Born in the UNIX community, Perl was designed for just the kinds of text-processing tasks you'll find yourself doing as a Web site administrator. Many good Web-related utilities are written in Perl, so you'll at least want to have a copy of the Perl program so that you can run them. After seeing what Perl can do, you'll probably want to try your hand at some programming as well.

You can get the latest set of executable files for NT Perl at https://www.perl.hip.com/. Two versions are available. One is a standard executable that can be used either for CGI applications or for standalone programs. The other version is an ISAPI DLL that you can use as a more efficient alternative to CGI programs.

ISAPI programs and CGI programs Many of the interesting activities you can do with a Web site depend on running a server-side program that can process requests from browsers. IIS supports two interfaces for running a program. The first, Common Gateway Interface (CGI), is a standard developed early in the evolution of the World Wide Web. CGI defines how information is passed from the browser to the server. A CGI program is an executable file or interpreted file such as Perl scripts. Information is usually passed to the program as part of the URL-like command-line arguments, but HTML forms can also use a method called POST that passes the information through the standard input file handle.

Microsoft has defined Internet Service API (ISAPI) applications as a higher-performance alternative to CGI. ISAPI applications are implemented as dynamic link libraries (DLLs) that run in the IIS address space, but otherwise the calling convention is the same as that for CGI programs. Here's the important difference: instead of starting and running a new copy of the program each time it's called from a URL, IIS loads the DLL once, keeps it in memory, and just passes the new arguments for each URL invocation. This makes ISAPI significantly faster than CGI.

Security is extremely important with ISAPI and CGI programs. In essence, you are letting Web users send you a command line to be run on your Web site.9 If you don't check the input to these programs carefully, an attacker can easily break into your system. Be wary of getting an EXE (or DLL) file off the Internet and putting it into your programs directory. It's better to get the source code, understand what it does, and compile it yourself. Perl programs also offer a bit of reassurance, because you can see the source code. If you install commercial programs where you don't have the luxury of source code, check the vendor's Web site frequently for information about security-related bug fixes.

Only the virtual directories that you have marked with Execute access in the Web/Directories tab of Internet Service Manager can be used to hold CGI or ISAPI programs; by default the only program directory is /scripts. For security reasons it's better not to mix data files and programs so that you can keep a close eye on exactly what programs can be run on your server.

At installation, the only file extensions that are supported are DLL, EXE, and IDC files. (The IIS documentation says .BAT files are supported too, but they are disabled for security reasons.) You can add associations for other types of files by adding them to the IIS script map. For example, if you want to run Perl programs directly, you need to create an association for Perl script files. This must be done in the registry editor:

1. Start/Run REGEDT32.EXE.

2. Drill down to HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \W3SVC \Parameters \ScriptMap.

3. Add a new key of type STRING. The name of the key should be the name of the extension you want to map. For example, you would typically use ".pl" for Perl files.

4. Set the value of this key to the name of the command that should run when this type of file is encountered. For Perl used as CGI it would typically be "c:\perl5\perl.exe %s %s" or wherever you've installed the Perl executable. (The first %s is for the program name, and the second is for any arguments that might have been passed through the URL.)

   Warning: Under no circumstances should you put an interpreter (such as PERL.EXE) in the scripts directory! This creates a serious security problem, because any user in the world can then run the interpreter and pass it an arbitrary program as command line arguments!

Another IIS quirk may lead you to think you have to make the scripts directory readable when you really don't. (You really shouldn't—it's a security hole.) Let's say you mistype the command string that's associated with the extension when you enter it into the registry. When IIS tries to run the program, it will get an error. In this case, IIS then tries to read the file and return it to the browser as straight text. If you have (wisely) turned off Read access to this directory, IIS will complain that it can't read the file instead of telling you that the registry string is incorrect.

ISAPI Filters With a CGI program or ISAPI program, the browser makes an explicit call to the program via a URL. ISAPI filters are different because they do their work without any specific action on the part of the browser. As IIS processes requests from browsers, it passes the requests to any installed ISAPI filters so that they can process the file as well. Writing an ISAPI filter requires quite a bit of programming expertise; the basics of ISAPI are covered in Appendix 1.

Server-Side Includes The IIS Web service permits a form of server-side include file that lets you have the contents of one file inserted into another automatically. This is similar to the include-file feature of languages such as C. To use this feature, place the text

 <!--#include file="FILENAME" -->

at the point in a HTML file where you want this second file's content to appear. The file name is treated in URL style and uses the virtual directories you have set up, so the filename should use forward-slashed names rather than DOS style. By default, files must have the extension of .stm before IIS will process them for include directives. If you want all HTML files in your site to be processed for includes, you can edit the registry key HTML\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters\ServerSideIncludesExtension and set the extension to ".htm" instead. Notice that the text of an include is actually an HTML comment. If the include doesn't happen for any reason, it won't be part of the visible text in the browser, but you will be able to see the include comment if you view the HTML source code.

Processing files for includes does cause a bit of a performance hit, but it's handy when you decide that the common site header in every one of your 200 HTML files needs to be changed. As an alternative, you might try the include bot feature of Microsoft FrontPage if you've elected to manage your Web content that way. You can also use Perl scripts to manage and globally change the content of files in lieu of using server-side includes, but you'll need to apply extreme discipline so that the common text has a consistent pattern you can find.

IIS does not support a feature called server-side execs that's common in many UNIX-based (and non-Microsoft NT-based) servers. With this feature, you can execute commands of the form

 <!--#exec cgi="command_line" -->

and the command line will be executed. Whatever output results from the command line will be included on the page at the point where the exec command was located. If you're trying to port existing Web content that uses server-side execs, it's best to figure out exactly what the page designer was trying to accomplish. Often there will be other equally acceptable ways to do the job, although some of them may require significant redesign.

Although server-side execs are powerful and convenient functions, they present a massive security risk. For example, if a user's input is used as part of the output of an HTML page, that user could potentially type in exec commands as part of their input and get your server to execute them. This might be a particular danger in the case of a guest book or bulletin-board-like discussion forum implemented as Web pages.

Internet Search Server (Tripoli) At the time this book was being written, Microsoft was beta testing its Internet Search Server product for IIS, code-named Tripoli. Although it wasn't in finished form, the beta was available for downloading at Microsoft's Web Site, and it looked very promising. Tripoli lets you easily create a searchable index page for your Web content. The search uses an automatically updated index so that the actual searches are fast, even for large sites. When Tripoli is complete, Microsoft will make the final version available on its Web site.

Tripoli is managed by a set of Web pages, similar to the HTML version of Internet Service Manager. These let you control what parts of your Web site are indexed. You can schedule index generation at regular intervals, presumably during your Web site's slack periods. Tripoli also adds statistics that you can track in Performance Monitor, so you know the impact of search requests on overall performance.

Performance Tuning Microsoft has integrated the most important IIS statistics into NT's Performance Monitor, so it's easy to track the IIS effects on overall system performance and the relationship to other work the server may be doing. Figure 7.15 shows a sampling of the IIS-related information you can display in Performance Monitor (see Chapter 3 for a description of Performance Monitor and Chapter 5 for hints on its use).

In the case of an Internet-connected server, the speed of your connection to the Internet is likely be the most limiting factor. Even a T1 is only 1.5 megabits per second, or about 200KB per second at best. A BONDed ISDN line gives you a top-end throughput of only 16KB per second. So bandwidth is already limited enough in these cases. For an intranet, on which Ethernet speeds are typically available, IIS could potentially soak up a lot of server CPU time and network bandwidth. Limiting IIS network use will prevent an impending crisis, but it's an indication that either the server or network bandwidth is overloaded.

Internet Service Manager's Web, FTP, and Gopher dialogs all offer an option titled Limit network use... in their Advanced option tab. (This applies to IIS only; PWS doesn't have this option.) The limit that you set in any of those three places affects the total combined bandwidth used by all three services. This type of restriction is most useful if you're sharing the server with other services that you don't want to be overwhelmed by IIS if demand becomes high, such as a primary domain controller, file services, or SQL server.

Using Performance Monitor, you can monitor total bandwidth being used by IIS to find an appropriate cutoff level. Start Performance Monitor and select Edit/Add to Chart from the menu or click the plus sign on the toolbar. For the Object, select Internet Information Services Global; for the counter select Measured Async I/O Bandwidth usage. Measure the performance during a typical load period. To have any impact on the overall server performance, you'll need to choose a limit that is lower than the peak bandwidth usage during this period.

If you're providing large files for downloading, FTP sessions can cause quite a load on your network bandwidth and create slow response time for Web users on the same server. Again, you can use Performance Monitor to determine a reasonable restriction to FTP sessions that give Web users a fighting chance at bandwidth. Monitor the FTP Total Bytes/sec and FTP Current Connections counters, along with the IIS global counter for Measured Async I/O Bandwidth, HTTP Connections/sec, and HTTP Total Bytes/sec. If Web response seems unacceptably slow, go to ISM and set the FTP connections below the current value. If you're impatient and feel like being cruel, knock a few sessions off immediately; if not, you'll have to wait until they finish normally to see the effect of fewer sessions. If FTP sessions were hogging the line, you should see HTTP bytes/sec and connections/sec increase.

If you offer a lot of database or other CGI programs on your site, it's possible that network bandwidth won't turn out to be the limiting factor. This may become more common as more sites turn to online-database technology and active server-based content. In such cases, the server limits are likely to come from using up the CPU power or saturating the disk bandwidth. You can detect both of these problems by monitoring % Processor Time for the CPU and % Disk Time separately for each disk drive (see Chapter 5 for details). If any of these numbers push up toward 100% for more than a brief spike, you have a bottleneck.

Security

Although security issues have been discussed in conjunction with many of the Internet features of NT described already in this chapter, this section looks at the bigger issues you'll have to address when connecting a server to the Internet.

Here is the most important thing to remember: You are connected to the world! It's easy for your employees or customers to connect to your site through the Internet, but it's just as easy for a hacker halfway across the world to connect, too. Or perhaps the person who wants to break in is a business competitor who would find the information useful. Either way, you want to keep the "bad guys" out.

Why Worry?

Quite often, the first reaction to the issue of Internet server security is, "The worst thing that can happen is someone would crash our server; we don't keep important information on it." But think again, because the consequences of someone hacking into your server can range from inconvenience to catastrophe:

• Misrepresentation: An intruder may place files on your Web server that make false, slanderous, or misleading statements. For example, in an investment advisory service, the intruder could create a Web page with a phony "buy" recommendation for a stock. Or, the hacker could forge electronic mail messages that appeared to be from someone within the company. Suddenly, your mishap on the Internet has turned from a computer problem into an expensive legal one.

• Loss of confidential or proprietary information: Valuable information would obviously include customer credit card numbers if you do online commerce, but it could also include mailing addresses and purchase records. If you let customers upload data to your server, that data can be a target as well. If you keep early draft versions of sensitive Web pages on the server, an intruder could see those pages before a public announcement. Even your own Web server logs may be valuable to competitors, because they show what data is being accessed at your site.

• Use of your system for "warez" distribution: When hackers find an FTP server that accepts uploads, they will put pirated software on the server for downloading by others. If you don't maintain control over public directories, your site may become a haven for illegal software distribution, exposing you to another legal risk.

• Denial of service: Your server could crash or be so overwhelmed by the intruder's acts that it doesn't respond to legitimate requests. Given the legal and financial implications of the other options, this is probably about the best thing that can happen. And having your Web site taken out of commission is not so good.

You must build a good defense into your Internet server because it's nearly impossible to find and prosecute someone who breaks in electronically. It's too easy for people to cover their tracks on the Internet. Even if you do track down the culprit, the laws on computer crime aren't well tested. Worse, if the person isn't even in your own country, you'll end up dealing with a maze of international laws and treaties.

Intruder Attacks and Countermeasures

Just about every attack on a system can be traced to a handful of causes that, either alone or in combination, allow the attacker to penetrate a system. By exploiting known problems with software, and with the help of sloppy system administration, intruders are likely to be able to break into just about any system if they're persistent enough. If you're vigilant, you can make the job tough enough that most potential intruders will decide to find an easier target.

Known Software Problems All software has bugs. In the case of the Internet, those bugs can sometimes be exploited to break into your system or disable it in some way. The most famous software problem in the history of the Internet is the Morris Internet Worm incident in 1988; it was the first time that many in the general public had even heard of the Internet.

Most Internet security problems today are related to the UNIX operating system. There's nothing particularly wrong with UNIX that isn't also a problem with other operating systems. It's just that people have had 20 years, often with OS source code in hand, to probe the security of UNIX. In addition, most versions of UNIX include a wide variety of Internet services; each is another opportunity for bugs and security holes. Most of the problems are fixed in new shipping versions of the operating system. But even when bugs are fixed, many sites don't upgrade. Those sites can become targets for future attacks.

Even though UNIX has a strong lead on security problems, NT and IIS seem to be trying hard to make up for lost time. Since its original release in January 1996, for example, IIS 1.0 has had three patches released that fix various security-related problems. Two of these involved a problem with the execution of batch files that would easily let anyone in the world execute any DOS command on your server! (This same problem was also found—and fixed—in other NT Web servers, including Netscape's.) In IIS 2.0, the installation default that allowed you to run batch files as common gateway interface (CGI) programs has been removed, although the documentation erroneously indicates it's preinstalled.

As NT increases in popularity, there will be more people probing its problems and a larger base of knowledge on its weaknesses. The best defense is to keep up with the information released by Microsoft and the third-party vendors of your products. Whenever a new patch or update is available, find out if there are any security-related problems that it fixes.10

Programming Errors Operating systems and Web servers have their problems, but often the worst threats to security come from locally written CGI programs or ones written by inexperienced programmers and distributed over the Internet. Many of these programs don't validate the arguments that are passed to them in any way, and people who manipulate the input to these programs may be able to obtain files or information they shouldn't be able to access.

For example, let's say you install a CGI program called DISPLAY.EXE that generates an HTML page based on an input file that's specified as an argument to the program. A call to your CGI program might look like something like "https://www.acme.com/scripts/display.exe?test.dat." The program works fine and the formatting looks beautiful, so you make your new Web page available and go home.

Later that evening, someone comes to your Web site and sees you're using this new DISPLAY.EXE program. He also notices the argument looks a lot like a file name. And unfortunately for you, this program doesn't check for suspicious input. After a few false starts he types "https://www.acme.com/scripts/display.exe?../../../autoexec.bat" and out pops your AUTOEXEC.BAT file. (Formatted beautifully, of course.) Now he knows how far up the root of the current disk drive he is, so he tries "https://www.acme.com/scripts/display.exe?../../../winnt/system32/logfiles/in961208.log," and the server starts delivering that day's log file. Now he knows who visited your site today. He can get a lot of other information the same way.

Does it seem incredible that someone could know enough to type just the right information? If you're like probably 90% of the people who install NT and IIS, you'll accept the defaults for the location of executables, HTML files, scripts, and log files, which makes breaking into the system and finding sensitive files even easier.

Each time this intruder runs the DISPLAY.EXE program, IIS puts an entry into the log file. If you are checking your log files regularly for suspicious use of CGI programs, you'll find this problem very quickly. For example, you should scan the log files for any use of the scripts directory that include the string ".." or other suspicious characters.

Sloppy Administration Between the struggle to get things up and running, the exhilaration of having them finally work, and the fear of doing something that will stop them from working, it's no wonder that many system administrators take the "if it ain't broke, don't fix it" philosophy when running Internet servers. As a result, many sites are less-than-stellar examples of security. Common errors include the following:

• Passwords: People use passwords that are easy to guess, such as "password" or their own name. They use the same password for all their accounts because it's too easy to forget different passwords for each one. NT's GUEST account should be disabled, because it allows anonymous access without a password. NT Server disables GUEST by default, but double-check to make sure it's disabled on your server.

• Inappropriate permissions: Many systems run with everyone given full access to files. As a result, someone who does break into a system, even on a low-privilege account, can do significant damage. (It's even worse if the disk uses the FAT file system, because security protections aren't even available.) Very few accounts should be given write access to files in the Web or FTP areas, and only an administrator should have the ability to install new CGI programs. It also goes without saying that NT-based Internet servers should use NTFS, which provides file/directory security, on their hard disks.

• Lack of monitoring: Both Windows NT and IIS have very good auditing and logging functions that you can use to detect intrusion. Unfortunately, people often don't use them. Many sites don't even do the simplest types of monitoring and maintenance, such as cleaning up leftover temporary files. You have to be aware of what's normal for your system so that you can detect the abnormal.

• Unused but active services: Every piece of software adds more complexity and more opportunities for break-ins. If you're using IIS only for its Web server, disable its Gopher and FTP services. The installation default, of course, is to run these services. If you don't turn them off, you've left the door open a bit.

Low-Level Attacks Data on the Internet can potentially pass through locations where someone has attached a packet sniffer to the line. That would let attackers see just what is going on between a remote client and your server. They could obtain any data that passed between the two, such as passwords or form data.

Even if your passwords are encrypted, other attacks are possible. One is "session playback." If a repeatable series of transactions occurs, for example, to log into your server, attackers can just record these actions during a legitimate session and then play them back whenever they want to attack. Another approach is to "hijack" a session as it occurs in real time. The attacker waits for the legitimate user to log in, then sends packets to the server with the valid information obtained by watching the logon process. This usually requires that the attacker intercept and block any subsequent requests by the legitimate user.

These kinds of attacks are relatively rare and also hard to set up. They require technically advanced hackers with physical access to the Internet at a point where they know your server's packets will pass. The best places to tap in are inside your own site; one company reported that it found a packet sniffer under the raised floor inside its computer room, connected to a dial-in modem line. Management suspected, but couldn't prove, that it was a night operator who worked only a few months and then quit. Unfortunately, the sniffer was only discovered six months after he left the company!

The new Point-to-Point Tunneling Protocol (PPTP), supported by NT 4.0, provides protection from these kinds of attacks by encrypting the entire message. PPTP is covered in Chapter 6. In a PPTP-encrypted message, all the attacker can see is the source and destination address. When combined with a firewall, as described in the next section, PPTP offers a very good level of protection from packet sniffing.

Creating Web Content

Editing Web Pages

Once you have your Web site up and running, the work really begins: creating the content and applications that will make people visit your site. This is true whether you're creating an Internet site or an intranet site. If you build a site with information that is useful and well organized, people will come to get it.

Microsoft includes its FrontPage Web page editing product with NT Server 4.0. FrontPage is much more than just an HTML editor, because it helps you manage the overall structure and content of the Web site. Tedious jobs like changing the look of your pages globally or catching all the references to a moved or renamed file are greatly simplified.

Still, sometimes you will want to drop into a low-level tool and edit with a tool that doesn't hide anything from you. That's especially true if you plan to make use of newer developments like Java or ActiveX. These technologies weren't quite cooked when FrontPage made its debut, so you won't get any tools or help working with these new types of active content. As crude as it sounds, we've found that Notepad is often the best tool for editing single files or making small editing changes. It's free, it's fast, and there's no learning curve.

Database Connections

IIS includes an Internet Database Connector (IDC) feature that lets you create dynamic HTML pages based on the contents of data tables. IDC is implemented as an Internet Server API (ISAPI) application that uses 32-bit ODBC to retrieve data from databases. Sample files and documentation are provide with IIS in the /samples/dbsamp/dbsamp.htm file under the location where you installed the wwwroot directory.

The basic approach of IDC is to have two files that control the HTML output. The first file has an extension of .IDC and describes the source of the data table and the fields you want to extract from it. A simple IDC file might look like this:

Datasource: Names
Username: admin
Template: names.htx
SQLStatment:
+Select FirstName, LastName
+From Names

An HTML template file, with an extension of .HTX, defines the format that is used to display the results of the data obtained when the query in the IDC file is executed. For the example above, the corresponding NAMES.HTX file might look like this:

<HTML>
<HEAD>
<TITLE>List of Names</TITLE>
</HEAD>
<BODY>
<%begindetail%>
<%if LastName EQ " "%>
<%else%>
<%FirstName%> <%LastName%><br>
<%endif%>
<%enddetail%>
</BODY>
</HTML>

The special tags enclosed in "<% ... %>" let you perform conditional actions and include the contents of fields you retrieved in the data query.

To perform the query, simply reference the IDC file in a link or as the action of a form:

<A HREF= "/scripts/names.idc">List the Names</A>

Using the examples from the IIS online documentation you can develop interactive databases that can gather information from users and store the information in a database.

Conclusion

IIS and the other Internet-specific features of Windows NT 4.0 Server (and to a lesser extent, Workstation) provide an unprecedented out-of-the-box capability to get your company on the Internet or create a private intranet. However, you must apply these features with care—or you may expose yourself to a severe security risk.

Further Reading

Chapman, Brent and Elizabeth D. Zwicky (1995), Building Internet Firewalls. Sebastopol, CA: O'Reilly & Associates, Inc., ISBN 1-56592-124-0.

Lehto, Kerry and W. Brett Polonsky (1996), Introducing Microsoft FrontPage. Redmond, WA: Microsoft Press. ISBN 1-57231-338-2.

Lemay, Laura (1994), Teach Yourself Web Publishing with HTML in a Week. Carmel, CA: Sams Publishing, ISBN 0-672-30667-0.

The Internet itself is one of the best sources of information about Internet issues. A good place to start is at Yahoo (https://www.yahoo.com) or one of the search engines such as AltaVista (https://www.altavista.digital.com). Here are a few of the best references we have found:

Internet Information Server

• news://comp.infosystems.www.servers.ms-windows

• news://microsoft.public.inetserver.iis

• https://rampages.onramp.net/~steveg/iis.html

Internet Security

• WWW Security FAQ, https://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.htm

• Windows NT Security, https://www.somarsoft.com

• CERT advisories, https://www.cert.org

Firewalls and Proxies

• Network Computing, https://techweb.cmp.com/nwc/netdesign/series.htm

• https://www.williamette.edu/~dlabar/firewall.html

FIGURE 7.1 WWW Service Properties, Directories tab. This dialog from Internet Service Manager lets you view IIS directories.

FIGURE 7.2 IIS 2.0 Setup. IIS 2.0 Setup allows you to determine which components are installed on your server.

FIGURE 7.3 Internet Service Manager. Internet Service Manager (ISM), from the Start menu's Microsoft Internet Server folder, is the primary tool used to manage IIS services.

FIGURE 7.4 ISM Web page. Alternatively, you can manage IIS from a special Internet Service Manager Web page. Note that proper security settings are vital if you are using this method.

FIGURE 7.5 WWW Service Properties, Service tab. The ISM Service tab displays and controls settings for the IIS Webserver.

FIGURE 7.6 WWW Service Properties, Directories tab. This dialog box from Internet Service Manager displays and controls IIS directories. Default pages and virtual directories can be set here.

FIGURE 7.7 Directory Properties. ISM Directory Properties is where you control who can access an IIS Web directory and whether it will appear as a virtual directory or virtual site on a Web browser.

FIGURE 7.8 WWW Service Properties, Logging tab. Logging in IIS can use either Microsoft's proprietary format or industry-standard NCSA format.

FIGURE 7.9 WWW Service Properties, Advanced tab. The ISM Advanced tab controls who is permitted access to the Web server and lets you limit overall IIS network bandwidth.

FIGURE 7.10 FTP Service Properties, Service tab. The ISM Service tab for the FTP server controls top-level settings.

FIGURE 7.11 FTP Service Properties, Messages tab. The Messages tab lets you set a welcome message for FTP users, as well as an exit message, and a "so sorry" message for users who attempt to connect when the server is already fully subscribed.

FIGURE 7.12 Directory Properties. Directory Properties for the FTP Service allows you to control access.

FIGURE 7.13 FTP Service Properties, Logging tab. IIS can log FTP activity in much the same way as Web activity.

FIGURE 7.14 Key Manager Key Manager is used to configure IIS for use with Secure Sockets Layer (SSL) for encrypted transactions.

FIGURE 7.15 Performance Monitor. IIS exports a series of Performance Monitor counters that permit performance tuning and data logging.

1 These port numbers are documented in Internet Engineering Task Force (IETF) Requests For Comment (RFC) documents, available on the Web at https://www.internic.net (start with the Directory and Database Services link on that page). WAIS searching of the InterNIC site is also available.

2 The language of the NTW 4.0 license agreement was changed for the express purpose of preventing such use, as explained in Chapter 1.

3 Internet Server API—see Appendix 1 for details.

4 As this was written (August 1996), the Gopher FAQ file hadn't been changed since May 1995. It really is a dying protocol!

5 On upload directories, consider setting write-only access. Set up a separate directory for downloads, and make arrangements to periodically inspect files and move them from the first directory to the second. This will provide some protection against warez attacks mentioned in the Internet Security section of this chapter.

6 See the "Network Monitor" section of Chapter 5 for a real-world example from a live NT Server running the IIS FTP service.

7 At this writing (August 1996) Navigator was widely reported to have an 80% or greater share of the browser market, so supporting it is probably a good idea!

8 Or, it might be easier to make someone come in and work over the weekend. (Just kidding.)

9 Indeed, Microsoft's ISAPI development kit includes an example program that literally allows a user to type in batch file-type command lines that are executed by the server!

10 Check for NT Workstation and Server patches at https://www.microsoft.com. Check the NT Workstation, NT Server, and IIS pages as needed. Another good resource for security information is the World Wide Web Security FAQ at https://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html.