Tips for IIS 4.0 and 5.0

USE SYSTEM SCANNER TO MONITOR YOUR WEB SERVER

You can make sure your Web server stays locked down by using System Scanner 1.1, a "Microsoft Windows 2000 Server Resource Kit" utility. Click the following link to learn more about System Scanner and to learn how to install the utility.

http://www.windowswebsolutions.com/articles/index.cfm?articleid=37799

WEB SECURITY AUDIT TOOL

I recommended searching your server (Windows 2000--Win2K--or Windows NT 4.0) for *.vbs. There is an amazing breadth and depth of great Windows Script Host (WSH) script on your server just waiting for IIS administrators. I promised that between then and now, I'd figure out how to enumerate the resources on a Microsoft Site Server 3.0, Membership-authenticated (Site Server 3.0 Personalization and Membership Directory Service--DS)

Web site to display the authentication for every resource that has Anonymous access.

Before I began writing the tool, which you can use to audit security on your Web sites, I had to find the Web site iteration logic on my Windows 2000 Advanced Server (Win2K AS). The logic was in the Microsoft Windows 2000 Resource Kit in listmembers.vbs (\program files\resource kit). I found the logic that returns the authentication method applied to a Web resource in Site Server in pmadmin.vbs (\microsoft site server\bin\p&m). The WSH script that I wrote, which combines the logic from both scripts, is called auditdsauth.vbs. You can download it from the IIS Administrator Web site (http://www.iisadministrator.com). I've provided this tool to a number of my clients, and it has exposed some glaring security holes that I have since shored up. The WSH script displays help about how to use it if you run it with the /h parameter (i.e., "cscript AuditDSAuth.VBS /h"), and the script is well documented within the code itself.

Anonymous access to resources on any protected area of a Web site is scary. Let me describe how the problem happens. Site Server 3.0 Membership authentication supports inheritance at the Web site, virtual directory, and folder levels. If you apply Anonymous access to the Web site itself, every file and folder beneath it inherits Anonymous access as well. If you apply Clear Text/Basic authentication then take away Anonymous access on a virtual directory or folder under the default Web site, every file and folder beneath that directory or folder inherits the same authentication method. If you apply authentication to a resource, it supercedes any authentication that it inherited. If you apply authentication to a file (e.g., an Active Server Pages--ASP--page), there is nothing downstream to inherit that authentication.

The inheritance feature is great, and being able to mix and match authentication types that supercede the inheritance is also great.

The problem is that many Web sites that you protect by forcing an authentication allow Anonymous access to their homepages. You would, of course, carefully take away Anonymous access where appropriate from each file and folder downstream before going live. But, if one of your developers later adds new features by adding a folder off the root Web site and ASP pages to that folder, the folder and those pages inherit Anonymous access from the root Web site. Even if you apply Anonymous access to default.asp and every image that it uses and take away Anonymous access from the Web site itself, users will still be challenged (prompted with a username and password dialog box) when they browse the site itself.

I've seen and developed many content-management systems, and the type of accident I describe seems to happen no matter how careful you are or how rock solid your content-management process is.

Consequently, you see the need for a tool like the one I've developed for Web sites that use Site Server 3.0 Membership authentication.

Unfortunately, because of the nature of the Internet, security auditing is a priority task for IIS administrators.

So, here's a call to action for those of you who are subscribers to IIS Administrator: Download auditdsauth.vbs and make it more robust by

1. Accepting a parameter to iterate any Web instance (instead of its current state of a hard-coded default Web site)
2. Iterating through every resource on a Web site (not just a single container)
3. Accepting a parameter to check only for resources with Anonymous access applied

IIS 5.0 ACCEPTS REVOKED CERTIFICATES

Here's a useful how-to that will help you keep your Web sites and Web pages secure. If you have built or are planning to build a Microsoft IIS 5.0 Web site that authenticates users with a certificate from Microsoft Certificate Services, you need to understand how each product manages revoked certificates. To ensure that a user has a valid certificate, you can instruct IIS to perform a realtime check for revoked certificates before IIS authenticates a user. Once you've done so, you would expect IIS to deny access to any user whose client certificate you're revoked in Certificate Authority (CA) beginning the next time that user attempts to log on.

However, Microsoft Certificate Services publishes the certificate revocation list (CRL) just once a week by default, and IIS compares client certificates to the current published CRL. Meanwhile, the new but unpublished CRL might contain additional revoked certificates.

Thus, a user might be able to log on successfully with an invalid certificate for up to 7 days after you place his or her certificate on the CRL. To eliminate this vulnerability, you must shorten the CA publication interval for the CRL. To do so, start the Microsoft Management Console (MMC) CA snap-in, open the Revoked Certificates folder's properties, and change the publication interval to 24 hours or less, depending upon your security requirements. Microsoft Support Online article Q258727 (http://support.microsoft.com/support/kb/articles/Q258/7/27.asp) documents this CRL behavior.

COMMENTARY: IIS AUTHENTICATION METHODS

Greetings, Would everyone who got a chuckle out of the alleged backdoor in Microsoft Web servers please stand up? I admit I laughed, too. I was driving to work that Friday morning when I first heard the news that a backdoor into Microsoft Web servers defiled Netscape engineers. The conversation in my carpool immediately turned to the ongoing problems between Microsoft and the Department of Justice (DOJ). We surmised that there would be a flurry of phone calls between individual states and the DOJ that morning.    However, it didn't take long before I realized that I was going to have a long and difficult morning ahead of me. As soon as I got to work, I was busy identifying which of the servers I'm responsible for actually contained the backdoor file dvwssr.dll. After the smoke cleared, the office was buzzing with which versions and add-on packages contained the DLL.    In light of this problem, I thought that this would be the perfect time to review some of the new authentication methods Windows 2000 and IIS 5.0 offer over Windows NT 4.0 and IIS 4.0. There isn't much new to report in the Anonymous and Basic authentication methods. The authentication formerly known as Windows NT Challenge/Response (also called NT LAN Manager--NTLM) is now simply called Integrated Windows authentication in IIS 5.0. This method still doesn't work across proxy servers--an ongoing source of difficulty in IIS 4.0. Microsoft alleviates that shortcoming in IIS 5.0 with two new authentication methods.    Microsoft calls the first method Digest authentication. Digest authentication requires that the IIS 5.0 server also be a Win2K domain controller. It also requires that you use Internet Explorer (IE) 5.0 as your browser. While Digest authentication is loosely based on the popular Message Digest5 (MD5) algorithm, it's intended merely as a preferable alternative to IIS's Basic authentication and the transmission of clear-text passwords. Digest authentication encrypts client-supplied passwords in compatible browsers, but it doesn't encrypt the content and data in the same way as Secure Sockets Layer (SSL). Digest authentication's encryption methods aren't as strong and impervious to attack as SSL's, but it also doesn't have the strict export restrictions. Digest authentication is well documented in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2069, which you can find at http://www.ietf.org/rfc/rfc2069.txt. Unlike Integrated Windows authentication, Digest authentication works across proxy servers and firewalls. If you are interested in setting up Digest authentication, see the Microsoft article "Setting Up Digest Authentication for Use with Internet Information Services 5.0" (http://support.microsoft.com/support/kb/articles/q222/0/28.asp).    The second addition to IIS 5.0 is an older standard known as Fortezza. Many government facilities and the military still use Fortezza. The National Security Agency developed and actually holds a registered trademark on the name. The standard's ancestry dates back to the Rainbow series of books released in 1983, which yielded Microsoft its orange book C2 rating for NT. Implementing Fortezza often involves smart cards and special PC cards. Microsoft and Netscape have incorporated Fortezza into some of their client/server products, including Microsoft Exchange Server, Microsoft Outlook, and Netscape Navigator.    Note that Microsoft doesn't actually provide Fortezza in Win2K. Microsoft implements Fortezza as an add-on Cryptographic Service Provider (CSP) available from http://www.spyrus.com. Other companies providing Fortezza products include Mykotronx and Litronic. You can find the official Fortezza Web site at http://www.armadillo.huntsville.al.us.    The Fortezza specification includes a Law Enforcement Access Field (LEAF), which is somewhat controversial (as we've seen with the cross- country debate about the Clipper-chip). Note that the LEAF isn't installed into IIS until you install Fortezza, a non-Microsoft product. If you're considering using Fortezza, I encourage you beforehand to consider Bruce Schneier's comments on Fortezza in his book "Applied Cryptography: Protocols, Algorithms, and Source Code in C" (John Wiley & Sons, 1996, 593-594). Until next time, Allen Jones, ajones@iisadministrator.com IIS Administrator UPDATE News Editor http://www.mykotronx.com/Data_Vc.htm http://www.litronic.com/solutions/fortezza.html

LINK VIEW SERVER-SIDE COMPONENT VULNERABILITY

On April 14, reports circulated about a vulnerability in dvwssr.dll, a component included in some IIS installations. This DLL suffers from a buffer overflow vulnerability that can let some users who already have Web-authoring permissions view on the same machine other files for which they don't have permissions. Microsoft has released a workaround that instructs administrators to simply remove the DLL. You can find more information at http://www.microsoft.com/technet/security/bulletin/ms00-025.asp.

MYRIAD ESCAPE CHARACTERS VULNERABILITY

Earlier this month, Microsoft released a patch for IIS that fixes a potential Denial of Service (DoS) attack. If a malicious user sends a Web server a log URL filled with escape character sequences, including special characters such as the space symbol (%20), it could needlessly tie up the CPU, creating a DoS condition. You can find more information at http://www.microsoft.com/technet/security/bulletin/fq00-023.asp.

MICROSOFT SITE SERVER ODBC DATABASE CATALOG SEARCH

Site Server 3.0 Search is an extremely easy and powerful technology to implement. Often, when you think of search, you think of searching content in the form of Active Server Pages (ASP) and HTML on your Web site. But Site Server Search lets you index and catalog tables in databases as well. This technology is called the ODBC Database Catalog Search. With this technology, you can build search catalogs to let your site visitors search for information in your Microsoft Access or Microsoft SQL Server databases. The results of successful database searches appear on a search results page, just like a content search. From this search results page, when a site visitor clicks a link, a page appears with information from the database record. ODBC Database Catalog Search is wizard driven, and you can configure and implement it easily.    You can use either wizards or custom configuration to create Site Server Search index catalogs to search your database. Creating the ASP to perform the searches is also automatic and completely wizard driven. Behind the scenes of the ASP, a Site Server Search Catalog retrieves a reference, and ActiveX Data Objects (ADO) retrieve successful results from the search.    You can create the Search Catalog only from the Site Server Service Admin (HTML) tool in Site Server 3.0: The feature isn't available in the Site Server Service Admin (Microsoft Management Console--MMC). When you've created your Database Search, you can manage the search catalog from either the Site Server Service Admin (HTML) or the Site Server Service Admin (MMC).    Creating a Site Server 3.0 database search is simple. The Catalog Definition Wizard facilitates the entire process. When you've created a database search, pick a table from a SQL Server or Access database that you'd like to search. You need to create a System ODBC data source to your Access or SQL Server database, which you can do in Control Panel in Windows 2000 or Windows NT 4.0.    Now, access Site Server Service Admin (HTML) on your Site Server machine. Choose Search from the Service Admin home page, which will take you to the home page of Web-based administration for Site Server 3.0 Search. Choose Catalog Build Definitions from the Left Navigation window on the Search page to move to the Catalog Build Definitions page. The Catalog Build Server creates and maintains the index catalogs, which keep references to all the resources (including databases) on your Web site that you choose to be available to Site Server Search.    Click Create at the bottom of the page to start the wizard that creates a new database search catalog. Choose A Database, then click Next, and follow the wizard's prompts. When the wizard prompts you to specify whether the columns are searchable or retrievable, consider two things. If you mark a column as searchable, its value can be searched after it has been indexed. If you mark a column as retrievable, its value can be retrieved and displayed to site visitors in search scripts. To save space and improve search performance, mark as retrievable only those columns that you need to be retrievable.    Note that everybody with access to the Site Server site can execute the ASP that Site Server uses to index and display database content. If you want to control access to database content, use Internet Service Manager (ISM) to change the directory security on the directories in the /siteserver/knowledge/search/database virtual root.    Click the hyperlink on the Database Catalog Wizard Summary page to search the database table. Notice at the bottom of the screen that you can search the other fields that you've cataloged as searchable with a slightly different syntax. Choose one of the results of your successful search by clicking its hyperlink. You'll go to a page with a summary of the database record in an HTML table format. See the Site Server 3.0 Search documentation for tips about how to customize the search scripts or how to move the ASP onto your site.    Developers reading this column might think, "Why wouldn't you just do this in T-SQL or ADO?" You could, of course, and you might choose to. But the power of this type of database search is that it is    - Completely wizard driven (95 percent of the work can be generated automatically in less than 5 minutes)    - Most likely faster than a database search using ADO or T-SQL    Although the ASP that Site Server Database Search Catalog Generation generates eventually uses ADO to retrieve records from the database, you avoid complex where clauses that T-SQL would have to search within table columns; the search server catalog itself handles the where clauses. The main weakness of the Site Server database search is that you're limited to searching only one table in the database. However, the Site Server online documentation covers many tricks for overcoming this drawback.