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 complainant 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://2019.decvnxytmk.oedi.net/about/overview.html.en
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://decvnxytmk.oedi.net/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://jqlsbiwihs.oedi.net/abuse/).
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 complainant 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://decvnxytmk.oedi.net/projects/tordnsel.html.en
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 "NNTP-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://decvnxytmk.oedi.net/projects/tordnsel.html.en
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://decvnxytmk.oedi.net/projects/tordnsel.html.en
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: https://kvz.io/blog/2007/07/28/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://decvnxytmk.oedi.net/projects/tordnsel.html.en
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: https://www.safer-networking.org/, 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://decvnxytmk.oedi.net/projects/tordnsel.html.en.
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://decvnxytmk.oedi.net/projects/tordnsel.html.en
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 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 whom 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 complainant.
- 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 complainant's problem.
- You are not insane. You may be insane, but we don't want the complainant to guess this is true.
- In many cases, your ISP will be involved as a conduit for the 3rd party complainant. 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 that have been offered to relay operators:
- The ISP/Complainant may very well demand to see logfiles. Fortunately, by default, nothing sensitive is disclosed. You may want a new ISP if they demand access to log files ad hoc.
- The ISP/Complainant may suggest you convert to a non-exit node. 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/Complainant demands you disable Tor. You may want a new ISP as a result.
- The ISP/Complainant 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 complainant 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 Complainant 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