wiki:doc/TorAbuseTemplates

Version 21 (modified by mikeperry, 8 years ago) (diff)

--

The best way to handle abuse complaints is to set up your exit node so that they are less likely to happen in the first place. Please see Tips for Running an Exit Node with Minimal Harassment for more info, before reading this document.

Below are a collection of letters you can use to respond to your ISP about their complaint in regards to your Tor exit server.

The general format of these templates is to inform the complaintant about Tor, to help them to find a solution to their particular issue that works in general for the Internet at large (open wifi, open proxies, botnets, etc), and barring all else, how to block Tor. All templates should include these first four paragraphs:

Common Boilerplate (Tor Intro)

  The IP address in question is a Tor exit node:
  https://www.torproject.org/overview.html

  The Tor network is a privacy, anonymity, and censorship circumvention
  network that can be used freely by anyone. It sees use by many
  important segments of the population, including whistle blowers,
  journalists, Chinese dissidents skirting the Great Firewall and
  oppressive censorship, abuse victims, stalker targets, the US
  military, and law enforcement, just to name a few:
  https://www.torproject.org/torusers.html

  As you can see from the overview document, the design of the system is
  such that there is nothing that any individual operator can do to
  trace connections further.

  While Tor is not designed for malicious computer users, it is true
  that they can use the network for malicious ends. In reality however,
  the actual amount of abuse is quite low:
  https://www.torproject.org/faq-abuse.html.en

Abuse Scenarios

The following scenario-specific paragraphs should be appended to the Common Boilerplate paragraphs above. The common boilerplate should be abridged or be omitted if the abuse complaintant is already familiar with Tor.

Brute Force Attacks

We're sorry your account has been brute forced. We can try to prevent our node from connecting to this forum, but since the Tor network has 800 or so exits, doing so wouldn't really stop the action long term. The attacker would probably just chain an open proxy after Tor, or just use open wireless and/or a proxy without Tor.

If the attack is still ongoing, however, we can try to implement the block temporarily to divert it. Again, such action is likely to be meaningless to the attacker, but if ours is the only IP they are using for some reason, we can try it for a few days.

In general, we believe that problems like this are best solved by improving the service to defend against the attack from the Internet at large. Brute force login attempts can be reduced/slowed by captchas, which is the approach taken by Gmail for this same problem. In fact, Google provides a free captcha service, complete with code for easy inclusion in a number of systems to help other sites deal with this issue: https://code.google.com/apis/recaptcha/intro.html

DoS Attacks, Scraping Robots, 'Click Fraud'

We're sorry your site is experiencing this heavy load from Tor.

However, it is possible that your rate limiting alarms simply experienced a false positive due to the amount of traffic that flows through the router. We provide service to almost a gigabit of traffic per second, 98% of which is web traffic.

If the attack is real and ongoing, however, we can try to implement the block temporarily to divert it. Such action is likely to be meaningless to the attacker because there are 800 other exit nodes we do not control and thousands of open proxies to use as well, but if ours is the only IP the attacker is using for some reason, we can try it for a few days.

In general, we believe that problems like this are best solved by improving the service to defend against the attack from the Internet at large. Brute force login attempts can be reduced/slowed by captchas, which is the approach taken by Gmail for this same problem. In fact, Google provides a free captcha service, complete with code for easy inclusion in a number of systems to help other sites deal with this issue: https://code.google.com/apis/recaptcha/intro.html

Fraud

This also does not mean that there is nothing that can be done. For serious incidents, traditional police work techniques of running stings and investigating to determine means, motive, and opportunity are still very effective.

Additionally, the Tor project provides an automated DNSRBL for you to query to flag orders coming from Tor nodes as requiring special review: https://www.torproject.org/tordnsel/

It also provides a Bulk Exit List service for retrieving the entire list: https://check.torproject.org/cgi-bin/TorBulkExitList.py

You can use this list to help you take a closer look at Tor orders, or to hold them temporarily additional for verification, without losing legitimate customers.

In fact, in my experience, the fraud processing teams contracted by many ISPs simply mark all requests from Tor nodes as fraud using that very list. So it is even possible this is a legitimate order, but was flagged as fraud solely based on IP, especially if you contract out fraud detection to a third party.

Google Groups Spam

It appears that your specific abuse complaint was generated by an authenticated Google groups user. Inspecting the headers reveals that the abuse complaint address for Google Groups is groups-abuse@…. Contacting this address will give you better luck at actually having this abuser's Google Groups account canceled than will chasing down Tor nodes, proxies, and open wireless access points.

Additionally, if your news reader supports killfiles, you may be interested in using the Tor Bulk Exit list script to download a list of IPs to include in your killfile for posts that match "NTTP-Posting-Host: <ip>" https://check.torproject.org/cgi-bin/TorBulkExitList.py

Hacked Gmail, Web Forum, or Misc Account Access

With respect to your account, given that the attacker used Tor and not a large botnet (or your machine's IP itself), it is likely that your password was either harvested off of your machine from a keylogger, or it was captured via a kiosk, or from open wireless.

Our recommendation is to treat this event as though there was a login from an open wireless access point in your city. Reset your password, and if you don't have antivirus already, download the free AVG: http://free.avg.com/us-en/download, Spybot SD: http://www.safer-networking.org/nl/home/index.html, and/or AdAware: http://www.lavasoft.com/?domain=lavasoftusa.com. Use these to scan to check for keyloggers or spyware that someone with access to your computer may have installed.

To help protect yourself while using open wireless, consider using this Firefox plugin: https://www.eff.org/https-everywhere/ and encourage the site maintainer to support https logins.

Hacking, PHP Webshells, XSS

This also does not mean that there is nothing that can be done. For serious incidents, traditional police work techniques of running stings and investigting to determine means, motive, and opportunity are still very effective.

Additionally, the Tor project provides an automated DNSRBL for you to query to flag visitors coming from Tor nodes as requiring special treatment: https://www.torproject.org/tordnsel/. The same list is available through the Tor Bulk Exit List: https://check.torproject.org/cgi-bin/TorBulkExitList.py

However, rather than banning legitimate Tor users from using your service in general, we recommend ensuring that such services are updated and maintained to free of XSS vulnerabilities that can lead to situations such as this PHP webshell.

PHP Relay or Exploited Webmail Account Spam

In addition, our nodes do not allow SMTP traffic to be sent using our IPs. Upon investigation, it appears that the source of the spam is due to an abusive or compromised webmail gateway running at: <web server here>. Did you contact their abuse department?

SSH Bruteforce Attempts

If you are concerned about SSH scans, you might consider running your SSHD on a port other than the default of 22. Many worms, scanners, and botnets scan the entire Internet looking for SSH logins. The fact that a few logins happened to come from Tor is likely a small blip on your overall login attempt rate. You might also consider a rate limiting solution: http://kevin.vanzonneveld.net/techblog/article/block_brute_force_attacks_with_iptables/

If it is in fact a serious problem specific to Tor, the Tor project provides an automated DNSRBL for you to query to block login attempts coming from Tor nodes: https://www.torproject.org/tordnsel/

It is also possible to download a list of all Tor exit IPs that will connect to your SSH port: https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=YOUR_IP&port=22

You can use this list to create iptables rules to block the network.

Other Scenarios

If a serious abuse complaint not covered by this template set arrives, the best answer is to follow a pattern with the complaining party. This is not legal advice. This was not written or reviewed by a lawyer. It was written by someone with experience in working with various ISPs who had issues with a Tor exit node on their network. It has also been reviewed by someone who works in Abuse at a major ISP.

  • Read the Tor Overview. Be prepared to summarize and answer basic questions. Assume the person with which you're going to converse knows nothing about Tor. Assume this same person isn't going to trust anything you say.
    • In serious cases, such as harassment email or death threats, it is often helpful to draw an analogy to situations in the physical world where an action is perpetrated by an anonymous individual (such as delivering the notice via postal mail).
    • Remind them that traditional policework can still be used to determine who had the means, motive, and opportunity to commit the crime.
  • Arrange to talk with or directly email the complaintant.
  • During the conversation make sure you explain a few points:
    • You are not the perpetrator of the issue.
    • You are a responsible server operator and concerned about the complaintant's problem.
    • You are not insane. You may be insane, but we don't want the complaintant to guess this is true.
  • In many cases, your ISP will be involved as a conduit for the 3rd party complaintant. Your ISP wants to know:
    • Your server is not compromised.
    • Your server is not a spam relay.
    • Your server is not a trojan/zombie.
    • You are a competent server administrator and can address the issue. Minimally, you can at least discuss and respond to the issue intelligently.
    • The ISP is not at fault and not liable for your actions. This is normally the case, but the poor abuse person dealing with the issues just wants to hear it isn't the ISPs problem. They will move on after they are comfortable.
  • Discuss options. Options Phobos has been offered:
    • The ISP/Complaintant may very well demand to see logfiles. Fortunately, by default, nothing sensitive disclosed. You may want a new ISP if they demand access to log files ad hoc.
    • The ISP/Complaintant suggests you convert to middleman. In this case, you may want to counter with a reduced exit policy, such as the one suggested in item #6 of the above blog post.
    • The ISP/Complaintant demands you disable Tor. You may want a new ISP as a result.
    • The ISP/Complaintant states they will firewall off the traffic on the default ports. You may want a new ISP as a result.
    • Update the config to disallow traffic to a certain IP range from your exit node. You may want to suggest the complaintant use the Tor DNS RBL instead.
  • After all has been discussed, offer a follow up conversation within a week. Make sure your agreed upon changes are implemented. Neither the ISP nor Complaintant may want to do this, but the fact that you offered is in your credit. This may help them feel "comfortable" with you.

Other Template Sets