wiki:doc/TorAbuseTemplates

Tor Abuse Templates: Before You Start

The best way to handle abuse complaints is to set up your exit node so that they are less likely to be sent in the first place. Please see Tips for Running an Exit Node with Minimal Harassment and Tor Exit Guidelines 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.

Format and Philosophy of Templates

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. The philosophy of the Tor Project is that abuse should be handled proactively by the site administrators, rather than wasting effort and resources on seeking vengeance and chasing ghosts.

The difference between the proactive approach and the reactive approach to abuse is the difference between decentralized fault-tolerant Internet freedom, and fragile, corruptible totalitarian control. To further preach to the choir, the identity-based Internet "driver's licenses" of South Korea and China have done nothing to curtail cybercrime and Internet abuse. In fact, all objective evidence seems to indicate that it has only created new markets for organized crime to preside over. This is the core idea that these abuse complaint templates attempt to instil in the recipient. Feel free to improve them if you feel they fall short of this goal.

All templates should include the Common Boilerplate below, and append some additional paragraphs depending on the specific Scenario.

Common Boilerplate (Tor Intro)

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

There is little we can do to trace this matter further. As can be seen
from the overview page, the Tor network is designed to make tracing of
users impossible. The Tor network is run by some 5000 volunteers who
use the free software provided by the Tor Project to run Tor routers.
Client connections are routed through multiple relays, and are
multiplexed together on the connections between relays. The system
does not record logs of client connections or previous hops.

This is because the Tor network is a censorship resistance, privacy,
and anonymity system used by whistle blowers, journalists, Chinese
dissidents skirting the Great Firewall, abuse victims, stalker
targets, the US military, and law enforcement, just to name a few.
See https://www.torproject.org/about/torusers.html.en for more info.

Unfortunately, some people misuse the network. However, compared to
the rate of legitimate use (the IP range in question processes nearly
a gigabit of traffic per second), abuse complaints are rare.
https://www.torproject.org/docs/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.

Comment/Forum Spam

This does not mean that nothing can be done, however.

The Tor project provides an automated DNSRBL for you to query to flag 
posts coming from Tor nodes as requiring special review. You can also
use this DNSRBL to only allow Tor IPs to read but not
post comments. https://www.torproject.org/tordnsel/

However, be aware that this may be just one jerk amongst many
legitimate Tor users who use your forums. You might have luck getting
rid of this jerk by temporarily limiting account creation to require
gmail accounts before posting, or by requiring account creation be
done over non-Tor before posting.

In general, we believe that problems like this are best solved by 
improving your 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

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?

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@google.com. 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

DoS Attacks and Scraping Robots

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,  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 server port:
https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=YOUR_IP&port=80

In general however, we believe that problems like this are best solved
by improving the service to defend against the attack from the Internet
at large. 

Scraping and robot activity 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

Slow DoS attacks aimed to consume the Apache MaxClients limit
(http://www.guerilla-ciso.com/archives/2049) can be alleviated by 
reducing the httpd.conf TimeOut and KeepAliveTimeout config values 
to 15-30 and raising the ServerLimit and MaxClients values to 
something like 3000.

If this fails, DoS attempts can also be solved with iptables-based rate
limiting solutions, load balancers such as nginx, and also IPS devices,
but be aware that Internet traffic is not always uniform in quantity by
IP, due to large corporate and even national outproxies, NATs, and 
services like Tor.
http://kevin.vanzonneveld.net/techblog/article/block_brute_force_attacks_with_iptables/
http://cd34.com/blog/webserver/ddos-attack-mitigation/
http://deflate.medialayer.com/

Brute Force Web Attacks

We're sorry your account has been brute forced. We can try to prevent
our node from connecting to this site, 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.

The Tor project does provide an automated DNSRBL for you to query to 
flag requests from Tor nodes as requiring special treatment: 
https://www.torproject.org/tordnsel/

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 rather than specifically tailoring behavior for Tor. 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

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. 
However, we still recommend using the general approach, as the attack 
will likely simply reappear from an open proxy or other IP once Tor 
is blocked.

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, SQL Injection)

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 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 vulnerabilities that can lead to
situations such as this (PHP webshell/XSS compromise/SQL Injection 
compromise).

E-Commerce 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 for additional 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.

Threats of Violence (Advice for Real-Time Discussion)

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

Last modified 5 weeks ago Last modified on Mar 16, 2014 4:53:10 AM