Stop the Madness: Redirect those Ridiculous Favicon 404 Requests
Published Monday, August 11, 2008 @ 7:10 am • 8 Responses
For the last several months, I have been seeing an increasing number of 404 errors requesting “favicon.ico” appended onto various URLs:
http://perishablepress.com/press/favicon.ico
http://perishablepress.com/press/2007/06/12/favicon.ico
http://perishablepress.com/press/2007/09/25/absolute-horizontal-and-vertical-centering-via-css/favicon.ico
http://perishablepress.com/press/2007/08/01/temporary-site-redirect-for-visitors-during-site-updates/favicon.ico
http://perishablepress.com/press/2007/01/16/maximum-and-minimum-height-and-width-in-internet-explorer/favicon.icoWhen these errors first began appearing in the logs several months ago, I didn’t think too much of it — “just another idiot who can’t find my site’s favicon..” As time went on, however, the frequency and variety of these misdirected requests continued to increase. A bit frustrating perhaps, but not serious enough to justify immediate action. After all, what’s the worst that can happen? The idiot might actually find the blasted thing? Wouldn’t that be nice..
But no, the 404 favicon errors just won’t go away. Last week, as I was digging through my site’s error logs, there were hundreds of these infamous favicon requests — line after line of moronic URL activity, scripted directory brachiation targeting the all-empowering favicon exploit. Give me a break. Finally, I just couldn’t deal with it any more and decided to put an end to the madness..
Pssst: it’s in the root directory
Fortunately, stopping this nonsense is relatively easy. My knee-jerk reaction was to simply block all requests for favicon.ico:
<IfModule mod_alias.c>
RedirectMatch 403 favicon.ico
</IfModule>
..very effective; 29 characters and problem solved. I could even add this line to my 3G Blacklist, but I don’t want to prevent direct access to my real favicon, so an alternate strategy is required. Let’s try it again, this time invoking the mind-boggling powers of Apache’s mod_rewrite:
# REDIRECT FAVICONZ
<ifmodule mod_rewrite.c>
RewriteCond %{THE_REQUEST} favicon.ico [NC]
RewriteRule (.*) http://domain.tld/favicon.ico [R=301,L]
</ifmodule>Ahh, much better. With this code placed in your site’s root blog’s subdirectory 1 HTAccess file, all requests for your site’s favicon.ico file will be directed to the original location, as specified in the RewriteRule. First line: check for the proper Apache module (mod_rewrite); second line: match any request for favicon.ico (regardless of casing); third line: rewrite all matched requests as http://domain.tld/favicon.ico and declare the redirect as permanent (301); last line: close the module-check container.
I have been using this code for about a week now and have seen no further 404 errors for misdirected favicon requests. Filtering out the noise from my error and access logs makes it easier to identify more serious issues.
Finally, in case you were wondering about the identity of the ruthless favicon bandit, here you go:
<Limit GET POST PUT>
order allow,deny
allow from all
deny from 65.60.102.254 "# favicon bandit zombie "
deny from 76.175.130.100 "# favicon bandit zombie "
deny from 80.219.216.247 "# favicon bandit zombie "
deny from 163.192.21.42 "# favicon bandit zombie "
deny from 203.123.182.138 "# favicon bandit zombie "
</LIMIT>These are all coming from completely different hosts, however blocking them for the immediate future may provide some temporary relief against any other cracker nonsense (i.e., non-favicon exploits) executed through these zombie machines.
And that’s a wrap. If you are experiencing similar 404 favicon requests, I would be interested in hearing about them. As always, thank you for your generous attention :)
Footnote
- 1 It has been discovered that the redirection method described in this article works only when placed in a subdirectory, such as would be the case for blogs installed in their own directory. When placed in the root directory, this code will create an infinite redirection loop. For more information, and to learn about a similar technique that works in all directories (including the root directory) check out my article, Redirect All Requests for a Nonexistent File to the Actual File.
About this article
Related articles
- Redirect All Requests for a Nonexistent File to the Actual File
- Redirect All (Broken) Links from any Domain via HTAccess
- 1-Minute Tutorial: Permanent (301) Redirect via PHP or htaccess
- Redirect any Subordinate URL to its Parent Directory via PHP
- htaccess Combo Pack: WordPress Permalinks and non-www Redirect
- Permanently Redirect a Specific IP Request for a Single Page via htaccess
- Redirect WordPress Individual Category Feeds to Feedburner via HTAccess
Dialogue
8 Responses Jump to comment form
August 12, 2008 at 8:50 am
I get that alot as well; i traced it a few times was actually coming from yahoo.
Their bot is acting up I think; Ah well file it away for 4g:p
August 12, 2008 at 2:04 pm
How incredibly timely. I just got a notice from my hosting provider that I am consuming way too many cycles (or whatever they call it). Their analysis is showing lots of these weird favicon requests, as well as a bunch for a specific image at a bunch of weird URL’s. I gotta try this .htaccess trick to see if it works. I’ll email you with some specifics.
August 27, 2008 at 2:18 pm
# REDIRECT FAVICONZ
RewriteCond %{THE_REQUEST} favicon.ico [NC]
RewriteRule (.*) http://domain.tld/favicon.ico [R=301,L]
This seems to upset Firefox by putting it into a loop. I used this instead.
# REDIRECT FAVICONZ
RewriteRule ^favicon\.ico$ /images/favicon.ico
September 22, 2008 at 10:08 am
Firefox is utterly anal about favicons for some reason.
My LAN XAMPP Apache logs are saturated with these 404s, because my compatibility regime obviously includes… Firefox!
Btw, for folks that don’t have a localhost LAMP (Apache, MySQL, PHP) or similar running, it would scare you sh*tless if you knew the amount of time your server spends writing to its error logs (most of which you can’t easily access on a shared package).
Share your thoughts..
← Previous post • Next post →
« WordPress Plugin: Authenticate Lite • Redirect All Requests for a Nonexistent File to the Actual File »
1 • Louis
August 11, 2008 at 11:31 am
You got a real writting talent Jeff; I so enjoyed the first part of the post. This introduction was awesome!
Now about the very problem of your favicon, I must say I find absolutely no sense in asking for a favicon everywhere. I can imagine that the zombie machine crawles the web searching for favicons, and that its worm is very badly coded so that it search by adding “favicon.ico” to the current document URL.
But anyway, for what purpose? Is there some kind of sick genius trying to make the internet implode by stealing every and each favicon? No seriously, I can’t see any reason of parsing the internet for favicons.