My site is hosted on an Apache web server. Why is that? Because,
in my humble opinion, Microsoft’s IIS web server is in no way
qualified to service internet web sites (it is excellent as an
intranet and applications server, however). Another reason is
the vast number of security issues that seem to pop up day after
In point of fact, the Gartner Group has recommended “that
businesses hit by both Code Red and Nimda immediately
investigate alternatives to IIS, including moving Web
applications to Web server software from other vendors such as
iPlanet and Apache”.
But what about those of us who are already hosting their sites
on Apache servers? I’ve seen lots of articles about how to
protect, detect, cleanse and prevent the worms from attacking
IIS servers. While the worms do not penetrate Apache security,
they do cause damage.
Some of the damage includes:Server logs get filled with junk -
The Nimda worm alone created over 20,000 entries in a 2 day
period in my log files.
The server is made very busy – This is especially true if you’ve
got a custom 404 error page, as I do. This means that every time
the worm attempts a penetration, then entire 404 page is
returned (in my case, that’s about 40k). That adds up to a lot
of wasted bandwidth.
I thought about this issue for a while after examining my logs
and seeing thousands of 404 errors from attempted worm
penetrations. Surely there was a way to at least reduce the
impact of these things? As I saw the 404 error count increase, I
realized that a significant portion of the bandwidth that I was
paying for was being thrown away.
An examination of the log files produced several thousand
attempts at each of the following URLs. Obviously each of these
is the address of a possible weakness in an IIS server.
The Apache web server provides a feature called .htaccess, which
provides commands to control a web site. This file is very
obscure and extremely useful when used properly. You have to be
careful when editing .htaccess files, as a small mistake can
make your web site stop working. What I like to do is
immediately test the site to be sure it works.
Be sure not to make the mistake that I made once – I browsed to
my site, saw that the home page came up, and went to work.
Later, I found it was not working but appeared to work because
the home page was stored in my browser cache. Thus I learned a
simple lesson the hard way: always hit the refresh key of the
browser when testing .htaccess changes.
I did a little research and testing, and added the following
lines to my .htaccess file.
redirect /scripts http://www.stoptheviruscold.invalid redirect
/MSADC http://www.stoptheviruscold.invalid redirect /c
http://www.stoptheviruscold.invalid redirect /d
http://www.stoptheviruscold.invalid redirect /_mem_bin
http://stoptheviruscold.invalid redirect /msadc
http://stoptheviruscold.invalid RedirectMatch (.*)cmd.exe$
These lines did exactly what I wanted them to do – they stopped
the virus from creating 404 errors in my log file, and they
prevented my 404 error page from being triggered, thus creating
lots of useless bandwidth utilization. There is still some
bandwidth used, obviously, but it is far less than it would have
been. The load on the server is also considerably reduced, which
should make my web hosting company happy.
Note that log file entries are still made by the various worms
as they attempt to penetrate the server. These entries do now
show as errors, which makes it easier to pick out real errors
from the logs.