Please Help! How do I redirect malicious visitors that come from.

I need to redirect them to a particular page on my site...

[timothius]

I am needing to redirect visitors that are referred to my site *from a certain domain name*. These visitors have wrong intentions and I need to be able to block them.

So... I setup a page to catch their IP address which I want to redirect them to.

I know how to block those visitors once I get their IP. All I need is the .htaccess code (or whatever I'm supposed to use) to redirect all visitors coming from a certain domain name to a particular page.

THANKS a MILLION! :c)

[jdMorgan]

1) If visitor arrives at any page of my site from baddomain.com, I want him to be redirected to a *SPECIFIC* page on my site where I can gather his IP address. (The specific page will then whisk him back off to baddomain.com via a meta redirect)

2) If a malicious visitor that has a particular IP address comes to any page on my site, I want him to be redirected a *DIFFERENT SPECIFIC* page on my site that would be a fake 404 page.

There are two more cases:

3) What if a visitor meets both condition: He's using a "bad" IP address *and* is referred by badddomain? In this case, you've said you want the bad-referrer case to take precedence, I believe.

4) Finally, for the sake of completeness, there is the case where neither the referrer nor the remote_addr are "bad" - In which case, you just want to serve the requested page.

Now, if you added the exclusion RewriteCond that I posted in my last post above, then all four cases should now be met -- If you're clearing your browser cache after or before each new test case. If this does not work properly, then there is probably something else going on -- another rewrite you haven't mentioned, forgot to clear the browser cache every time, using a script that actually handles one or both error URLs, etc.

Or, I suppose that your server could be hosed up... :o

Warranty is void if you've dropped any [L] flags, used a full URL instead of a URL-path in a RewriteRule, or added an [R=30x] to anything -- There's no wiggle room in .htaccess code at all.

Here is what the entire thing should like like, with full mutual-exclusion between the two rules:

# Enable mod_rewrite
Options +FollowSymlinks
RewriteEngine on
#
# Internally rewrite visitors referred by wiki to error.html page,
# where we will log the IP address and redirect them somewhere else
RewriteCond %{HTTP_REFERER} wikihow\.com
RewriteCond %{REQUEST_URI} !^/error\.html$
RewriteCond %{REQUEST_URI} !^/error2\.html$ 
RewriteRule .* /error.html [L]
#
# Internally rewrite requests from unwelcome IP addresses/ranges to
# (non-existent) error2.html page, creating a 404-Not Found response
RewriteCond %{REMOTE_ADDR} 44\.44\.44\.44 [OR]
# ... More IP address RewriteConds with [OR] flags ...
RewriteCond %{REMOTE_ADDR} 55\.55\.55\.55 [OR]
# No [OR] flag allowed on the following three RewriteCond lines
RewriteCond %{REMOTE_ADDR} 33\.33\.33\.33
RewriteCond %{REQUEST_URI} !^/error\.html$
RewriteCond %{REQUEST_URI} !^/error2\.html$ 
RewriteRule .* /error2.html [L]

Jim

[timothius]

Wow... I think you nailed it Jim. The things that I was missing were 1) the two lines below for *each* of the rewriterules and 2), the two [L] flags. THANK-YOU SO MUCH!

RewriteCond %{REQUEST_URI} !^/error\.html$
RewriteCond %{REQUEST_URI} !^/error2\.html$

I was testing it out on different browsers after clearing their respective caches, and I was a little bit confused why they seemed to treat the rules a bit differently...

For instance in IE7, if I encounter the IP address redirect first, then go to the site from the wiki, I'll usually get the same redirect, instead of the second one. The same goes for the other way around. If I visit the site through the domain first after clearing my cache and then try to go their directly, I'll end up being sent to the redirection page again. This is rather confusing... Is there any way to control the order or has is it handled by the browser? That's ok if you can't answer.

You were great Jim, THANKS! :)

[jdMorgan]

This is likely a cache-control issue, since the browser (or any client, for that matter) has no idea what we're doing with mod_rewrite inside the server. So, it's down to the cache-handling differences between the browsers themselves.

Unfortunately, there is no "Live HTTP Headers" add-on for IE like there is for Firefox/Mozilla. If there were, it would probably be easy to examine the request and response headers and see why the two act differently. It's likely that you have not defined full Expires and Cache-control headers for each filetype and the special pages (such as error pages) on your server, and the browsers therefore fall back to their default behaviors, which differ.

You have to either flush the cache each and every time you test any one of the four cases listed above, or go in and disable the darn thing (usually by telling it to keep cached pages for zero days, since the descriptive language in the browser dialog boxes is all dumbed-down).

If you do disable your caches, be sure to re-enable them after you finish testing. If you don't, and you have a broadband ISP, then other Webmasters will hate you. If you don't, and you have a dial-up ISP, then you'll hate yourself! The speed benefits of caching go largely unnoticed -- until you don't have a cache.

Now, if you want to know how to make all browsers do the same thing caching-wise, then it's time to read up on HTTP cache-control headers, mod_expires, and mod_headers. It's a whole new layer of complexity... :)

Jim

[timothius]

All I can say is... wow. I didn't know when I started web design that I would ever have to deal with stuff like this :D I think though, for my present purposes, the current config will suffice...

You've been incredible Jim! I really, really, really appreciate your moderating on Webmaster World. THANK-YOU

[jdMorgan]

> I didn't know when I started web design that I would ever have to deal with stuff like this.

Ah, but now you've made a good start to *knowing how* to deal with it. That puts you in a much smaller class than "generic Web page designer." And that means potentially- better designs, better sites, and better compen$ation from clients. ;)

Jim