One of the annoying little things that comes with running a web server is the way that the log files get filled up with requests from Internet worms. The most common worms recently include Nimda and CodeRed, which produce log entries like this:
2003-05-27 17:01:17 11.22.33.44 - 192.168.1.102 80 GET /default.ida XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 404 2 - - -
(That particular entry indicates a probe by the Code Red II worm. It was taken from my web server's log, with just the remote IP address changed to protect the guilty...)
Despite the huge publicity surrounding the worm outbreaks and the constant urging to get the latest patches, it seems that some people are too lazy or too inattentive or too stupid (or all three) to fix their systems. As a result, there seems to be a never-ending supply of machines out there on the Internet that want to probe my web server to see if it can be infected. This clutters up the log files and wastes drive space.
The simplest solution to this problem is to simply deny access to the web site for all requests that do not specify the correct hostname for the site. Since the worms scan for IIS systems by trying to connect to random or semi-random IP addresses, they cannot know the hostname for a particular web site when they do find an IIS server. If the IIS configuration is changed so that it doesn’t accept requests where the hostname is not specified, the worms can be defeated. And the best part is that the requests are not even logged by IIS, thus instantly eliminating all the clutter from the log files.
To make this change, simply select the default web site on your server (this will probably be called “www”) and choose “Properties” on the right-click menu. On the “Web Site” tab, click the “Advanced...” button. You should see a dialog similar to the following:
This dialog controls which local IP addresses & hostnames IIS will respond to incoming requests for this particular web site. By default, IIS responds to incoming requests on any local IP address and doesn’t check the “Host:” HTTP header. This allows people using ancient HTTP/1.0 clients to access your web site. Unfortunately, it also allows worms to make requests using your site’s IP address. To remove this loophole, enter the fully-qualified hostname for the web site, using the “Edit...” button, as shown below:
You can test that the change has taken effect by running your favorite web browser and entering the IP address of your web site into the address bar. If you’ve done everything properly, you should see the following message from IIS:
If you see your web site’s content instead of the message above, then you’ve done something wrong...
Because this configuration change removes the ability for people to access your web site by specifying its IP address instead of its hostname, you should consider the ramifications of this change before you deploy it. For instance, if you have any links on your web site that contain your site’s IP address directly, then these links will be broken after you make this change.
Please also be aware that while this technique is an effective measure against worms that probe ranges of IP addresses looking for IIS installations, there is still no substitute for following effective security procedures. Keep your server patched against all known vulnerabilities and try to apply as many “best practices” as possible to lock-down IIS to defeat new and unknown attacks.
I always welcome constructive feedback - if you have any comments or concerns about this article, please contact me at webmaster [at] noegruts [dot] com
© 1999-2006. Please read these notes before copying from or linking to this site.