In this issue

The apache.org site received a slight, unauthorised, redesign this week after the machine hosting it was victim to an attack. This was made possible due to a number of misconfigured non-related services on the machine and not due to a security hole within the Apache web server itself.

There seems to have been no malicious intent as the only damage was the addition of a mildly ironic "Powered by Microsoft BackOffice" logo to the front page. Those of you who missed it the first time can see it in all its glory on the the attrition mirror. The group responible gave full information of what they had done and how they managed to do it.

Brian Behlendorf, in a message to Apache developers, commented "I think it can be said that this compromise was mostly due to a lack of discipline on the part of those who had root and set up services without considering the ramifications of the way they were installed ... the policy of giving root access to a larger number of people than usual was probably a mistake."

Here are a few simple steps to ensure that your site isn't vulnerable to a similar attack

• Make sure that the files in your document root are owned by a different user to the one the web server is running as. So if your web server is running as user 'www' make sure your files are not owned by 'www'. This ensures that if someone is able to find a security flaw in the server or your scripts they will not be able to directly alter the contents of your site, making it harder for them to gain access by running trojan programs
• Don't share your web server document root with your ftp directory. ftp servers are notoriously difficult to configure securely and attackers may be able to take advantage of security flaws in ftp to write files into your web directory that they can execute at will
• If your site runs the PHP scripting language then consider turning on "safe-mode". This will prevent attackers who are able to upload pages executing arbitrary commands.
• Audit any scripts you run on your server, paying particular attention to scripts that read and return files based on data passed in the URL or from a form. Without correct checking users could pass in filenames containing "../" sections and potentially read arbitrary files on your system.
• Where possible only allow users who fully understand the security risks to run CGI or other scripts on your server

The Apache site was unavailable for a period of time on Thursday due to an unrelated problem with the machine hardware. FTP access to the Apache site is unlikely to be restored, and the Apache bug databases are temporarily disabled pending a security audit.

ZDNet examine web server platforms in their article, "Picking the Right Server is Key". They compare Windows 2000 Advanced Server, Netware 5.1, Red Hat Linux using Apache, Solaris using iPlanet, and Solaris using Apache. Their conclusion was the Linux/Apache approach was measurably slower at serving up static HTML but commendably fast at executing CGI scripts. However their benchmark results show that there is little performance difference at all until the server gets to around 1,000 static requests per second.

So if you're running a site on one machine, are expecting over 86 million hits a day, and have the bandwidth to be able to fulfill them, this may be an issue. If you're in that situation, we suggest investing in a few more servers (the more flashy lights the better) and some load balancing hardware as the additional cost outweighs the cost you'll be paying for the bandwidth anyway. We'd also like a shell account on that box, please.

If you are a regular reader of Apache Week you'll know that Apache has been the top web server in all the probe-based web surveys for some time, now with over 60% market share. The April survey from E-Soft also gives some other interesting statistics for modules in use; the most popular being the PHP scripting language in use on 29% of Apache sites. In the secure server space, Apache still leads with 34% of the market with Stronghold (also based on Apache) in second place at 31% giving a combined total of nearly two thirds market share.

Of particular note is the number of sites running older copies of Apache. Nearly 19% of Apache sites are still running versions of Apache 1.2 even though the last 1.2 release was over two years ago in February 1998. Only 6% of Apache sites are running the latest version, Apache 1.3.12 leaving the other 94% of sites potentially vulnerable to the cross-site scripting attack.

The Developer Shed have released an overview of session management for PHP in their article, "Couch Sessions". The article takes a look at tracking users using session management and explains how it can be easily acomplished with PHP4 and PHP3.

This occasional section contains short announcements of jobs which require significant Apache experience. To see more jobs or find out how to submit your vacancy visit the Apache Week Jobs section.

Software Designer (Boulder, Colorado)

bivio is seeking software designers skilled in building ultra-reliable, reusable, high-performance transaction processing systems using Apache, mod_perl, Oracle on Linux. Benefits: salary, equity, relocation, four weeks vacation, and portions of work releasable as freeware. Qualifications: problem solver, egoless programmer, and can take on extreme responsibility.

web developer (Bath, England)

To work on a range of commercial projects related to the Netcraft Web Server Survey, including web content technologies,

Apache Site: www.apache.org/httpd
Release: 1.3.12 (Released 25^th February 2000) (local download sites)
Beta: None
Alpha: 2.0a3 (Released 28^th April 2000) (local download sites)

Apache 1.3.12 is the current stable release. Users of Apache 1.3.11 and earlier on Unix and Windows systems should upgrade to this version. Read the Guide to 1.3.12, the Guide to 1.3.11 for information about changes between 1.3.9 and 1.3.11 and the Guide to 1.3.9 for information about changes between 1.3.6 and 1.3.9.

A series of alpha releases of Apache 2.0 are being made available from the Apache site. This alpha has a number of additions and fixes since the second alpha released at the end of March but should still not be considered even beta-quality code. The release of the third alpha was covered in Linux Today and slashdot.

Every day at Apache Week we receive many requests to help with individual Apache problems. Whilst we can't respond to every request we are interested to hear about particular problems you are having with Apache so that we can write about the things that more commonly occur. We are equally interested in any success stories you might want to share, how you came across pit falls and what you did to solve them. Mail the editors at editors@apacheweek.com.

The O'Reilly Network recently started an Apache forum where users can request help and talk about their experiences with Apache.