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 attrition mirror. The group responible gave full
information of what they had done and how they managed to do
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
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
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
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
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,
To work on a range of commercial projects related to the
Netcraft Web Server Survey, including web content
Apache Site: www.apache.org/httpd
Release: 1.3.12 (Released 25th February
Alpha: 2.0a3 (Released 28th April 2000) (local download
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
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
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 firstname.lastname@example.org.
The O'Reilly Network recently started an
Apache forum where users can request help and talk about
their experiences with Apache.