I began using IIS servers about a year ago. My Web site has several IIS 4.0 servers with Service Pack 6a (SP6a) and all hotfixes applied. What else do I need to do to secure my servers?
All IIS administrators have this concern—in fact, security should never stop being a concern. Regularly reviewing all new security fixes and staying informed about new hacking and cracking technologies is part of a Web server administrator's job description.
Fixing all known problems is essential, as is keeping up with the newest Microsoft security bulletins. Because you recently installed your servers, you might have overlooked an essential IIS 4.0 fix for a problem that occurred a few years ago.
This problem centers on the Microsoft Remote Data Services (RDS—formerly Microsoft Advanced Data Connector—ADC) functionality that you install by default when you install IIS 4.0. RDS is a component of ADO. RDS contains an object called the Data Factory Object, which lets a client work directly with an ODBC data source, such as a Microsoft SQL Server or Access database.
Because RDS lets a client provide database connection information to the server, RDS is a likely candidate for exploitation. Users can exploit it to gain access to databases and execute code on the server. For this reason, taking corrective measures on any IIS 4.0 server isn't optional. To disable RDS on your system, remove these registry entries:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svcparameters\ADCLaunch\RDSServer.DataFactory
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesw3svc\parameters\ADCLaunch\AdvancedDataFactory
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\w3svc\parameters\ADCLaunch\VbBusObj.VbBusObjCls
In addition, remove the RDS by removing the MSADC virtual directory from your IIS 4.0 Default Web site. I also recommend that you delete the C:\program files\common files\system\msadc folder and its contents. At a minimum, delete the Samples folder at that path if you installed the RDS sample files.
If you want to keep RDS capabilities, you can run handsafe.reg, which resides in C:\program files\common files\system\msadc by default. Handsafe.reg enables what Microsoft calls Safe mode for RDS. Even so, some security specialists consider this utility insufficient to secure these services.
You need to be completely informed about this vulnerability if you use RDS. For more information about the vulnerability, see the Microsoft articles "PRB: Security Implications of RDS 1.5, IIS 3.0 or 4.0, and ODBC" (http://support.microsoft.com/support/kb/articles/q184/3/75.asp) and "Re-Release: Unauthorized Access to IIS Servers Through ODBC Data Access with RDS" (http://www.microsoft.com/technet/security/bulletin/ms99-025.asp). You don't want to miss http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface=2, which has the complete lowdown on this problem. To keep up with the latest security information and patches, consider subscribing to Security UPDATE (http://www.win2000mag.net/email).
I want to place a common footer at the bottom of all pages that my server sends. How can I add such a footer in IIS?
IIS 5.0 and IIS 4.0 contain a feature called Document Footer, which lets you add a footer to the bottom of your Web site's pages. You can set up this feature on the Documents tab in Internet Services Manager (ISM), which Figure 1 shows. When you enable this feature, you specify a file that contains the HTML code you want to add to the server's output. The footer file isn't a complete .html file—just the content you want to display.
Now that I've explained IIS's built-in footer capability, I'd like to explain why you shouldn't use it. First and most important, using your Web server to manage part of the content violates good design principles. You should manage content as part of the development cycle, not as part of Web server administration. By mixing Web server setup and Web site design, content management becomes a bit confusing.
Second, the Document Footer feature delivers only static content. Because IIS simply appends the footer file to the output, IIS can't parse the footer for server-side .inc files or Active Server Pages (ASP) content. Not only is the footer content static, but you can append it only to static content. In other words, IIS can't append footers to output from scripting languages such as ASP, Perl, or PHP Hypertext Preprocessor (PHP).
So, what solutions exist? If you use a tool for software development, such as Microsoft FrontPage or Allaire HomeSite, you can easily add footers to your content. These tools let you add a reference to the bottom of your pages to include a standard footer file. To change the content, you just change the footer file. You don't need to modify the original script to modify the footer.
Your only other solution is to develop a custom Internet Server API (ISAPI) filter that adds the content to all outgoing pages. This solution is the most scalable but the most difficult to develop because ISAPI filters aren't easy to code.
For those of you who develop ASP content, Microsoft's upcoming ASP.NET will have capabilities that make this kind of task much easier to manage. For information about ASP.NET, go to http://msdn.microsoft.com/library/dotnet/cpguide/cpconintroductiontoasp.htm.
I want to use Basic authentication over the Internet with IIS 5.0 to secure logons to my Web site. My company's information services manager is concerned that certain parts of the logon process can be captured, even though I use Secure Sockets Layer (SSL). I know that code-cracking technology has improved. How secure is SSL?
When a Web client attempts to access a secured resource, IIS must authenticate the user to ensure that the user has the necessary permissions. IIS supports several authentication methods, including Basic authentication. Basic authentication's chief benefit is that virtually all browsers support it. Only Microsoft Internet Explorer (IE) supports all the other methods of authentication that IIS supports (aside from Anonymous authentication). Although IE enjoys a majority of the market share, many users still use Netscape and other browsers. When compatibility with the widest possible audience is a priority, Basic authentication is your only choice.
The downside is that Basic authentication is inherently insecure. Passwords aren't encrypted but rather base64 encoded, which means that anyone who has a freeware network monitor can decode them. The standard suggestion for providing Basic authentication and secure logons is to use SSL during the Basic logon process. (For SSL-related resources, see "Related Reading.") Using SSL, the entire logon process is encrypted, so your manager can rest easily. I recommend that all Web server administrators become conversant in SSL basics to make good choices about how they should implement the protocol.
With SSL, note that you can use a network monitor, or sniffer, to capture the content of an SSL session. However, the capture is useless for all practical considerations. To make your site as secure as possible, consider these steps:
Use a large key. To enable SSL on your Web site, you must install a Web server certificate. When you create your certificate request, you indicate the key size to use in your SSL sessions. (Explaining this process is outside the scope of this article, but you can find plenty of information at http://www.thawte.com/support/server/contents.html and in the Microsoft Knowledge Base.) The larger the key, the more secure it is. The smaller the key, the faster it is. Windows NT 4.0 supports a key size up to 2048 bits, and Windows 2000 supports a key size of 4096 bits.
The big question is, "How large should the key be?" According to Michael Howard, Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press, 2000), it would take 1427 years for a 600MHz Pentium III machine to crack a 56-bit symmetric key. The numbers are astronomical for 128 bits and higher, which are in common use, but you want the costs of decryption to be astronomical compared with the value of the information. (For more information about the highly publicized multicomputer effort that cracked a 56-bit key, see http://www.distributed.net.) For most sites, a 128-bit key is sufficient. Some browsers still don't support this capability, but SSL will step down to the browser's capability unless you disable this capability in IIS.
Don't stop using SSL after authentication. A common mistake that Web server administrators make when they use SSL to encrypt Basic authentication is to disable SSL after authentication has occurred. This error is big. After authentication, HTTP sends the credentials of the Basic authenticated user to the server with every request that user makes for a resource (i.e., page) from the server. Otherwise, the user would have to reauthenticate for every new file request. If you disable SSL after authentication, HTTP sends the username and password across the network unencrypted.
Enable SSL connection logging. In Win2K, you can log SSL connection events in the event logs. To log these events, you must set the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging registry subkey to 1 (Log Errors), 2 (Log Warnings), 4 (Log Information and Success Events), or 7 (Log Everything). In addition to SSL connection logging, you can set up a troubleshooting log for tracking SSL connections. The technique for this setup isn't public, but it's available from Microsoft or a Microsoft Certified Partner.
I'm using host headers to create multiple Web sites with one IP address. Can I map a subweb (of the Default Web site) to its own site name without upsetting the root Web? For example, if the root Web is www.rootweb.com and the subweb is www.rootweb.com/subweb, I'd like to access the subweb as www.newweb.com.
This question brings up terminology that I must clarify. The idea of a subweb, as it relates to IIS, is strictly a FrontPage concept. When you install FrontPage Server Extensions on your server, you can create a FrontPage-enabled Web. This Web lets users use the FrontPage client software to create and publish Web sites to a FrontPage-enabled Web that IIS hosts. In addition to letting users create content, the FrontPage client lets users administer the Web site to a certain degree, including specifying which users are browsers, authors, or Web site administrators. When you use the FrontPage client to assign a user as a browser, author, or administrator, the NTFS permissions are adjusted on the Web site accordingly. In this way, the client software modifies NTFS permissions on the server.
Because Web sites can be large, FrontPage introduced the notion of a subweb. The idea of a subweb is to create an administrative unit that's part of the root Web but administered separately. In this way, different teams can manage different subwebs, and each team can have a unique administrative setup. In the usual setup, you can't define a subweb as a standalone Web because, as far as IIS is concerned, the subweb is just a virtual directory of the root Web. You can, however, create a new Web site and map it to the subweb Home folder. Table 1 shows the setup for creating and mapping a new Web site.
With this setup, you'll achieve your desired goal, but you might experience unintended consequences. For example, you can't use www.newweb.com as a FrontPage Web site, because this URL would confuse FrontPage considerably. Server Extensions, in conjunction with the FrontPage client, track a Web site's content and internally manage a lot of the site's metadata. As a result, if you used a subweb and another top-level domain to access the same FrontPage Web, as you suggest, FrontPage would become confused.
A second concern is that you have two complete sets of Web properties to maintain. You would have to mirror a change in one place to another place. In short, the term subweb is strictly a FrontPage invention as far as IIS is concerned; it isn't intended to infer that a virtual directory can have a unique URL.
| RELATED READING |
|
IIS Administrator IIS Informant, March 2001,InstantDoc ID 19772 Allen Jones, "SSL Demystified," December 2000, InstantDoc ID 16047 Chris Lehr, "Implementing SSL on IIS 5.0," January 2001, InstantDoc ID 16183 Netscape http://www.netscape.com—Netscape originally designed Secure Sockets Layer (SSL) and maintains a good deal of information about this protocol on its site. Microsoft William Stallings, "Web Security," http://www.microsoft.com/ technet/security/chaptr14.asp |
