Default Site
With Apache 1.3, the first entry of your VirtualHosts section serves as your "default" site -- in other words, if someone comes to a site that's not configured in your VirtualHosts section correctly, but is specified in public DNS as your server's IP address, he will be sent to the default Web site.With Apache 2.0, the default site is instead the first file (in alphabetical order) in the /etc/apache2/sites-enabled directory. After initial installation, there will be a symlink from 000-default in this directory to /etc/apache2/sites-available/default. As you can see from this, Apache 2.0 offers another level of abstraction in virtual hosts by recommending putting the actual files in /etc/apache2/sites-available and then symlinking from there to /etc/apache2/sites-enabled.
favicon.ico Errors
I don't use the favicons on my sites, so my error log had plenty of 'File does not exist' errors for the favicon.ico file. I did some searching for solutions to these errors. Some people suggest creating a fake favicon.ico file. Some claim that every site should have one and that you should create one for that reason. I found one site that suggested adding the following to your httpd.conf file.RedirectMatch permanent .*/favicon\.ico$ http://www.microsoft.com/favicon.ico/requests/are/flooding/my/error/log
Since Firefox and other browsers also request favicons, I don't think it's fair to single out Microsloft, even though I'd like to. Another suggestion I found was to enter the following in your Apache configuration file.
Add to the httpd.conf/apache2.conf file:
# Don't bother looking for favicon.ico
Redirect 404 /favicon.ico
# Don't bother sending the custom error page for favicon.ico
<Location /favicon.ico>
ErrorDocument 404 "No favicon"
</Location>
(source: Getting rid of favicon.ico)
This will generate an immediate 404 error when the favicon.ico file is requested and avoid the error log entries. This is probably the best solution if you're not going to make your own favicon files.
Initially, I opted for the easy way out with this simple solution. In the document root of your web site enter "touch favicon.ico" at a command prompt. This will create a zero byte file to transmit back to browsers requesting the file. A quick and easy solution.
(source: lists.debian.org)
Apache Tweaks for CodeRed and Nimda
Send To Non-existant Domain
Like many others, when I first started using Apache I found entries in the access.log file that looked like requests for windows programs. Since I was running Apache on Linux, I started searching the web for what these entries were. I found that many people thought that these entries meant that their web server was being hacked and were looking for solutions. Obviously, if your Apache web server is running on Linux like mine was, there is no threat from these hits on the server, just junk in the log file and bandwidth being used up by infected MS Windows systems.The first work around I found for this problem was to add statements like the ones below to your .htaccess file. The redirects simply send the request on to a non-existant domain.
redirect /scripts http://www.nosuchsite.invalid
redirect /MSADC http://www.nosuchsite.invalid
redirect /c http://www.nosuchsite.invalid
redirect /d http://www.nosuchsite.invalid
redirect /_mem_bin http://nosuchsite.invalid
redirect /msadc http://nosuchsite.invalid
RedirectMatch (.*)\cmd.exe$ http://nosuchsite.invalid$1
Virus Attempts: Return to Sender
Another technique that I found was to send the request back its source with a permanent redirect. I never was very clear on whether the virus/worms would actually pay any attention to permanent redirects, but I've included them here as another work around for the CodeRed and Nimda worms.Add to the httpd.conf/apache2.conf file or the .htaccess file:
RedirectMatch Permanent ^/(.*cmd\.exe.*)$ http://127.0.0.1/$1
RedirectMatch Permanent ^/(.*root\.exe.*)$ http://127.0.0.1/$1
RedirectMatch Permanent ^/(.*default\.ida.*)$ http://127.0.0.1/$1
(source: WebHosting Talk - Web Hosting Forum)
Write virus-garbage to other logfile
I found this solution to keep your log files clean. This solution redirects access log entries from the CodeRed and Nimda worms to their own separate log file.Add to the httpd.conf/apache2.conf file:
# CodeRed and Nimda in seperate logfiles
#
# For Code Red
SetEnvIf Request_URI "^/default.ida(.*)$" code_red_attacks attacks
# For Nimda
SetEnvIf Request_URI "root\.exe(.*)$" nimda_attacks attacks
SetEnvIf Request_URI "cmd\.exe(.*)$" nimda_attacks attacks
CustomLog /var/log/apache2/codered.log common env=code_red_attacks
CustomLog /var/log/apache2/nimda.log common env=nimda_attacks
CustomLog /var/log/apache2/access.log common env=!attacks
I don't remember where I found the above solution, but I found this similar solution at http://real.ath.cx/BSDinstall.html.
Add to the httpd.conf/apache2.conf file:
# For Code Red
SetEnvIf Request_URI "^/default.ida" attacks
# For Nimda
SetEnvIf Request_URI "^/scripts" attacks
SetEnvIf Request_URI "^/c/winnt" attacks
SetEnvIf Request_URI "^/_mem_bin" attacks
SetEnvIf Request_URI "^/_vti_bin" attacks
SetEnvIf Request_URI "^/MSADC" attacks
SetEnvIf Request_URI "^/msadc" attacks
SetEnvIf Request_URI "^/d/winnt" attacks
CustomLog /var/www/logs/access_log combined env=!attacks
CustomLog /var/www/logs/attack_log combined env=attacks
(source: http://real.ath.cx/BSDinstall.html)
Redirect to Microsoft With An Access Forbidden Error
This last solution is my personal favorite. Send them an access forbidden error and redirect them to Microsoft's information pages on the Code Red and Nimda worms.Add to the httpd.conf/apache2.conf file:
# deny access from codered
<Location /default.ida*>
deny from all
ErrorDocument 403 http://www.microsoft.com/technet/security/bestprac/isacored.mspx
</Location>
# deny access from nimda
<Location /scripts/*>
deny from all
ErrorDocument 403 http://www.microsoft.com/technet/Security/topics/virus/nimda.mspx
</Location>
