Latest TweetsWordPress and the Blank Target Vulnerability (aka rel noopener + noreferrer): perishablepress.com/wordpress-… #WordPress #security #html
Perishable Press

Stop the Madness: Redirect those Ridiculous Favicon 404 Requests

For the last several months, I have been seeing an increasing number of 404 errors requesting “favicon.ico” appended onto various URLs:

http://example.com/favicon.ico
http://example.com/2007/06/12/favicon.ico
http://example.com/2007/09/25/absolute-horizontal-and-vertical-centering-via-css/favicon.ico
http://example.com/2007/08/01/temporary-site-redirect-for-visitors-during-site-updates/favicon.ico
http://example.com/2007/01/16/maximum-and-minimum-height-and-width-in-internet-explorer/favicon.ico

When 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://example.com/favicon.ico [R=301,L] 
</ifmodule>

Ahh, much better. With this code placed in your site’s root blog’s subdirectory1 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://example.com/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 :)

Footnotes

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 root) check out Redirect All Requests for a Nonexistent File to the Actual File.

Jeff Starr
About the Author Jeff Starr = Web Developer. Book Author. Secretly Important.
Archives
10 responses
  1. 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.

  2. Jeff Starr

    Thank you, Louis! It helps to have such excellent readers — makes it very easy to stay inspired and focused. So thanks to you as well :)

    And for the favicon issue — that’s just it: it seems like an absolute waste of resources to be scanning for vulnerabilities via favicon.ico. It’s like, “what’s the point?” I would love to know the purpose and/or reasoning for this nonsense, but until that happens, it’s the best I can do to stop the madness with a little htaccess magic!

  3. 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

  4. 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.

  5. Jeff Starr

    @Donace: not surprising, as I have posted several times on this site, Yahoo’s sloppy Slurp crawler can’t seem to play by the rules. And, funny you should mention 4G.. ;)

    @Chris: check your email! :)

  6. Callum Mckay August 27, 2008 @ 2:18 pm

    # REDIRECT FAVICONZ

    RewriteCond %{THE_REQUEST} favicon.ico [NC]
    RewriteRule (.*) http://example.com/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

  7. Jeff Starr

    Hi Callum, depending on the location of the htaccess code, infinite loops may be an issue. Glad to see you worked it out for yourself (and thanks for sharing the code, btw), but for others who may be experiencing the same problem, check out this folow-up article I posted after encountering the same thing on another one of my sites:

    Redirect All Requests for a Nonexistent File to the Actual File

    There, I explain the method in detail and provide an alternate technique that may be used anywhere on your site.

  8. 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).

  9. Thank you thank you thank you! I get hundreds of these every week! Problem solved.

  10. Jeff Starr

    My pleasure, Bernard — glad to be of service! :)

[ Comments are closed for this post ]