How Do I Fight Russian Site Cloners?
An anonymous reader writes "I used to run a small web design service, the domain for which I allowed to expire after years of non-use. A few weeks ago, I noticed that my old site was back online at the old domain. The site-cloners are now using my old email addresses to gain access to old third-party web services accounts (invoicing tools, etc.) and are fraudulently billing my clients for years of services. I've contacted the Russian site host, PayPal, and the invoicing service. What more can I do? Can I fight back?"
If you have a summary of your clients (and you should) you should send out a mass email and let them know what's going on
check the dns domain registrar of theirs and report domain abuse.
that's what whois information is about too.
Of how Russian Free Enterprise works, I would suggest either hiring hitmen to brazenly gun-down whoever cloned your site, if it is a relatively small operation, or insinuate that the cloner is an enemy of the state, and have him jailed on trumped-up tax evasion charges, if it is a large operation.
If neither of these options suits, I hear that Polonium is the new Earl Grey...
Check out Uniform Domain Name Dispute Resolution. It is often overturned in court, and isn't always effective, but taking back control of the domain in whatever way possible is more than likely the only way you will fully recover from this. Otherwise you are simply on a damage mitigation mission.
"It's ok, I'm completely secure as long as my iron is off"
Yes!! You've hit on the perfect answer. Hindsight and a time machine can solve any problem. Bravo!
Try to close your Slashdot account, for example.
Bastard. now I've got to re-register.
This is the fundamental thing to take away from this incident, and, while it may be obvious, it deserves stating plainly:
Domain control / email address control is an authentication tool.
We've brushed by the concept in prior conversations about validating new user sign-ups.
Implications include, as in this scenario, human verification by looking at a web page of a familiar domain, human verification by email correspondence with a familiar email address, and password resetting when in control of an email address; SSL certificate-based identity (if the decrypted certificate can also be acquired), URL -referenced data validity (executables for download), and probably a number of other authentication/control mechanisms reliant on domain/address -- your ideas are solicited.
DNS hijacking, then, should be a serious concern. DJB warned about cache poisoning via brute-force source port + transaction ID spoofing in 1999. A long time went by before the issue got enough publicity (in 2008) to force the major DNS software purveyors to clean up their acts. This guy needs to be taken seriously.