block referrer

[hugh]

I would normally block a problem referrer using mod-security or a proven rewrite rule to a 75mb file on flickr if I'm feeling unkind. However I'm unable to block a new referrer today and I'm at a loss to explain why, especially where when I test mod-security sending their referrer using Lynx (below) my server behaves as it should and blocks the request. So I'm left thinking it's not working because the referrer I'm using is wrong. Any thoughts?

Lynx: wget [localhost...] --referer=<URL>

Thanks!

[wilderness]

Have you checked your error logs?

#referer contians the phrase "junk"
SetEnvIfNoCase Referer junk keep_out

#referer begins with the phrase "junk"
SetEnvIfNoCase Referer ^junk keep_out

#referer ends with the phrase "junk"
SetEnvIfNoCase Referer junk$ keep_out

#referer comes from domain
SetEnvIf Referer ^http\://example\.com keep_out

Please note; in lieu of the term "keep_out or whatever term you use consistently.

You may also accomplish the same thing with mod_rewrite and/or multiple conditions.
Ex: Referer and comes from a specific IP range.
Ex: Referer and User Agent includes a specific phrase.

[hugh]

I'm not comfortable with writing my own rules so I based my efforts on this examples which has worked wonders for me in the past:

[pubcon.com...]

But I'm at a loss why both methods are failing...

[wilderness]

But I'm at a loss why both methods are failing...

Again, what are your error logs reporting?
Are you sure it's failing?, the rewrite will not prevent the lines from appearing in your visitor logs, rather (in most instances) will provide a 403.

Or in the Jim's example you provided possibly a 302, 301 or even a 200 after completion (all depending upon your host).
My two hosts react entirely different to page replacements.

SetEnvIf and deny from, are the simpliest rules to comprehend and IMO, everybody should begin there and progress to more complex Rewrites.

[hugh]

In either case the result is the same, the requests get a 200 return code unless I test with mod-security using Lynx where I personally get a return code 500 so to me the difference 'seems' to be related to the referer sent by the host...

[jdMorgan]

You might want to check the 'real' referrer carefully, and make sure it isn't hex-encoded or using a 'foreign' character-set that is fooling your filter.

Servers aren't magic; If the request gets through, then your filter string probably does not match the actual referrer. Oh, and do mind that perpetually-misspelled "HTTP Referer" referrer problem -- Not sure, but it might apply here...

Jim

[hugh]

This just worked in .htaccess

# set the spam_ref variable
SetEnvIfNoCase Referer "^http://(www.)?some-spammer.com" spam_ref=1

SetEnvIfNoCase Referer "^http://(www.)?other-spammer.com" spam_ref=1

SetEnvIfNoCase Referer "^casino-poker" spam_ref=1

# block all referres that have spam_ref set
<FilesMatch "(.*)">
Order Allow,Deny
Allow from all
Deny from env=spam_ref
</FilesMatch>

[hugh]

Thanks both for taking the time to reply. Anyway yes the site in question is in Korea which seems to have been part of the problem...