Proper syntax (asp) for banning hijack sites

Forum Moderators: open

Message Too Old, No Replies

Proper syntax (asp) for banning hijack sites

JohnRoy

6:14 am on Sep 1, 2010 (gmt 0)

While dealing with a IIS server that was 'hijacked'

_{(in this instance, the defintion is as described on [xencraft.com...] )}
the following lines of code was added to ASP source code

dim request_string
request_string= Request.ServerVariables("SERVER_NAME")
if not (instr(request_string,"original-site.com")>0) then
 Response.Status = "200"
 Response.write "</head><body> Hell-Oh !"
 Response.write "</br><b>Stolen Content</b> was detected on " & request_string
 Response.write ".</br>Access to original owners server denied.</body></html>"
Response.End 
end if

Result:
if the page is not called from original server, the visitor AND the SE bot get a "200 OK" with no content.

Any cons for this approach?

Had it first served a flat "403" (access denied) but want the SE bots to get the updated blank pages. What about a "203" response?

[edited by: marcel at 9:49 am (utc) on Sep 1, 2010]
[edit reason] fixed broken link [/edit]

wilderness

7:05 pm on Sep 1, 2010 (gmt 0)

This thread would have received more useful replies in the IIS forum.
Suggest returning there.

Even prior to 2003 when the SSID forum was heavy with participation, there was NEVER much discussion of IIS servers.

JohnRoy

7:21 pm on Sep 1, 2010 (gmt 0)

The question is not limited to the server used.
It's an overall question on how to deal with badBots vs. seBots.

REPEAT...

Result: if the page is not called from original server, the visitor AND the SE bot get a "200 OK" with no [real] content.

Any cons for this approach?

Had it first served a flat "403" (access denied) but want the SE bots to get the updated blank pages.

What about a "203" response?

marcel

10:30 am on Sep 2, 2010 (gmt 0)

The question is not limited to the server used.

I agree, although the code itself is specific to this forum.

Not sure myself on what the best response would be here, I'd never heard of the 203 response before your post, but it looks like it would do the job. Don't know if Google/Bing etc. do anything with this response though.

The most important thing is that your content is no longer being hijacked, and that part you've solved.

Ocean10000

2:06 pm on Sep 2, 2010 (gmt 0)

I have been blocking these types of proxies for a long time. I usually check the logs and figure out where they are coming from and details about the request so I can form a nice blocking stratigy. Depending on the case I end up givin a 403 or a 200 with a snippy quote that I won't repeat here.

And looking at the code, I don't think it will block the proxie in question. As the server information returned should always be yours. I did a write up on how I block bots Quick primer on identifying bot activity. [webmasterworld.com] which you might find helpfull.

wilderness

3:47 pm on Sep 2, 2010 (gmt 0)

Result: if the page is not called from original server, the visitor AND the SE bot get a "200 OK" with no [real] content.

Ocean,
JohnRoy needs to expand on his definition of original server, whether that term is supposed to be his own server or the bots server

1) If the later, than he needs to initiate header checks.

additionally, he needs to expand on his definition of SE bot

1) It makes no sense at all to provide blank pages (absent any content) to legitimate SE bots.

Jim and others have provided multiple examples (time and again) of serving up otherwise blank-content files in order to reduce bandwith abuses by non-legitimate bots. These redirects, however are based upon multiple criteria/conditions in order to assure that legitimate bots are not served up this blank content (thereby reducing SERPS). (Please note; these methdos are for the most part explained in Apache and not IIS, however the forum may offer some rare examples of PHP methods).

JohnRoy

7:23 pm on Sep 2, 2010 (gmt 0)

Server of example.com that was 'hijacked'.

Definition in this instance is as in Preventing Web Site Hijacking [xencraft.com]

One of my pages recently turned up in a Google listing, but at a new location. When I investigated the page, I found that my entire site was duplicated, and was very up-to-date.

Apparently, they are running a proxy server and some software which maps addresses under their domain to domains of other sites.

Once the SE bot hits BadSite.com - that "server" (not ip) initiates a call to example.com. Log file would show the se bot ip, and server: BadSite.com

So instead of returning a regular page, a short message states that content is stolen from original (example.com) server.

http 203 means: The server successfully processed the request, but is returning information that may be from another source.

JohnRoy needs to expand on his definition of original server, whether that term is supposed to be his own server or the bots server

Original server refers to example.com from where the hijacker at badsite.com grabs his content.

additionally, he needs to expand on his definition of SE bot. It makes no sense at all to provide blank pages (absent any content) to legitimate SE bots.

It's makes no impact on example.com whether the legitimate SE bots think that badsite.com has blank pages or not.

The only question is how they treat 203 responses.

_{(I think this post was moved to wrong location)}

wilderness

8:48 pm on Sep 2, 2010 (gmt 0)

Neither IIS or Apache allow a webmaster to control a domain of which they are not the administrator of.
At your own domain level, you may control referring requests, however that method is far-less-than 100% accurate.

In the event your server or host has some kind of script or SQL vulnerability, those issues need to be repaired. If your on some type of shared hosting and host is unable to secure these vulnerabilities, than you should change hosts immediately.

1) Not sure anybody has a clue how legitimate SE's treat a 203.
In addition (and from an Apache point-of-view) header responses (203) require modification of the "http.conf" file. Shared hosting does not offer and any ability to control these responses by paying customers.

(I think this post was moved to wrong location)

I provided that in my initial response and you so much as told me I had my head in another body orfice.

In summary, I'd suggest that you review your raw visitor logs and make a determination as to how these intrusions occurred on your domain and if these is any consistency in their re-occurrence.
Then after lengthy and careful review, revise your access requests (i. e., denials).

wilderness

9:04 pm on Sep 2, 2010 (gmt 0)

So instead of returning a regular page, a short message states that content is stolen from original (example.com) server.

This is a bad practice to even consider.

Some webmasters serve up other images, when another website in-lines links to their own servers images, and replacing that image request with another image. Something to the effect of "image stolen by". Some even replace the requested images with vulgar images.

The entire method is a bad and irrational management choice. The soundest practice is to simply deny access, and without any explanation (explanation only challenges the thief to look for other vulnerabilities in your site (s).

JohnRoy

9:10 pm on Sep 2, 2010 (gmt 0)

I assume you missed reading the definition quoted from xencraft.com - has nothing to do with my server security.

This thread would have received more useful replies in the IIS forum.
Suggest returning there.

This is the IIS forum.

JohnRoy

9:31 pm on Sep 2, 2010 (gmt 0)

The soundest practice is to simply deny access, and without any explanation.

Agree.

But, after it already occurred, there's a need to have stolen content removed from SERPs. A 403 or 404 would not remove old content.

To stop the se bots from coming back, here's another line:

Response.write "<meta name=""robots"" content=""noindex"">"

wilderness

12:23 am on Sep 3, 2010 (gmt 0)

I assume you missed reading the definition quoted from example.com - has nothing to do with my server security.

It sure does. Your host provides you with a sort of bare-bones server designed to cover the "majority of their customers".

Security is any vulnerability.
Your vulnerability is/was that you failed to stop this creature on day one.

The following section of that web page explains many of things I've mentioned:
"Preventing Web Theft, Aggressive Access, or Harassment"

This is the IIS forum.

My primary participation since 2001 has been ONLY in the Search Engine Spider Forum.

This thread was moved there:
[webmasterworld.com...]

There's some very long threads in this SSID forum on SQL Injection, which I suggest you read.

MetaTags stops nothing.
"Most "Compliant and legitimate bots fulfill your wishes, however even some compliant bots require term specific meta-tags. Rogue harvesters could care less what you desire.