21–30 of 111 posts
recommendation: respond with fake data, based on source IP. the problem will take care of itself.
I am going to lok into this later today through nginx. I am planning on having every request from their scraping IP return a static page linking to the proper site.
You found out the right first step yourself: Block the source IP address. Sure it will turn into a game of whack-a-mole with them changing their IP but eventually, their customers will get fed up with their downtime. Second idea: Javascript redirect all of your pages to your own subdomain. Again, its just a step in an arms race, but this would be a little too hard/expensive to take to court. You can win an arms race…
For now I have added a news post with a link to the proper site and am debating between blocking the IP or delivering a static page with a link to the proper URL or a javascript redirect to the proper site.
(for now)
recommendation: respond with fake data, based on source IP. the problem will take care of itself.
Let them eat /dev/urandom to their heart's content.
I would contact the other site first and find out WTF. It is unlikely, but they might have a good reason for it. If they are just trying to rip you off, solution might be as simple as just asking them to stop.
Earlier quoted context omitted.
I have reported it to the abuse contact of the web host, colocation provider, and cloudflare. I am however not expecting a response in a timely manner from any of them. Luckily they are stripping out the ad tags before displaying by site so it shouldn't affect Ad Sense.
Do you know who their web host is? If so, block the whole Class B from fetching your site.
You found out the right first step yourself: Block the source IP address. Sure it will turn into a game of whack-a-mole with them changing their IP but eventually, their customers will get fed up with their downtime. Second idea: Javascript redirect all of your pages to your own subdomain. Again, its just a step in an arms race, but this would be a little too hard/expensive to take to court. You can win an arms race…
If the query string is being passed through, which I suspect it is, you can use the query string to easily locate the corresponding entry in your own logs. Or, if the query string isn't being passed through, you can use a path instead:
You probably already thought of this technique. I decided to post it anyway in case you hadn't, or in case anyone else is facing a similar challenge.
Earlier quoted context omitted.
Do you know who their web host is? If so, block the whole Class B from fetching your site.
Class B? What is this, 1992?
Don't just block the /24 ("Class C" IP block), block the /16 ("Class B" IP block) the IP resides in. You'll reduce your audience in India, but they'll have to switch webhosts to continue leaching his/her site.
You found out the right first step yourself: Block the source IP address. Sure it will turn into a game of whack-a-mole with them changing their IP but eventually, their customers will get fed up with their downtime. Second idea: Javascript redirect all of your pages to your own subdomain. Again, its just a step in an arms race, but this would be a little too hard/expensive to take to court. You can win an arms race…
If you have a hard time determining their IP, here's a trick that might work. Visit their site with a unique but innocuous-looking path or query that would never be accessed by a normal user. For example: http://4co.in/?q=1 If the query string is being passed through, which I suspect it is, you can use the query string to easily locate the corresponding entry in your own logs. Or, if the query string isn't being pass…
If you can't imagine what to do in this situation you shouldn't be running a website of this nature
This type of thing can (and does) happen and it's up to you to know how to defend yourself.
The others have given plenty of ideas, but I guess there are more specific things that can be done depending on their page structure/ads etc