eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
IIS administrators have had a tough year. Code Red, Code Red II, Nimda and variants have been sweeping back and forth over the Internet like a reapers scythe, and all of us have had to do our share of ducking.
“Right now, I barely cope,” wrote one Internet Information Services administrator. “I get the IIS security patch e-mails and install them ASAP. Somehow, I still managed to get infected with Code Red II.”
Another wrote: “I am aghast at the number of patches that Microsoft has already put out for IIS 5.0. How am I supposed to keep up? Its a full-time job and, like others, securing IIS against intrusions is not my only task.” (For more IT managers views on IIS, go to www.eweek.com/article/0,3658,s%253D702%2526a%253D17279,00.asp.)
“We have moved our public Web site to a service provider. Let them deal with the security issues for me,” wrote a third.
Microsoft Corp.s IIS certainly hasnt been the exclusive target of crackers—in May, the sadmind worm targeted IIS and Sun Microsystems Inc.s Solstice AdminSuite package; and Februarys Lion (or 1i0n) worm attacked Domain Name System servers on Linux-based servers.
However, the attacks on IIS have been unique in both severity and risk.
IIS is significantly more vulnerable than other Web servers because it ships with so many by-default-enabled features and because so many of these features pass user input to services with system-level access. A successful attack on IIS is significantly more damaging than with other Web servers.
The IIS bugs being exploited by these attacks are also fairly recent arrivals, many affecting IIS 4.0, the version that shipped with Windows NT Server, and the current IIS 5.0. IT administrators who havent kept up on patches released by Microsoft are guaranteed to be in trouble.
Because of these issues and because IIS is such a popular Web server for its tight Windows integration, ease of use and functionality (just under 30 percent of all Web sites run IIS, according to Web survey company Netcraft Ltd.), the number of infected IIS servers on the Internet is tremendous. And each infected server generates a lot of attacks on its own.
To see for ourselves how long a default installation of IIS would last in the wild, eWeek Labs connected a fresh install of Windows 2000 Server to the outside Internet. As an arbitrary deadline, we immediately started downloading the network install of Windows 2000 Service Pack 2 and disconnected from the network when it was done.
The 110MB download took 25 minutes. For the first 15 minutes, we didnt see any HTTP traffic at all; in the last 10 minutes of the download, we were infected with Nimda twice—once from two different servers and several times by our own server reinfecting itself.
Deciding whether to stay or switch is something each IIS customer will have to determine based on their IT needs, in-house skills and comfort level with what they have now.
In this package, we explore the alternatives that many IIS administrators are considering afresh. In this story, well examine the technical implications of switching away from IIS to Web servers that are less of a target and have better security track records.
We also describe and evaluate several ways IIS users can make sure their Web server platform is configured securely—something that is certainly possible, given the right techniques and tools.
At its heart, a Web server is a simple thing, so organizations doing simple things with their Web servers, such as serving static pages and images, will find it easy to switch to another option. This is a straightforward process, other than the one-time chore of recreating server settings on a new platform and in new ways (which will involve some training).
The real costs and problems lie in trying to move Web sites with dynamic content, such as applications based on Web scripting languages; and moving installed application servers; custom-written components such as ISAPI extensions or Common Object Model components; and use of packaged applications such as search engines or e-commerce storefronts.
Moving applications based on Web scripting languages and installed application servers is actually easier than it might seem at first. All the major scripting languages and application servers (with the notable exception of Windows itself) run on multiple Web servers and on multiple operating systems and provide very good source code compatibility.
Whats needed to switch?
Especially useful will be Suns Sun ChiliSoft ASP (www.chilisoft.com), which provides an ASP (Active Server Pages) engine that works on several Unix operating systems; Linux; Windows; and with servers including the Apache Software Foundation Inc.s Apache, iPlanet E-Commerce Solutions iPlanet and Zeus Technology Ltd.s Zeus Web servers.
The software costs $495 per server and is included free with iPlanet Web Server Enterprise Edition.
ChiliSoft ASP provides source code compatibility with ASP 2.0 (the version of ASP that ships with IIS 4.0 and Windows NT Server 4.0) and with Microsofts ActiveX Data Obejects data access libraries.
We set up ChiliSoft ASP on a Windows 2000 server with iPlanet Web Server Enterprise Edition 6.0 and ran the Nile Bookstore, our standard ASP test application, on it. We had only one problem: We got a ChiliSoft error when we called Response.Redirect after outputting an HTTP header because ChiliSoft ASP has buffering turned off by default. We fixed the problem by turning buffering on for that page by adding a line “Response Buffer=true” to the file. We also could have edited a ChiliSoft ASP registry seting to turn on buffering for all pages. Otherwise, every page in the site worked as it did using IIS.
However, if a company relies on ISAPI applications for its Web site, porting can be a lot more problematic.
The iPlanet Web Server has no support for ISAPI applications. By default, Apache does load a module called mod_isapi, which gives the open-source Web server basic support for ISAPI. Using this, we were able to run several simple ISAPI applications, such as a page counter and a visitor guest book, on our Apache servers.
But a potentially large problem is that Apaches mod_isapi provides support only for ISAPI extensions, not for ISAPI filters, which are typical in more advanced e-commerce ISAPI applications.
Support for both extensions and filters is found in the Zeus Web server, which runs on nearly every operating system except Windows. Although Zeus costs $1,700 (unlike the free Apache and IIS), moving to it can also provide other benefits, such as excellent performance and support for many other Web application languages.
Although ChiliSoft ASP and the ISAPI support in these products can ease the pain of moving applications from an IIS platform, companies that are serious about moving should consider recoding their applications in languages such as JSP (JavaServer Pages) and PHP, both of which are more stable and more scalable on new Web platforms.
Although porting an application to a new language may sound daunting, it can be feasible, depending on the application. eWeek Labs has some experience in this area. Last year, in an eValuation designed to test the benefits of dynamic Web development languages, we ported our Nile bookstore application from ASP to JSP, PHP and Cold Fusion.
Any Web developer familiar with ASP should have little trouble moving to JSP. Also, some tools, such as Macromedia Inc.s UltraDev, make it possible to use the same development environment for coding in both languages. PHP can be a little more difficult for ASP developers, although any developer familiar with C or Perl should have little trouble using the open-source language. In addition, several free tools are available that do some automated conversion from ASP to PHP.
West Coast Technical Director Timothy Dyck can be reached at timothy_dyck@ziffdavis.com. East Coast Technical Director Jim Rapoza can be reached at jim_rapoza@ziffdavis.com.