Gartner analyst John Pescatore’s research note "Nimda Worm Shows You Can't Always Patch Fast Enough" (FT-14-5524, dated September 19, 2001), which recommends enterprises investigate alternatives to Microsoft IIS, certainly has caused a lot of discussion. Embattled Windows administrators, probably still coping with the effects of various virus attacks, now must deal with senior management asking whether the enterprise can replace IIS with an alternative Web infrastructure.
The simple answer is that moving away from IIS is difficult and will become even more difficult as more companies migrate to Windows 2000. IIS is part of the basic Win2K infrastructure and probably will be an increasingly important component in Windows .NET Server (formerly code-named Whistler). Microsoft Exchange 2000 Server is the first application to depend on IIS; you can't install or operate Exchange 2000 without running IIS on every Exchange 2000 server in the enterprise. In fact, Exchange is a pretty good pointer to a future .Net world when more and more applications depend on web services and implicitly, the IIS. The question, therefore, isn’t whether to move away from IIS, but whether to move away from Windows to another infrastructure that comes with its own set of problems. I fear that Gartner might have lost sight of this important point in its rush to condemn IIS.
IIS provides Exchange 2000 the basic protocol support to let users access their mailboxes through POP3, IMAP4, and HTTP and also provides Network News Transfer Protocol (NNTP) support for news server interaction. IIS also supplies the basic SMTP service on all Win2K servers (a service that applications such as Microsoft SharePoint Portal Server 2001 use to send email). Exchange 2000 extends the SMTP service to support features such as mailboxes and distribution lists (DLs) and to implement the advanced queuing and routing functionality that replaces much of the Message Transfer Agent (MTA) workload that you find in earlier Exchange versions. Figure 1 illustrates the close connection between Exchange 2000 and IIS—in particular, the link between IIS and the Exchange Installable File System (ExIFS), which lets Internet clients map the contents of Exchange mailboxes and public folders.
If removing IIS were technically possible, a replacement Web server would need to provide all the necessary pieces to let Exchange 2000 continue to provide mailbox access and send messages to other servers. Without IIS, Exchange 2000 is a truncated server that can't handle even local delivery if users log on through Messaging API (MAPI). The Information Store (IS) and MTA would still be present, but without the Advanced Queuing (AQ) and Routing engines, the system can't route messages from the IS to the MTA and other systems (through X.400 connections) or vice versa. IIS has lots of smarts that enable Exchange 2000 to work, so without IIS, Exchange 2000 is brain-dead. The conclusion is that removing IIS or replacing it with a Web server such as Apache or iPlanet (without negatively affecting Exchange) is nearly impossible, so the Gartner analyst's advice is a little impractical.
Given that changing Web servers isn’t a realistic solution, we need to protect our servers better than we have in the past. Of course, everyone says that they've tightened security on their Web servers, but the effects that the Code Red, Code Blue, and Nimda viruses have had on corporate systems suggest room for improvement. And because IIS runs on every Exchange 2000 server, this topic concerns all Exchange administrators.
So, what steps can you take to tighten security for both Exchange 2000 and IIS? First, continue to maintain a high degree of vigilance against email viruses and ensure that your Exchange servers are fully protected with the best antivirus agent you can find, together with up-to-date pattern files.
Second, apply a second level of protection (if you don't have one already in place) to protect against viruses that infect through techniques such as those that Nimda demonstrates —Web sites, file shares, and Internet Explorer (IE). As with Exchange antivirus tools, make sure that you use the latest pattern files; give someone the task of determining and downloading the most recent files from antivirus vendors’ sites.
Third, assign someone the responsibility for checking Security Web sites such as Symantec's Security Response daily to keep an eye on what's happening in the world of viruses. Your anti-virus vendor probably maintains a DL that notifies you when potential threats arise. Email notifications might not be much good in the midst of an attack that causes you to shut down Exchange, but sometimes an email message can give you early warning that some new problems are lurking on the Internet, ready to strike your system.
Fourth, be diligent in learning about and applying Microsoft patches. Perfect commercial software doesn't exist, so you must expect that some bugs, flaws, and imperfections will surface. The bugs might be in Exchange, IE, Microsoft Outlook or Outlook Express, IIS, or Windows. You need to find out about newly exposed flaws and how to fix them. Microsoft's Security home page is a good place to start, as are the many security newsgroups that you can join.
Fifth, use available best practices, including Microsoft’s new IIS Lockdown Tool, to lock down IIS. Note that the IIS lockdown tool affects the ability of Exchange 2000 to provide dynamic content through IIS, which is how Outlook Web Access (OWA) and Instant Messaging work, so you need to apply the advice given in Microsoft article Q309508. Microsoft maintains a current Security Best Practices list , which the company updates regularly. You can't blame others when a problem arises if the information about how to prevent the problem is available.
The depressing fact is that some idiots derive warped pleasure out of exploits that hurt others through increased workload, pressure, and strain. But with some common sense and protective actions, you can have your IIS (and Exchange) and secure it, too.
