Handling abuse - like to get your help please
As I am new to this business could somebody please give me a hint how to best handle such an abuse complain - possibly stop it? Thanks, Regards and a nice weekend. we have detected abuse from the IP address xxx.xxx.xxx,xxx, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was automatically generated. Note: Local timezone is +0200 (CEST) /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:50 +0200] "POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:51 +0200] "POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:52 +0200] "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 290 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"
Hello, I generally respond using the templates on this page: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorAbuseTemplat.... Generally the abuser has already stopped or is connected to a new exit node by the time you get a message. Hope that helps!-- Michael CanningPresident - CaveFox Technology Corporationmcanning@cavefox.net 17. Jun 2016 15:35 by pa011@web.de:
As I am new to this business could somebody please give me a hint how to best handle such an abuse complain - possibly stop it?
Thanks, Regards and a nice weekend.
we have detected abuse from the IP address xxx.xxx.xxx,xxx, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate.
Log lines are given below, but please ask if you require any further information.
If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was automatically generated.
Note: Local timezone is +0200 (CEST)
/var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:50 +0200] "POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:51 +0200] "POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:52 +0200] "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 290 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"
On 06/17/2016 09:35 PM, pa011 wrote:
As I am new to this business could somebody please give me a hint how to best handle such an abuse complain - possibly stop it?
You can explain Tor, offer to block that destination from your exit, and offer your help so they can treat Tor users differently in general. Teaching them that not all Tor users they will see are bad, and they should not outright block Tor, etc. Often these reports are generated automatically by some intrusion detection systems and are purely informational. -- Moritz Bartl https://www.torservers.net/
Thank you both ! @ Michael: that’s exactly what I did so far and in the past @ Moritz: I will try my best - yes it was an automated response with just an name in Germany and no IP given, that I could possibly block "HTTP/1.1 404 293..." are these the ports the traffic went trough ? Am 17.06.2016 um 21:42 schrieb Moritz Bartl:
On 06/17/2016 09:35 PM, pa011 wrote:
As I am new to this business could somebody please give me a hint how to best handle such an abuse complain - possibly stop it?
You can explain Tor, offer to block that destination from your exit, and offer your help so they can treat Tor users differently in general. Teaching them that not all Tor users they will see are bad, and they should not outright block Tor, etc.
Often these reports are generated automatically by some intrusion detection systems and are purely informational.
On 2016-06-17 at 21:51, pa011 wrote:
Thank you both !
@ Michael: that’s exactly what I did so far and in the past @ Moritz: I will try my best - yes it was an automated response with just an name in Germany and no IP given, that I could possibly block
"HTTP/1.1 404 293..." are these the ports the traffic went trough ?
Hi, Glad to hear other people already helped you out with your first question :) To answer this one: No, this is just the HTTP version (so protocol and version), the HTTP status code (404 for "Not Found"; file was not found on the server) and the size of the message that was transmitted to the client, 293 bytes in this case. Best Regards, Michael Armbruster
Thank you Michael, solving that obviously easy question :-) So what was this "attac" then about, on which way, how can I see that ? Nice weekend to all Paul Am 17.06.2016 um 21:53 schrieb Michael Armbruster:
On 2016-06-17 at 21:51, pa011 wrote:
Thank you both !
@ Michael: that’s exactly what I did so far and in the past @ Moritz: I will try my best - yes it was an automated response with just an name in Germany and no IP given, that I could possibly block
"HTTP/1.1 404 293..." are these the ports the traffic went trough ?
Hi,
Glad to hear other people already helped you out with your first question :)
To answer this one: No, this is just the HTTP version (so protocol and version), the HTTP status code (404 for "Not Found"; file was not found on the server) and the size of the message that was transmitted to the client, 293 bytes in this case.
Best Regards, Michael Armbruster
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2016-06-17 at 22:12, pa011 wrote:
Thank you Michael, solving that obviously easy question :-)
So what was this "attac" then about, on which way, how can I see that ?
Nice weekend to all
Paul
Am 17.06.2016 um 21:53 schrieb Michael Armbruster:
On 2016-06-17 at 21:51, pa011 wrote:
Thank you both !
@ Michael: that’s exactly what I did so far and in the past @ Moritz: I will try my best - yes it was an automated response with just an name in Germany and no IP given, that I could possibly block
"HTTP/1.1 404 293..." are these the ports the traffic went trough ?
Hi,
Glad to hear other people already helped you out with your first question :)
To answer this one: No, this is just the HTTP version (so protocol and version), the HTTP status code (404 for "Not Found"; file was not found on the server) and the size of the message that was transmitted to the client, 293 bytes in this case.
Best Regards, Michael Armbruster
Hi Paul, assuming the default HTTP port, it was an attack to the port 80. Furthermore, the cryptic looking signs (%XX, whereas X is 0-9 or A-F), are url escaped characters. Unescaping them leads to something like this:
/cgi-bin/php-cgi?-d+allow_url_include=on+-d+safe_mode=off+- d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+- d+auto_prepend_file=php://input+-d+cgi.force_redirect=0+- d+cgi.redirect_status_env=0+-n
(I only inserted line breaks, so it does look nicer. The url itself has NO line breaks). So the attacker accessed /cgi-bin/php-cgi on the webserver with some arguments. Looking at those, we can see "allow_url_include=on" and "safe_mode=off" etc. So the attacker tried to modify the CGI servlet (the executable he tried to access) via some url manipulation to deactivate various security features. Now to the other things per log entry. At the beginning of each log entry, we have the IP address of the "attacker" (your node in this case, you replaced it with x characters for anonymity, that's good for this mailing list). Secondly, we see the time when the access took place. Then, we see the method of the request, in this case, its a POST. POST means that we send additional data with our request to the server, while GET does not do that (GET can only send data like the url manipulation does, via the url, though of course, usually you submit important data like the ID of an article you try to read on a news site). Putting all those bits together, we can conclude that an attacker tried to access the PHP executable on the CGI path on a webserver and disabling various security features. The malicious code or data he tried to send to the server was sent via POST data. Though we cannot see the post data, so we can only speculate what the attacker tried to do. A good bet would be to upload a shell to the webserver to gain further access on the server, but that's only speculation. I hope I could answer your question well enough :) Best Regards, Michael
On Fri, Jun 17, 2016, at 09:30 PM, Michael Armbruster wrote:
Hi Paul,
assuming the default HTTP port, it was an attack to the port 80. Furthermore, the cryptic looking signs (%XX, whereas X is 0-9 or A-F), are url escaped characters. Unescaping them leads to something like this:
/cgi-bin/php-cgi?-d+allow_url_include=on+-d+safe_mode=off+- d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+- d+auto_prepend_file=php://input+-d+cgi.force_redirect=0+- d+cgi.redirect_status_env=0+-n
...
Putting all those bits together, we can conclude that an attacker tried to access the PHP executable on the CGI path on a webserver and disabling various security features. The malicious code or data he tried to send to the server was sent via POST data. Though we cannot see the post data, so we can only speculate what the attacker tried to do. A good bet would be to upload a shell to the webserver to gain further access on the server, but that's only speculation.
Specifically, this looks like https://www.exploit-db.com/exploits/29290/ - server operators take note. GD -- http://www.fastmail.com - Accessible with your email software or over the web
I only got 1 abuse complaint, but I also only ran a Tor node for about a month with a reduced exit policy. I explained that I was running a Tor exit node, told them I blocked the offending address, and then linked to the Tor Project website for more info. They thanked me for my time, and marked the problem as resolved. Interesting enough, the abuse complaint was from Webiron, and was never marked as "resolved" on their website.
Hello, Thanks for running an exit relay. That is just an automated email message. You do not want to reply to every single automated message you receive, firstly because these replies go into a black hole and they are not read by any humans, so your effort may be useless. Generally, you should only reply to abuse reports which are personalized and properly addressed, indicating a clear problem or concern, sent by simple internet users, authorities, investigatory bodies, etc. The emails don't have to come from some organization/government/authority in order to demand reply, simple concerned users are also rightful to receive a human written personalized reply. You will quickly learn to make the difference between an automated message and a real abuse report. Over 90% of the abuse reports are fail2ban automated emails, emails sent by intrusion preventing systems / firewalls - some of them clearly state it's an automated message, others claim not to be responsible for the content, others are addressed to 'whom it may concern', these are all the same, copy/pasted text emails spammed to the abuse addresses. These are not by any means strict rules, you are free to reply to whatever you want, this is just my advice and purely informational. I run quite a bunch of exits. On 6/17/2016 11:12 PM, pa011 wrote:
Thank you Michael, solving that obviously easy question :-)
So what was this "attac" then about, on which way, how can I see that ?
Nice weekend to all
Paul
Am 17.06.2016 um 21:53 schrieb Michael Armbruster:
On 2016-06-17 at 21:51, pa011 wrote:
Thank you both !
@ Michael: that’s exactly what I did so far and in the past @ Moritz: I will try my best - yes it was an automated response with just an name in Germany and no IP given, that I could possibly block
"HTTP/1.1 404 293..." are these the ports the traffic went trough ?
Hi,
Glad to hear other people already helped you out with your first question :)
To answer this one: No, this is just the HTTP version (so protocol and version), the HTTP status code (404 for "Not Found"; file was not found on the server) and the size of the message that was transmitted to the client, 293 bytes in this case.
Best Regards, Michael Armbruster
Hi all, thanks again for your hints - in my case they obviously find Tor less fancy - their response today is following: "Hello. You need to take steps to ensure that the complaint would be no longer received. This software is only allowed if there are no complaints on the server." As I cant close Port 80 and the next attack would be a different target I guess there is not much room for response :-( Rgds Paul Am 18.06.2016 um 03:05 schrieb s7r:
Hello,
Thanks for running an exit relay. That is just an automated email message. You do not want to reply to every single automated message you receive, firstly because these replies go into a black hole and they are not read by any humans, so your effort may be useless.
Generally, you should only reply to abuse reports which are personalized and properly addressed, indicating a clear problem or concern, sent by simple internet users, authorities, investigatory bodies, etc. The emails don't have to come from some organization/government/authority in order to demand reply, simple concerned users are also rightful to receive a human written personalized reply. You will quickly learn to make the difference between an automated message and a real abuse report.
Over 90% of the abuse reports are fail2ban automated emails, emails sent by intrusion preventing systems / firewalls - some of them clearly state it's an automated message, others claim not to be responsible for the content, others are addressed to 'whom it may concern', these are all the same, copy/pasted text emails spammed to the abuse addresses.
These are not by any means strict rules, you are free to reply to whatever you want, this is just my advice and purely informational. I run quite a bunch of exits.
On 6/17/2016 11:12 PM, pa011 wrote:
Thank you Michael, solving that obviously easy question :-)
So what was this "attac" then about, on which way, how can I see that ?
Nice weekend to all
Paul
Am 17.06.2016 um 21:53 schrieb Michael Armbruster:
On 2016-06-17 at 21:51, pa011 wrote:
Thank you both !
@ Michael: that’s exactly what I did so far and in the past @ Moritz: I will try my best - yes it was an automated response with just an name in Germany and no IP given, that I could possibly block
"HTTP/1.1 404 293..." are these the ports the traffic went trough ?
Hi,
Glad to hear other people already helped you out with your first question :)
To answer this one: No, this is just the HTTP version (so protocol and version), the HTTP status code (404 for "Not Found"; file was not found on the server) and the size of the message that was transmitted to the client, 293 bytes in this case.
Best Regards, Michael Armbruster
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Jun 20, 2016, at 4:19 AM, pa011 <pa011@web.de> wrote:
Hi all,
thanks again for your hints - in my case they obviously find Tor less fancy - their response today is following:
"Hello. You need to take steps to ensure that the complaint would be no longer received. This software is only allowed if there are no complaints on the server."
As I cant close Port 80 and the next attack would be a different target I guess there is not much room for response :-(
Rgds
Paul
Paul, This is a recurring issue that will not go away, because protecting malicious traffic is part of the foundational Tor philosophy. Tor very intentionally has no ability (beyond rudimentary port/host blocking) to control the type of traffic it carries, there are no plans to add any sort of IDS functionality, and filtering exit relay traffic is frowned upon by the Tor community. This is why abuse reports happen, and it's the primary reason that Tor relays are blocked by so many services—typically not because folks are against personal privacy, but because they simply take a very practical approach to network security. So, if you (or your ISP) determine that the benefits of Tor aren’t compelling enough to turn a blind eye to malicious Tor traffic and the abuse reports it generates, then your only real options are to either not run an exit, or not run Tor at all. That’s just the way it is. Jon
Jon, all others, yes I understand what you say and obviously have to accept the ISP's wishes (order). But before giving up a 100Mbit/s exit I would like to understand more about the ISP's reasons and burdens: - is it just the more work for rather poor money handling(forwarding) those abuses ? - to whom else dose he have to report what he is doing with the gotten abuses? - must he answer to the origin of the abuse? - who is getting a copy of them(if at all)? - can he loose his license as a ISP (with to many or badly handled abuses)? - are there any regulatory burdens for them - if so which ones? - are ISP's treated different in different parts of the world? Answers here might help me and others in bringing forward the discussion with them. Paul Am 21.06.2016 um 15:38 schrieb BlinkTor:
On Jun 20, 2016, at 4:19 AM, pa011 <pa011@web.de> wrote:
Hi all,
thanks again for your hints - in my case they obviously find Tor less fancy - their response today is following:
"Hello. You need to take steps to ensure that the complaint would be no longer received. This software is only allowed if there are no complaints on the server."
As I cant close Port 80 and the next attack would be a different target I guess there is not much room for response :-(
Rgds
Paul
Paul,
This is a recurring issue that will not go away, because protecting malicious traffic is part of the foundational Tor philosophy. Tor very intentionally has no ability (beyond rudimentary port/host blocking) to control the type of traffic it carries, there are no plans to add any sort of IDS functionality, and filtering exit relay traffic is frowned upon by the Tor community. This is why abuse reports happen, and it's the primary reason that Tor relays are blocked by so many services—typically not because folks are against personal privacy, but because they simply take a very practical approach to network security. So, if you (or your ISP) determine that the benefits of Tor aren’t compelling enough to turn a blind eye to malicious Tor traffic and the abuse reports it generates, then your only real options are to either not run an exit, or not run Tor at all.
That’s just the way it is.
Jon
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
If you know your ISP, the best thing to do is try to schedule a face-to-face meeting with their management and security personnel. Be prepared to explain Tor, its essential function, and both the pros and cons of running an exit. Then listen to their concerns, and try to address them. Ultimately, if they’re not on board with the basic idea of running an exit, none of your other questions matter—because they’re not going to get paid for the hassle of running Tor. They have to be willing to host your exit purely for the sake of the warm fuzzy feeling of knowing they might be helping some oppressed soul somewhere, or at least annoying the NSA and its international counterparts. Or, find an online “faceless” ISP that specifically permits Tor exits in its AUP.
Exits are badly needed, but is it economically feasible to change to a relay? Based on your cost, and the ISP attitude to a relay only, does it make sense to be a relay instead - and still provide for the Tor community? I would be curious also to know if many of the ISP's have a higher level that gives them grief if they fail to act. I personally know my provider CEO, and he has no problem at all with what I run (just 2 relays now) unless many complaints occur. He stated that the government (FBI) starts monitoring after a few complaints from "certain" factions and he wants to avoid that. He has actually considered running his own exit after I talked to him, he fully understands and supports the ideals. Me On 06/21/2016 10:36 AM, pa011 wrote:
Jon, all others,
yes I understand what you say and obviously have to accept the ISP's wishes (order).
But before giving up a 100Mbit/s exit I would like to understand more about the ISP's reasons and burdens:
- is it just the more work for rather poor money handling(forwarding) those abuses ? - to whom else dose he have to report what he is doing with the gotten abuses? - must he answer to the origin of the abuse? - who is getting a copy of them(if at all)? - can he loose his license as a ISP (with to many or badly handled abuses)? - are there any regulatory burdens for them - if so which ones? - are ISP's treated different in different parts of the world?
Answers here might help me and others in bringing forward the discussion with them.
Paul
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
If it is Tor philosophy to prevent criminal activity then should not tor develop other tools apart from port and IP blocking? I am less certain that we can ring our hands of this issue. We will have fewer and fewer exit nodes until the gross attacks like multiple login attempts are restrained in someway. Those exit nodes that have such restrictions would announce the fact on atlas. Gerry Sent from my Cyanogen phone On 21 Jun 2016 14:39, BlinkTor <toradmin@brazoslink.net> wrote: On Jun 20, 2016, at 4:19 AM, pa011 <pa011@web.de> wrote:
Hi all,
thanks again for your hints - in my case they obviously find Tor less fancy - their response today is following:
"Hello. You need to take steps to ensure that the complaint would be no longer received. This software is only allowed if there are no complaints on the server."
As I cant close Port 80 and the next attack would be a different target I guess there is not much room for response :-(
Rgds
Paul
Paul, This is a recurring issue that will not go away, because protecting malicious traffic is part of the foundational Tor philosophy. Tor very intentionally has no ability (beyond rudimentary port/host blocking) to control the type of traffic it carries, there are no plans to add any sort of IDS functionality, and filtering exit relay traffic is frowned upon by the Tor community. This is why abuse reports happen, and it's the primary reason that Tor relays are blocked by so many services—typically not because folks are against personal privacy, but because they simply take a very practical approach to network security. So, if you (or your ISP) determine that the benefits of Tor aren’t compelling enough to turn a blind eye to malicious Tor traffic and the abuse reports it generates, then your only real options are to either not run an exit, or not run Tor at all. That’s just the way it is. Jon _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
But the point of Tor is to promote open access to the Internet. Once Tor starts filtering traffic, it's no better than the government censorship so many people use Tor to get around. They'd go from one filter to another. I understand your point, but I don't think we can accurately detect malicious traffic without compromising the security of other Tor users. Even if we could, there's always the 1% of legitimate uses that would be marked as malicious. Security, privacy, or convenience, choose any 2. On Jun 21, 2016 9:46 AM, <gerard@bulger.co.uk> wrote:
If it is Tor philosophy to prevent criminal activity then should not tor develop other tools apart from port and IP blocking? I am less certain that we can ring our hands of this issue. We will have fewer and fewer exit nodes until the gross attacks like multiple login attempts are restrained in someway. Those exit nodes that have such restrictions would announce the fact on atlas.
Gerry
Sent from my Cyanogen phone On 21 Jun 2016 14:39, BlinkTor <toradmin@brazoslink.net> wrote:
On Jun 20, 2016, at 4:19 AM, pa011 <pa011@web.de> wrote:
Hi all,
thanks again for your hints - in my case they obviously find Tor less fancy - their response today is following:
"Hello. You need to take steps to ensure that the complaint would be no longer received. This software is only allowed if there are no complaints on the server."
As I cant close Port 80 and the next attack would be a different target I guess there is not much room for response :-(
Rgds
Paul
Paul,
This is a recurring issue that will not go away, because protecting malicious traffic is part of the foundational Tor philosophy. Tor very intentionally has no ability (beyond rudimentary port/host blocking) to control the type of traffic it carries, there are no plans to add any sort of IDS functionality, and filtering exit relay traffic is frowned upon by the Tor community. This is why abuse reports happen, and it's the primary reason that Tor relays are blocked by so many services—typically not because folks are against personal privacy, but because they simply take a very practical approach to network security. So, if you (or your ISP) determine that the benefits of Tor aren’t compelling enough to turn a blind eye to malicious Tor traffic and the abuse reports it generates, then your only real options are to either not run an exit, or not run Tor at all.
That’s just the way it is.
Jon
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tuesday, June 21, 2016 09:52:43 AM Tristan wrote:
But the point of Tor is to promote open access to the Internet. Once Tor starts filtering traffic, it's no better than the government censorship so many people use Tor to get around. They'd go from one filter to another.
This is not such an absolute truth as you make it sound. A filter running on the exit node that kicks in, say, when it detects five hundred http connections from the same middle relay in under ten seconds (or whatever would be considered clearly obvious "undesirable behaviour" - would not trigger for 99% of legitimate uses of tor. It's probably true that we could only detect a small fraction of all malicious traffic with high confidence, but if we could deter *some* obviously malicious traffic with a fairly low false-positive rate, then that's very far away from "government censorship", or switching one form of censorship for another. For example, it would never trigger on the poor chinese or iranian blogger blogging about government brutality, which is one of the prime examples always cited when defending TOR. Such filters wouldn't have to be mandatory; if you want to run an unrestricted exit node, the more power to you. But it would give people donating resources to TOR an additional argument: "Yes, the TOR people do care about abuse of their service, and they're trying to give people ways to address it". Relay operators would have an additional option: Either run an unrestricted exit node, or run just a relay, or run an exit node filtering *some* obviously malicious traffic. This might lead to more people who'd be willing to donate exit bandwith. On the client side, the tor process could flag circuits (locally) that use a filtered exit node so the tor browser could notify the user when an exit node might block legitimate traffic.
I understand your point, but I don't think we can accurately detect malicious traffic without compromising the security of other Tor users.
I'm not sure how this would compromise the security of other Tor users.
On Sat, Jun 18, 2016 at 04:05:23AM +0300, s7r wrote: :Hello, : :Thanks for running an exit relay. :That is just an automated email message. You do not want to reply to :every single automated message you receive, firstly because these :replies go into a black hole and they are not read by any humans, so :your effort may be useless. Yes. The TOR exit we run here isn't an 'official service' but it is a well well loved unofficial service. as such we are able to reject most automated emails about our tor-exit at SMTP time with a terse reason incase we're wrong and the bounce does go to a human. Most exit operators probably don't have that level of control over their mail system but if you get a form letter throw it out becuase that's where yor response will go. We also run a webserver on the exit node with a single static page we copied off somewhere on the tor project webpage: http://tor-exit.csail.mit.edu/ Having an obvious DNS host name may or may not help, but if you can arrange it I'm sure it doesn't hurt. We also have a template respose saved in our ticketing system for complaints we do think warrant a response: ---------------------------------------------------------------------- Hello, The source address 128.52.128.105 is a Tor exit node, and is not the origin point for the traffic in question. See http://tor-exit.csail.mit.edu (which is the host in your logs) for details. That traffic did not originate locally at CSAIL or MIT, and we have no way of identifying the person who sent it or communicating with them. For further information please read http://tor-exit.csail.mit.edu/ the bottom of this page includes information on how to block all Tor exits should you wish to do so (including links to get a list of all current Tor exits). Blocking traffic from this node would simply result in the problem traffic using a different exit. Sincerely, The Infrastructure Group MIT Computer Science and Artificial Intelligence Laboratory ---------------------------------------------------------------------- -Jon
participants (13)
-
BlinkTor -
Geoff Down -
gerard＠bulger.co.uk -
Gumby -
Jonathan Proulx -
Michael Armbruster -
Michael Canning -
Moritz Bartl -
pa011 -
Pascal Schuppli -
s7r -
SuperSluether -
Tristan