Intrusion Prevention System Software - Snort or Suricata
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers. He personally recommends Snort or Suricata. As far as I understand implementing such a software is not going together with Tor - am I right? Somebody having same or any experience? Thanks Paul
On 04/10/16 08:48 AM, pa011 wrote:
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers.
You can first ask him for a copy of the complaints in order to understand what sort of alleged abuses are taking place. Are the complaints about spam or scraping or web server exploits or something else? You can change your exit policy to reduce likelihood of complaints: https://blog.torproject.org/blog/tips-running-exit-node
As far as I understand implementing such a software is not going together with Tor - am I right?
If your exit nodes tamper with traffic in any way they will be labelled as Bad Exit. (Tor tries to be net neutral.) https://trac.torproject.org/projects/tor/wiki/doc/badRelays
Am 04.10.2016 um 16:48 schrieb krishna e bera:
On 04/10/16 08:48 AM, pa011 wrote:
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers.
You can first ask him for a copy of the complaints in order to understand what sort of alleged abuses are taking place. Are the complaints about spam or scraping or web server exploits or something else?
I do get a copy of every complaint - they are unfortunately: - Http browser intrucion - /var/log/apache2/other_vhosts_access.log:soldierx.com:80 xxx.xxx.xxx.xxx - - [30/Sep/2016:11:14:34 -0400] "HEAD / HTTP/1.0" 302 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12" - invalid VAT number requests -recorded connection attempt(s) from your hosts to our honeypots - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot - botnet drone|Description: Ramnit botnet victim connection to sinkhole details, - attackers used the method/service: *imap*
You can change your exit policy to reduce likelihood of complaints: https://blog.torproject.org/blog/tips-running-exit-node
I know, but I hardly like to block port 80
As far as I understand implementing such a software is not going together with Tor - am I right?
If your exit nodes tamper with traffic in any way they will be labelled as Bad Exit. (Tor tries to be net neutral.) https://trac.torproject.org/projects/tor/wiki/doc/badRelays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
same shit here: Dear User, We are contacting you because of unusual activity coming from your IP address towards the IT infrastructure of the European Commission. In specific, since 03/10/2016, IP addresses 95.85.45.159 & 104.236.225.19 of Digital Ocean, located in the Netherlands (NL) and the USA respectively, have submitted a significantly large number of invalid VAT number requests as compared to the total number of requests (89,59% & 89,96% respectively) towards VAT numbers from a multiple of EU member States (MS) through the VIES on the Web service (http://ec.europa.eu/taxation_customs/vies/). For more information on Invalid VAT number requests please refer to FAQ, questions 7, 11, 12, 13 and 20 of the VIES on the WEB site (http://ec.europa.eu/taxation_customs/vies/faq.html). The scope of our team is to monitor on a daily basis the performance of the VIES-on-the-Web (VoW) service in order to ensure its performance in accordance with the standards agreed upon between EU's Directorate General for Taxation and Customs Union (DG TAXUD) and the EU Member States. Our objective is to secure constant and uninterrupted availability and flow of traffic (requests for VAT validation) at all times. Under this framework, our team intervenes whenever there is out of the ordinary, unusual and potentially suspicious use of the system that violates the rules of use as they are stated in the Specific disclaimer for this service, which is available at the VoW site (http://ec.europa.eu/taxation_customs/vies/disclaimer.html). Consequently, in order to allow flawless use of the service, we were obliged to block the access to VIES on the Web for the IP address 88.198.110.130. Following our action, we would like to know if you are aware of this situation. Furthermore, your cooperation and contribution is necessary in order to determine the reason for this occurrence. Please inform us if this behaviour is normal and if such, how often it should occur; we would then take action to unblock the traffic coming from the corresponding IP address assuming you will agree to follow a set ITSM VIES/Web Team "ITSM2 is a contracted support partner for the IT Service Management of the European Commission. This e-mail is a reply to your message sent to the TAXUD-VIESWEB@ec.europa.eu<mailto:TAXUD-VIESWEB@ec.europa.eu> e-mail. Answers provided by the contactor are on behalf and according to policy guidelines of DG TAXUD, but not binding for the European Commission." I am so done with it, I added ExitPolicy reject 147.67.136.103 # TAX SPAM ExitPolicy reject 147.67.136.21 # TAX SPAM ExitPolicy reject 147.67.119.103 # TAX SPAM ExitPolicy reject 147.67.119.3 # TAX SPAM ExitPolicy reject 147.67.136.3 # TAX SPAM ExitPolicy reject 147.67.119.21 # TAX SPAM Thats going on for months now and by all means, this is not free speech ... Markus. 2016-10-04 17:42 GMT+02:00 pa011 <pa011@web.de>:
Am 04.10.2016 um 16:48 schrieb krishna e bera:
On 04/10/16 08:48 AM, pa011 wrote:
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers.
You can first ask him for a copy of the complaints in order to understand what sort of alleged abuses are taking place. Are the complaints about spam or scraping or web server exploits or something else?
I do get a copy of every complaint - they are unfortunately:
- Http browser intrucion - /var/log/apache2/other_vhosts_access.log:soldierx.com:80 xxx.xxx.xxx.xxx - - [30/Sep/2016:11:14:34 -0400] "HEAD / HTTP/1.0" 302 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12"
- invalid VAT number requests
-recorded connection attempt(s) from your hosts to our honeypots
- Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
- botnet drone|Description: Ramnit botnet victim connection to sinkhole details,
- attackers used the method/service: *imap*
You can change your exit policy to reduce likelihood of complaints: https://blog.torproject.org/blog/tips-running-exit-node
I know, but I hardly like to block port 80
As far as I understand implementing such a software is not going together with Tor - am I right?
If your exit nodes tamper with traffic in any way they will be labelled as Bad Exit. (Tor tries to be net neutral.) https://trac.torproject.org/projects/tor/wiki/doc/badRelays
_______________________________________________ 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
Me too Markus -could fill a folder with that tax issue :-(( Costing a lot of time to answer and restrict the IPs Plus my ISP moaning with good reason: "It's not just about you, but you're giving a bad reputation to one /21 and one /22 subnet. That's ~ 3000 IPs which are potentionaly endagered to be marked as source of malicious content / blacklisted / whatever ... so you see, this is quite critical for us." Am 04.10.2016 um 17:48 schrieb Markus Koch:
same shit here:
Dear User, We are contacting you because of unusual activity coming from your IP address towards the IT infrastructure of the European Commission. In specific, since 03/10/2016, IP addresses 95.85.45.159 & 104.236.225.19 of Digital Ocean, located in the Netherlands (NL) and the USA respectively, have submitted a significantly large number of invalid VAT number requests as compared to the total number of requests (89,59% & 89,96% respectively) towards VAT numbers from a multiple of EU member States (MS) through the VIES on the Web service (http://ec.europa.eu/taxation_customs/vies/). For more information on Invalid VAT number requests please refer to FAQ, questions 7, 11, 12, 13 and 20 of the VIES on the WEB site (http://ec.europa.eu/taxation_customs/vies/faq.html). The scope of our team is to monitor on a daily basis the performance of the VIES-on-the-Web (VoW) service in order to ensure its performance in accordance with the standards agreed upon between EU's Directorate General for Taxation and Customs Union (DG TAXUD) and the EU Member States. Our objective is to secure constant and uninterrupted availability and flow of traffic (requests for VAT validation) at all times. Under this framework, our team intervenes whenever there is out of the ordinary, unusual and potentially suspicious use of the system that violates the rules of use as they are stated in the Specific disclaimer for this service, which is available at the VoW site (http://ec.europa.eu/taxation_customs/vies/disclaimer.html). Consequently, in order to allow flawless use of the service, we were obliged to block the access to VIES on the Web for the IP address 88.198.110.130. Following our action, we would like to know if you are aware of this situation. Furthermore, your cooperation and contribution is necessary in order to determine the reason for this occurrence. Please inform us if this behaviour is normal and if such, how often it should occur; we would then take action to unblock the traffic coming from the corresponding IP address assuming you will agree to follow a set ITSM VIES/Web Team "ITSM2 is a contracted support partner for the IT Service Management of the European Commission. This e-mail is a reply to your message sent to the TAXUD-VIESWEB@ec.europa.eu<mailto:TAXUD-VIESWEB@ec.europa.eu> e-mail. Answers provided by the contactor are on behalf and according to policy guidelines of DG TAXUD, but not binding for the European Commission."
I am so done with it, I added
ExitPolicy reject 147.67.136.103 # TAX SPAM ExitPolicy reject 147.67.136.21 # TAX SPAM ExitPolicy reject 147.67.119.103 # TAX SPAM ExitPolicy reject 147.67.119.3 # TAX SPAM ExitPolicy reject 147.67.136.3 # TAX SPAM ExitPolicy reject 147.67.119.21 # TAX SPAM
Thats going on for months now and by all means, this is not free speech ...
Markus.
2016-10-04 17:42 GMT+02:00 pa011 <pa011@web.de>:
Am 04.10.2016 um 16:48 schrieb krishna e bera:
On 04/10/16 08:48 AM, pa011 wrote:
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers.
You can first ask him for a copy of the complaints in order to understand what sort of alleged abuses are taking place. Are the complaints about spam or scraping or web server exploits or something else?
I do get a copy of every complaint - they are unfortunately:
- Http browser intrucion - /var/log/apache2/other_vhosts_access.log:soldierx.com:80 xxx.xxx.xxx.xxx - - [30/Sep/2016:11:14:34 -0400] "HEAD / HTTP/1.0" 302 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12"
- invalid VAT number requests
-recorded connection attempt(s) from your hosts to our honeypots
- Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
- botnet drone|Description: Ramnit botnet victim connection to sinkhole details,
- attackers used the method/service: *imap*
You can change your exit policy to reduce likelihood of complaints: https://blog.torproject.org/blog/tips-running-exit-node
I know, but I hardly like to block port 80
As far as I understand implementing such a software is not going together with Tor - am I right?
If your exit nodes tamper with traffic in any way they will be labelled as Bad Exit. (Tor tries to be net neutral.) https://trac.torproject.org/projects/tor/wiki/doc/badRelays
_______________________________________________ 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
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I don't know what I'm doing different, because I only got 2 complaints in the last 2 months, and that was for SSH and SQL stuff. On Oct 4, 2016 11:01 AM, "pa011" <pa011@web.de> wrote:
Me too Markus -could fill a folder with that tax issue :-(( Costing a lot of time to answer and restrict the IPs
Plus my ISP moaning with good reason: "It's not just about you, but you're giving a bad reputation to one /21 and one /22 subnet. That's ~ 3000 IPs which are potentionaly endagered to be marked as source of malicious content / blacklisted / whatever ... so you see, this is quite critical for us."
Am 04.10.2016 um 17:48 schrieb Markus Koch:
same shit here:
Dear User, We are contacting you because of unusual activity coming from your IP address towards the IT infrastructure of the European Commission. In specific, since 03/10/2016, IP addresses 95.85.45.159 & 104.236.225.19 of Digital Ocean, located in the Netherlands (NL) and the USA respectively, have submitted a significantly large number of invalid VAT number requests as compared to the total number of requests (89,59% & 89,96% respectively) towards VAT numbers from a multiple of EU member States (MS) through the VIES on the Web service (http://ec.europa.eu/taxation_customs/vies/). For more information on Invalid VAT number requests please refer to FAQ, questions 7, 11, 12, 13 and 20 of the VIES on the WEB site (http://ec.europa.eu/taxation_customs/vies/faq.html). The scope of our team is to monitor on a daily basis the performance of the VIES-on-the-Web (VoW) service in order to ensure its performance in accordance with the standards agreed upon between EU's Directorate General for Taxation and Customs Union (DG TAXUD) and the EU Member States. Our objective is to secure constant and uninterrupted availability and flow of traffic (requests for VAT validation) at all times. Under this framework, our team intervenes whenever there is out of the ordinary, unusual and potentially suspicious use of the system that violates the rules of use as they are stated in the Specific disclaimer for this service, which is available at the VoW site (http://ec.europa.eu/taxation_customs/vies/disclaimer.html). Consequently, in order to allow flawless use of the service, we were obliged to block the access to VIES on the Web for the IP address 88.198.110.130. Following our action, we would like to know if you are aware of this situation. Furthermore, your cooperation and contribution is necessary in order to determine the reason for this occurrence. Please inform us if this behaviour is normal and if such, how often it should occur; we would then take action to unblock the traffic coming from the corresponding IP address assuming you will agree to follow a set ITSM VIES/Web Team "ITSM2 is a contracted support partner for the IT Service Management of the European Commission. This e-mail is a reply to your message sent to the TAXUD-VIESWEB@ec.europa.eu<mailto:TAXUD-VIESWEB@ec.europa.eu> e-mail. Answers provided by the contactor are on behalf and according to policy guidelines of DG TAXUD, but not binding for the European Commission."
I am so done with it, I added
ExitPolicy reject 147.67.136.103 # TAX SPAM ExitPolicy reject 147.67.136.21 # TAX SPAM ExitPolicy reject 147.67.119.103 # TAX SPAM ExitPolicy reject 147.67.119.3 # TAX SPAM ExitPolicy reject 147.67.136.3 # TAX SPAM ExitPolicy reject 147.67.119.21 # TAX SPAM
Thats going on for months now and by all means, this is not free speech ...
Markus.
2016-10-04 17:42 GMT+02:00 pa011 <pa011@web.de>:
Am 04.10.2016 um 16:48 schrieb krishna e bera:
On 04/10/16 08:48 AM, pa011 wrote:
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers.
You can first ask him for a copy of the complaints in order to understand what sort of alleged abuses are taking place. Are the complaints about spam or scraping or web server exploits or something else?
I do get a copy of every complaint - they are unfortunately:
- Http browser intrucion - /var/log/apache2/other_vhosts_access.log: soldierx.com:80 xxx.xxx.xxx.xxx - - [30/Sep/2016:11:14:34 -0400] "HEAD / HTTP/1.0" 302 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12"
- invalid VAT number requests
-recorded connection attempt(s) from your hosts to our honeypots
- Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
- botnet drone|Description: Ramnit botnet victim connection to sinkhole details,
- attackers used the method/service: *imap*
You can change your exit policy to reduce likelihood of complaints: https://blog.torproject.org/blog/tips-running-exit-node
I know, but I hardly like to block port 80
As far as I understand implementing such a software is not going together with Tor - am I right?
If your exit nodes tamper with traffic in any way they will be labelled as Bad Exit. (Tor tries to be net neutral.) https://trac.torproject.org/projects/tor/wiki/doc/badRelays
_______________________________________________ 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
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
Short answer: ISP I got 2 abuse mails (1 false positive) from Hostwinds in 4 months and I get weekly mass reports from DigitalOcean. And the thing that pisses me off is: Its all bots or Tax spam or other stuff I got weeks/months ago. Different day, same shitty abuse mail. Markus 2016-10-04 18:03 GMT+02:00 Tristan <supersluether@gmail.com>:
I don't know what I'm doing different, because I only got 2 complaints in the last 2 months, and that was for SSH and SQL stuff.
On Oct 4, 2016 11:01 AM, "pa011" <pa011@web.de> wrote:
Me too Markus -could fill a folder with that tax issue :-(( Costing a lot of time to answer and restrict the IPs
Plus my ISP moaning with good reason: "It's not just about you, but you're giving a bad reputation to one /21 and one /22 subnet. That's ~ 3000 IPs which are potentionaly endagered to be marked as source of malicious content / blacklisted / whatever ... so you see, this is quite critical for us."
Am 04.10.2016 um 17:48 schrieb Markus Koch:
same shit here:
Dear User, We are contacting you because of unusual activity coming from your IP address towards the IT infrastructure of the European Commission. In specific, since 03/10/2016, IP addresses 95.85.45.159 & 104.236.225.19 of Digital Ocean, located in the Netherlands (NL) and the USA respectively, have submitted a significantly large number of invalid VAT number requests as compared to the total number of requests (89,59% & 89,96% respectively) towards VAT numbers from a multiple of EU member States (MS) through the VIES on the Web service (http://ec.europa.eu/taxation_customs/vies/). For more information on Invalid VAT number requests please refer to FAQ, questions 7, 11, 12, 13 and 20 of the VIES on the WEB site (http://ec.europa.eu/taxation_customs/vies/faq.html). The scope of our team is to monitor on a daily basis the performance of the VIES-on-the-Web (VoW) service in order to ensure its performance in accordance with the standards agreed upon between EU's Directorate General for Taxation and Customs Union (DG TAXUD) and the EU Member States. Our objective is to secure constant and uninterrupted availability and flow of traffic (requests for VAT validation) at all times. Under this framework, our team intervenes whenever there is out of the ordinary, unusual and potentially suspicious use of the system that violates the rules of use as they are stated in the Specific disclaimer for this service, which is available at the VoW site (http://ec.europa.eu/taxation_customs/vies/disclaimer.html). Consequently, in order to allow flawless use of the service, we were obliged to block the access to VIES on the Web for the IP address 88.198.110.130. Following our action, we would like to know if you are aware of this situation. Furthermore, your cooperation and contribution is necessary in order to determine the reason for this occurrence. Please inform us if this behaviour is normal and if such, how often it should occur; we would then take action to unblock the traffic coming from the corresponding IP address assuming you will agree to follow a set ITSM VIES/Web Team "ITSM2 is a contracted support partner for the IT Service Management of the European Commission. This e-mail is a reply to your message sent to the TAXUD-VIESWEB@ec.europa.eu<mailto:TAXUD-VIESWEB@ec.europa.eu> e-mail. Answers provided by the contactor are on behalf and according to policy guidelines of DG TAXUD, but not binding for the European Commission."
I am so done with it, I added
ExitPolicy reject 147.67.136.103 # TAX SPAM ExitPolicy reject 147.67.136.21 # TAX SPAM ExitPolicy reject 147.67.119.103 # TAX SPAM ExitPolicy reject 147.67.119.3 # TAX SPAM ExitPolicy reject 147.67.136.3 # TAX SPAM ExitPolicy reject 147.67.119.21 # TAX SPAM
Thats going on for months now and by all means, this is not free speech ...
Markus.
2016-10-04 17:42 GMT+02:00 pa011 <pa011@web.de>:
Am 04.10.2016 um 16:48 schrieb krishna e bera:
On 04/10/16 08:48 AM, pa011 wrote:
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers.
You can first ask him for a copy of the complaints in order to understand what sort of alleged abuses are taking place. Are the complaints about spam or scraping or web server exploits or something else?
I do get a copy of every complaint - they are unfortunately:
- Http browser intrucion - /var/log/apache2/other_vhosts_access.log:soldierx.com:80 xxx.xxx.xxx.xxx - - [30/Sep/2016:11:14:34 -0400] "HEAD / HTTP/1.0" 302 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12"
- invalid VAT number requests
-recorded connection attempt(s) from your hosts to our honeypots
- Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
- botnet drone|Description: Ramnit botnet victim connection to sinkhole details,
- attackers used the method/service: *imap*
You can change your exit policy to reduce likelihood of complaints: https://blog.torproject.org/blog/tips-running-exit-node
I know, but I hardly like to block port 80
As far as I understand implementing such a software is not going together with Tor - am I right?
If your exit nodes tamper with traffic in any way they will be labelled as Bad Exit. (Tor tries to be net neutral.) https://trac.torproject.org/projects/tor/wiki/doc/badRelays
_______________________________________________ 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
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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Yes its ISP - plus 10 times more fire-power both, Markus and me which is 10 times more work, sadly :-( Am 04.10.2016 um 18:12 schrieb Markus Koch:
Short answer: ISP
I got 2 abuse mails (1 false positive) from Hostwinds in 4 months and I get weekly mass reports from DigitalOcean. And the thing that pisses me off is: Its all bots or Tax spam or other stuff I got weeks/months ago. Different day, same shitty abuse mail.
Markus
2016-10-04 18:03 GMT+02:00 Tristan <supersluether@gmail.com>:
I don't know what I'm doing different, because I only got 2 complaints in the last 2 months, and that was for SSH and SQL stuff.
On Oct 4, 2016 11:01 AM, "pa011" <pa011@web.de> wrote:
Me too Markus -could fill a folder with that tax issue :-(( Costing a lot of time to answer and restrict the IPs
Plus my ISP moaning with good reason: "It's not just about you, but you're giving a bad reputation to one /21 and one /22 subnet. That's ~ 3000 IPs which are potentionaly endagered to be marked as source of malicious content / blacklisted / whatever ... so you see, this is quite critical for us."
Am 04.10.2016 um 17:48 schrieb Markus Koch:
same shit here:
Dear User, We are contacting you because of unusual activity coming from your IP address towards the IT infrastructure of the European Commission. In specific, since 03/10/2016, IP addresses 95.85.45.159 & 104.236.225.19 of Digital Ocean, located in the Netherlands (NL) and the USA respectively, have submitted a significantly large number of invalid VAT number requests as compared to the total number of requests (89,59% & 89,96% respectively) towards VAT numbers from a multiple of EU member States (MS) through the VIES on the Web service (http://ec.europa.eu/taxation_customs/vies/). For more information on Invalid VAT number requests please refer to FAQ, questions 7, 11, 12, 13 and 20 of the VIES on the WEB site (http://ec.europa.eu/taxation_customs/vies/faq.html). The scope of our team is to monitor on a daily basis the performance of the VIES-on-the-Web (VoW) service in order to ensure its performance in accordance with the standards agreed upon between EU's Directorate General for Taxation and Customs Union (DG TAXUD) and the EU Member States. Our objective is to secure constant and uninterrupted availability and flow of traffic (requests for VAT validation) at all times. Under this framework, our team intervenes whenever there is out of the ordinary, unusual and potentially suspicious use of the system that violates the rules of use as they are stated in the Specific disclaimer for this service, which is available at the VoW site (http://ec.europa.eu/taxation_customs/vies/disclaimer.html). Consequently, in order to allow flawless use of the service, we were obliged to block the access to VIES on the Web for the IP address 88.198.110.130. Following our action, we would like to know if you are aware of this situation. Furthermore, your cooperation and contribution is necessary in order to determine the reason for this occurrence. Please inform us if this behaviour is normal and if such, how often it should occur; we would then take action to unblock the traffic coming from the corresponding IP address assuming you will agree to follow a set ITSM VIES/Web Team "ITSM2 is a contracted support partner for the IT Service Management of the European Commission. This e-mail is a reply to your message sent to the TAXUD-VIESWEB@ec.europa.eu<mailto:TAXUD-VIESWEB@ec.europa.eu> e-mail. Answers provided by the contactor are on behalf and according to policy guidelines of DG TAXUD, but not binding for the European Commission."
I am so done with it, I added
ExitPolicy reject 147.67.136.103 # TAX SPAM ExitPolicy reject 147.67.136.21 # TAX SPAM ExitPolicy reject 147.67.119.103 # TAX SPAM ExitPolicy reject 147.67.119.3 # TAX SPAM ExitPolicy reject 147.67.136.3 # TAX SPAM ExitPolicy reject 147.67.119.21 # TAX SPAM
Thats going on for months now and by all means, this is not free speech ...
Markus.
2016-10-04 17:42 GMT+02:00 pa011 <pa011@web.de>:
Am 04.10.2016 um 16:48 schrieb krishna e bera:
On 04/10/16 08:48 AM, pa011 wrote: > One of my main ISP is going mad with the number of abuses he gets > from my Exits (currently most on port 80). > He asks me to install "Intrusion Prevention System Software" or > shutting down the servers.
You can first ask him for a copy of the complaints in order to understand what sort of alleged abuses are taking place. Are the complaints about spam or scraping or web server exploits or something else?
I do get a copy of every complaint - they are unfortunately:
- Http browser intrucion - /var/log/apache2/other_vhosts_access.log:soldierx.com:80 xxx.xxx.xxx.xxx - - [30/Sep/2016:11:14:34 -0400] "HEAD / HTTP/1.0" 302 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12"
- invalid VAT number requests
-recorded connection attempt(s) from your hosts to our honeypots
- Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
- botnet drone|Description: Ramnit botnet victim connection to sinkhole details,
- attackers used the method/service: *imap*
You can change your exit policy to reduce likelihood of complaints: https://blog.torproject.org/blog/tips-running-exit-node
I know, but I hardly like to block port 80
> As far as I understand implementing such a software is not going > together with Tor - am I right?
If your exit nodes tamper with traffic in any way they will be labelled as Bad Exit. (Tor tries to be net neutral.) https://trac.torproject.org/projects/tor/wiki/doc/badRelays
_______________________________________________ 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
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
_______________________________________________ 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
Wouldn't it be interesting if we could set up some kind of central "Tor Abuse Center" where all the complaints go, and all the relay operators can help respond to them. I suppose it would be pretty chaotic though... On Oct 4, 2016 11:18 AM, "pa011" <pa011@web.de> wrote:
Yes its ISP - plus 10 times more fire-power both, Markus and me which is 10 times more work, sadly :-(
Am 04.10.2016 um 18:12 schrieb Markus Koch:
Short answer: ISP
I got 2 abuse mails (1 false positive) from Hostwinds in 4 months and I get weekly mass reports from DigitalOcean. And the thing that pisses me off is: Its all bots or Tax spam or other stuff I got weeks/months ago. Different day, same shitty abuse mail.
Markus
2016-10-04 18:03 GMT+02:00 Tristan <supersluether@gmail.com>:
I don't know what I'm doing different, because I only got 2 complaints in the last 2 months, and that was for SSH and SQL stuff.
On Oct 4, 2016 11:01 AM, "pa011" <pa011@web.de> wrote:
Me too Markus -could fill a folder with that tax issue :-(( Costing a lot of time to answer and restrict the IPs
Plus my ISP moaning with good reason: "It's not just about you, but
you're
giving a bad reputation to one /21 and one /22 subnet. That's ~ 3000 IPs which are potentionaly endagered to be marked as source of malicious content / blacklisted / whatever ... so you see, this is quite critical for us."
Am 04.10.2016 um 17:48 schrieb Markus Koch:
same shit here:
Dear User, We are contacting you because of unusual activity coming from your IP address towards the IT infrastructure of the European Commission. In specific, since 03/10/2016, IP addresses 95.85.45.159 & 104.236.225.19 of Digital Ocean, located in the Netherlands (NL) and the USA respectively, have submitted a significantly large number of invalid VAT number requests as compared to the total number of requests (89,59% & 89,96% respectively) towards VAT numbers from a multiple of EU member States (MS) through the VIES on the Web service (http://ec.europa.eu/taxation_customs/vies/). For more information on Invalid VAT number requests please refer to FAQ, questions 7, 11, 12, 13 and 20 of the VIES on the WEB site (http://ec.europa.eu/taxation_customs/vies/faq.html). The scope of our team is to monitor on a daily basis the performance of the VIES-on-the-Web (VoW) service in order to ensure its performance in accordance with the standards agreed upon between EU's Directorate General for Taxation and Customs Union (DG TAXUD) and the EU Member States. Our objective is to secure constant and uninterrupted availability and flow of traffic (requests for VAT validation) at all times. Under this framework, our team intervenes whenever there is out of the ordinary, unusual and potentially suspicious use of the system that violates the rules of use as they are stated in the Specific disclaimer for this service, which is available at the VoW site (http://ec.europa.eu/taxation_customs/vies/disclaimer.html). Consequently, in order to allow flawless use of the service, we were obliged to block the access to VIES on the Web for the IP address 88.198.110.130. Following our action, we would like to know if you are aware of this situation. Furthermore, your cooperation and contribution is necessary in order to determine the reason for this occurrence. Please inform us if this behaviour is normal and if such, how often it should occur; we would then take action to unblock the traffic coming from the corresponding IP address assuming you will agree to follow a set ITSM VIES/Web Team "ITSM2 is a contracted support partner for the IT Service Management of the European Commission. This e-mail is a reply to your message sent to the TAXUD-VIESWEB@ec.europa.eu<mailto:TAXUD-VIESWEB@ec.europa.eu> e-mail. Answers provided by the contactor are on behalf and according to policy guidelines of DG TAXUD, but not binding for the European Commission."
I am so done with it, I added
ExitPolicy reject 147.67.136.103 # TAX SPAM ExitPolicy reject 147.67.136.21 # TAX SPAM ExitPolicy reject 147.67.119.103 # TAX SPAM ExitPolicy reject 147.67.119.3 # TAX SPAM ExitPolicy reject 147.67.136.3 # TAX SPAM ExitPolicy reject 147.67.119.21 # TAX SPAM
Thats going on for months now and by all means, this is not free speech ...
Markus.
2016-10-04 17:42 GMT+02:00 pa011 <pa011@web.de>:
Am 04.10.2016 um 16:48 schrieb krishna e bera: > On 04/10/16 08:48 AM, pa011 wrote: >> One of my main ISP is going mad with the number of abuses he gets >> from my Exits (currently most on port 80). >> He asks me to install "Intrusion Prevention System Software" or >> shutting down the servers. > > You can first ask him for a copy of the complaints in order to > understand what sort of alleged abuses are taking place. Are the > complaints about spam or scraping or web server exploits or something > else?
I do get a copy of every complaint - they are unfortunately:
- Http browser intrucion - /var/log/apache2/other_vhosts_access.log:soldierx.com:80 xxx.xxx.xxx.xxx - - [30/Sep/2016:11:14:34 -0400] "HEAD / HTTP/1.0" 302 192 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12"
- invalid VAT number requests
-recorded connection attempt(s) from your hosts to our honeypots
- Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
- botnet drone|Description: Ramnit botnet victim connection to sinkhole details,
- attackers used the method/service: *imap*
> You can change your exit policy to reduce likelihood of complaints: > https://blog.torproject.org/blog/tips-running-exit-node
I know, but I hardly like to block port 80
>> As far as I understand implementing such a software is not going >> together with Tor - am I right? > > If your exit nodes tamper with traffic in any way they will be > labelled > as Bad Exit. (Tor tries to be net neutral.) > https://trac.torproject.org/projects/tor/wiki/doc/badRelays > > > _______________________________________________ > 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
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
_______________________________________________ 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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 10/04/2016 06:23 PM, Tristan wrote:
Wouldn't it be interesting if we could set up some kind of central "Tor Abuse Center" where all the complaints go, and all the relay operators can help respond to them. I suppose it would be pretty chaotic though...
We actually discussed this briefly again at the recent Tor developers meeting, and it comes up every once in a while. It's an interesting thought experiment, and it would not take much to turn ourselves into an Abuse Management provider. I've seen this actually exists in the commercial space. One thing that makes it hard is that there's no assurance that someone is really only running an exit on a certain IP address; even if the Abuse Management Service verified that that IP address was a Tor exit at that point in time, it cannot in all honesty state that in fact the exit relay process caused a particular network activity or not. I do think we can operate this "in good faith", and we simply cannot set it up in a way that we can make it impossible to misuse. Still, this will not help in this (and related) cases: I have not yet seen proven cases where the reputation of the netblock was endangered, but if an ISP is afraid of that, there's no good way to cooperate. An IDS is their obvious suggestion, which just shows that they don't understand how Tor works. I argue strongly against deploying such systems on Tor exits. It will mess up more than it does good, and it won't be able to reliably detect *and block* bad behaviour. -- Moritz Bartl https://www.torservers.net/
Am 04.10.2016 um 18:46 schrieb Moritz Bartl:
Still, this will not help in this (and related) cases: I have not yet seen proven cases where the reputation of the netblock was endangered, but if an ISP is afraid of that, there's no good way to cooperate. An IDS is their obvious suggestion, which just shows that they don't understand how Tor works.
That is obviously true and kind of shame for a huge ISP, but you cant tell them frankly without putting your one year contract at risk and loosing further room for negotiation over a few thousands mile distance :-(
I argue strongly against deploying such systems on Tor exits. It will mess up more than it does good, and it won't be able to reliably detect *and block* bad behaviour.
100% agreed. Just let us kick out the bots ... Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot I am not in for free speech for bots and anything without a pulse. markus Hello! === You are receiving this e-mail in regard to abuse issues against our clients coming from the host at IP 95.85.45.159. === --- Automated Message - To get a response or report issues with the reports, please see the contact info below. --- --- Report details are at the bottom of the e-mail. For web attacks see the "bot" links for more details about the attack. ---- Webiron is a security service and this e-mail is being sent on behalf of our customers. We do not control how our clients configure their protection and as a result do not control how blocks and bans are generated. We are committed to providing useful information on abuse issues on behalf of our clients to help stop issues related to issues that seem to originate from within your network. We value your time and effort and appreciate your assistance in handling these issues! If you are responsible for abuse issues however the IP being reported does not belong to you, please open a ticket or email us to let us know of the error and we'll correct it as soon as possible. Please note due to the retaliatory nature of attackers and the abundance of internet abuse havens and fake hosting companies, we do not give out the exact IP of our clients. If you require further assistance we will be more than happy to work with you. Just open a ticket our contact us with the details below. -- Who We Are -- A little about our service, we are a server protection solution designed to help hosting companies, their customers, and SoC departments improve their system security, stability and lower TCO and support costs. Please feel free to send us your comments or responses. If you are inquiring for more information you must disclosed the offending IP. To contact us via e-mail, use <support@webiron.com>, however if you require a ticket tracked response you can open one at https://www.webiron.com/abuse-soc-issues.html -- Abuse Criteria -- To be considered abusive a bot must either be a clear danger (IE: exploit attempts, flooding, etc) or match at least two items from the list athttps://www.webiron.com/supporthome/view-article/33-criteria-for-what-makes-... -- Removal Requests -- To be removed entirely from future reports reply to this e-mail with REMOVE (in all caps) in the subject line. Please note this will only stop the e-mail to the address the e-mail was sent to and public notices will remain as your abuse address will be listed on our BABL blacklist. -- Feed/History Links -- IP Abuse Feed: https://www.webiron.com/abuse_feed/95.85.45.159 IP Detailed Information: https://www.webiron.com/iplookup/95.85.45.159 Your Abuse Report History: https://www.webiron.com/abuse_feed/abuse@digitalocean.com --- Blacklist Warning --- In an ongoing effort to stop chronic abuse we maintain several blacklists available as flat data or free public DNSRBL. For more information see: https://www.webiron.com/rbl.html To check the blacklist status of the offending IP, see: https://www.webiron.com/iplookup/95.85.45.159 -- NEW -- We have now opened access to our RBL API allowing direct access to the entire RBL database. For more information please see:https://www.webiron.com/rbl.html Thank you for your support, The WebIron Team ---------------------------------------------------------- *** Note *** - All times are in America/Phoenix (-07:00) ---------------------------------------------------------- Unwanted and or Abusive Web Requests: Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot - Block Type: New Ban - Time: 2016-10-04 00:33:54-07:00 - Port: 80 - Service: http - Report ID: ff681d81-5ce4-4329-8890-49642bd24a77 - Bot Fingerprint: d5930168c39511ee975f5943a5f3faac - Bot Information: https://www.webiron.com/bot_lookup/d5930168c39511ee975f5943a5f3faac - Bot Node Feed: https://www.webiron.com/bot_feed/d5930168c39511ee975f5943a5f3faac - Abused Range: 45.79.79.0/24 - Requested URI: / - User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36 2016-10-04 18:46 GMT+02:00 Moritz Bartl <moritz@torservers.net>:
On 10/04/2016 06:23 PM, Tristan wrote:
Wouldn't it be interesting if we could set up some kind of central "Tor Abuse Center" where all the complaints go, and all the relay operators can help respond to them. I suppose it would be pretty chaotic though...
We actually discussed this briefly again at the recent Tor developers meeting, and it comes up every once in a while. It's an interesting thought experiment, and it would not take much to turn ourselves into an Abuse Management provider. I've seen this actually exists in the commercial space.
One thing that makes it hard is that there's no assurance that someone is really only running an exit on a certain IP address; even if the Abuse Management Service verified that that IP address was a Tor exit at that point in time, it cannot in all honesty state that in fact the exit relay process caused a particular network activity or not.
I do think we can operate this "in good faith", and we simply cannot set it up in a way that we can make it impossible to misuse.
Still, this will not help in this (and related) cases: I have not yet seen proven cases where the reputation of the netblock was endangered, but if an ISP is afraid of that, there's no good way to cooperate. An IDS is their obvious suggestion, which just shows that they don't understand how Tor works. I argue strongly against deploying such systems on Tor exits. It will mess up more than it does good, and it won't be able to reliably detect *and block* bad behaviour.
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I hate Webiron. They never marked any of my IP abuses as resolved, even though I responded and revised my exit policy within 24 hours of the complaint. On Oct 4, 2016 12:10 PM, "Markus Koch" <niftybunny@googlemail.com> wrote:
100% agreed.
Just let us kick out the bots ...
Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
I am not in for free speech for bots and anything without a pulse.
markus
Hello!
=== You are receiving this e-mail in regard to abuse issues against our clients coming from the host at IP 95.85.45.159. ===
--- Automated Message - To get a response or report issues with the reports, please see the contact info below. --- --- Report details are at the bottom of the e-mail. For web attacks see the "bot" links for more details about the attack. ----
Webiron is a security service and this e-mail is being sent on behalf of our customers. We do not control how our clients configure their protection and as a result do not control how blocks and bans are generated.
We are committed to providing useful information on abuse issues on behalf of our clients to help stop issues related to issues that seem to originate from within your network.
We value your time and effort and appreciate your assistance in handling these issues!
If you are responsible for abuse issues however the IP being reported does not belong to you, please open a ticket or email us to let us know of the error and we'll correct it as soon as possible.
Please note due to the retaliatory nature of attackers and the abundance of internet abuse havens and fake hosting companies, we do not give out the exact IP of our clients. If you require further assistance we will be more than happy to work with you. Just open a ticket our contact us with the details below.
-- Who We Are -- A little about our service, we are a server protection solution designed to help hosting companies, their customers, and SoC departments improve their system security, stability and lower TCO and support costs.
Please feel free to send us your comments or responses. If you are inquiring for more information you must disclosed the offending IP. To contact us via e-mail, use <support@webiron.com>, however if you require a ticket tracked response you can open one at https://www.webiron.com/abuse-soc-issues.html
-- Abuse Criteria -- To be considered abusive a bot must either be a clear danger (IE: exploit attempts, flooding, etc) or match at least two items from the list athttps://www.webiron.com/supporthome/view-article/33- criteria-for-what-makes-a-bot-bad.html
-- Removal Requests -- To be removed entirely from future reports reply to this e-mail with REMOVE (in all caps) in the subject line. Please note this will only stop the e-mail to the address the e-mail was sent to and public notices will remain as your abuse address will be listed on our BABL blacklist.
-- Feed/History Links -- IP Abuse Feed: https://www.webiron.com/abuse_feed/95.85.45.159 IP Detailed Information: https://www.webiron.com/iplookup/95.85.45.159 Your Abuse Report History: https://www.webiron.com/abuse_feed/abuse@digitalocean.com
--- Blacklist Warning --- In an ongoing effort to stop chronic abuse we maintain several blacklists available as flat data or free public DNSRBL.
For more information see: https://www.webiron.com/rbl.html
To check the blacklist status of the offending IP, see: https://www.webiron.com/iplookup/95.85.45.159
-- NEW -- We have now opened access to our RBL API allowing direct access to the entire RBL database. For more information please see:https://www.webiron.com/rbl.html
Thank you for your support,
The WebIron Team
---------------------------------------------------------- *** Note *** - All times are in America/Phoenix (-07:00) ----------------------------------------------------------
Unwanted and or Abusive Web Requests:
Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot - Block Type: New Ban - Time: 2016-10-04 00:33:54-07:00 - Port: 80 - Service: http - Report ID: ff681d81-5ce4-4329-8890-49642bd24a77 - Bot Fingerprint: d5930168c39511ee975f5943a5f3faac - Bot Information: https://www.webiron.com/bot_lookup/d5930168c39511ee975f5943a5f3faac - Bot Node Feed: https://www.webiron.com/bot_feed/d5930168c39511ee975f5943a5f3faac - Abused Range: 45.79.79.0/24 - Requested URI: / - User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
2016-10-04 18:46 GMT+02:00 Moritz Bartl <moritz@torservers.net>:
On 10/04/2016 06:23 PM, Tristan wrote:
Wouldn't it be interesting if we could set up some kind of central "Tor Abuse Center" where all the complaints go, and all the relay operators can help respond to them. I suppose it would be pretty chaotic though...
We actually discussed this briefly again at the recent Tor developers meeting, and it comes up every once in a while. It's an interesting thought experiment, and it would not take much to turn ourselves into an Abuse Management provider. I've seen this actually exists in the commercial space.
One thing that makes it hard is that there's no assurance that someone is really only running an exit on a certain IP address; even if the Abuse Management Service verified that that IP address was a Tor exit at that point in time, it cannot in all honesty state that in fact the exit relay process caused a particular network activity or not.
I do think we can operate this "in good faith", and we simply cannot set it up in a way that we can make it impossible to misuse.
Still, this will not help in this (and related) cases: I have not yet seen proven cases where the reputation of the netblock was endangered, but if an ISP is afraid of that, there's no good way to cooperate. An IDS is their obvious suggestion, which just shows that they don't understand how Tor works. I argue strongly against deploying such systems on Tor exits. It will mess up more than it does good, and it won't be able to reliably detect *and block* bad behaviour.
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ 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
Hello, I'm the ISP technician who is negotiating with Paul who started this thread. I just read this whole discussion and I think that there are few things which need to be mentioned. The threat of blocked subnet is real. It happened once to us and we don't want to experience that anymore. Imagine a few hundreds angry customers, who are bombing your support and writing all over the internet about your awful services. The worst thing is, that you can't do anything about it, but wait to some authority to confirm your delist request. Then you spend few days/ weeks searching the newly created discusion threads and keep explaining what happened. That costs a lot of money and energy. The prevention is the best solution. Nowadays IPS can be handled by the owner to filter just what he wants to be filtered. It's not a rocket science. We are using IPS for our webhosting and mailserver segment and I can say it can save work of 2-3 people, who would otherwise constantly write to clients to put some hotfix to their system / change their password / etc. It would be fine, if you start seek for solution how to stop malicious activity comming out of the tor exit nodes and stop seeking reasons why not to do that. Freedom is very important to me, but freedom of one ends where the other begins. Petr "100% agreed. Just let us kick out the bots ... Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot I am not in for free speech for bots and anything without a pulse. markus Hello! === You are receiving this e-mail in regard to abuse issues against our clients coming from the host at IP 95.85.45.159. === --- Automated Message - To get a response or report issues with the reports, please see the contact info below. --- --- Report details are at the bottom of the e-mail. For web attacks see the "bot" links for more details about the attack. ---- Webiron is a security service and this e-mail is being sent on behalf of our customers. We do not control how our clients configure their protection and as a result do not control how blocks and bans are generated. We are committed to providing useful information on abuse issues on behalf of our clients to help stop issues related to issues that seem to originate from within your network. We value your time and effort and appreciate your assistance in handling these issues! If you are responsible for abuse issues however the IP being reported does not belong to you, please open a ticket or email us to let us know of the error and we'll correct it as soon as possible. Please note due to the retaliatory nature of attackers and the abundance of internet abuse havens and fake hosting companies, we do not give out the exact IP of our clients. If you require further assistance we will be more than happy to work with you. Just open a ticket our contact us with the details below. -- Who We Are -- A little about our service, we are a server protection solution designed to help hosting companies, their customers, and SoC departments improve their system security, stability and lower TCO and support costs. Please feel free to send us your comments or responses. If you are inquiring for more information you must disclosed the offending IP. To contact us via e-mail, use <support@webiron.com>, however if you require a ticket tracked response you can open one at https://www.webiron.com/abuse-soc-issues.html -- Abuse Criteria -- To be considered abusive a bot must either be a clear danger (IE: exploit attempts, flooding, etc) or match at least two items from the list athttps://www.webiron.com/supporthome/view-article/33-criteria-for-what -makes-a-bot-bad.html -- Removal Requests -- To be removed entirely from future reports reply to this e-mail with REMOVE (in all caps) in the subject line. Please note this will only stop the e-mail to the address the e-mail was sent to and public notices will remain as your abuse address will be listed on our BABL blacklist. -- Feed/History Links -- IP Abuse Feed: https://www.webiron.com/abuse_feed/95.85.45.159 IP Detailed Information: https://www.webiron.com/iplookup/95.85.45.159 Your Abuse Report History: https://www.webiron.com/abuse_feed/abuse@digitalocean.com --- Blacklist Warning --- In an ongoing effort to stop chronic abuse we maintain several blacklists available as flat data or free public DNSRBL. For more information see: https://www.webiron.com/rbl.html To check the blacklist status of the offending IP, see: https://www.webiron.com/iplookup/95.85.45.159 -- NEW -- We have now opened access to our RBL API allowing direct access to the entire RBL database. For more information please see:https://www.webiron.com/rbl.html Thank you for your support, The WebIron Team ---------------------------------------------------------- *** Note *** - All times are in America/Phoenix (-07:00) ---------------------------------------------------------- Unwanted and or Abusive Web Requests: Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot - Block Type: New Ban - Time: 2016-10-04 00:33:54-07:00 - Port: 80 - Service: http - Report ID: ff681d81-5ce4-4329-8890-49642bd24a77 - Bot Fingerprint: d5930168c39511ee975f5943a5f3faac - Bot Information: https://www.webiron.com/bot_lookup/d5930168c39511ee975f5943a5f3faac - Bot Node Feed: https://www.webiron.com/bot_feed/d5930168c39511ee975f5943a5f3faac - Abused Range: 45.79.79.0/24 - Requested URI: / - User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36 2016-10-04 18:46 GMT+02:00 Moritz Bartl <moritz@torservers.net>:
On 10/04/2016 06:23 PM, Tristan wrote:
Wouldn't it be interesting if we could set up some kind of central "Tor Abuse Center" where all the complaints go, and all the relay operators can help respond to them. I suppose it would be pretty chaotic though...
We actually discussed this briefly again at the recent Tor developers meeting, and it comes up every once in a while. It's an interesting thought experiment, and it would not take much to turn ourselves into an Abuse Management provider. I've seen this actually exists in the commercial space.
One thing that makes it hard is that there's no assurance that someone is really only running an exit on a certain IP address; even if the Abuse Management Service verified that that IP address was a Tor exit at that point in time, it cannot in all honesty state that in fact the exit relay process caused a particular network activity or not.
I do think we can operate this "in good faith", and we simply cannot set it up in a way that we can make it impossible to misuse.
Still, this will not help in this (and related) cases: I have not yet seen proven cases where the reputation of the netblock was endangered, but if an ISP is afraid of that, there's no good way to cooperate. An IDS is their obvious suggestion, which just shows that they don't understand how Tor works. I argue strongly against deploying such systems on Tor exits. It will mess up more than it does good, and it won't be able to reliably detect *and block* bad behaviour.
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ 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"
Just 2 make 1 thing clear: Its not we against you (ISPs). Working myself years ago at an ISP I know the trouble and I understand the issues. Markus 2016-10-04 19:49 GMT+02:00 <oconor@email.cz>:
Hello,
I'm the ISP technician who is negotiating with Paul who started this thread. I just read this whole discussion and I think that there are few things which need to be mentioned.
The threat of blocked subnet is real. It happened once to us and we don't want to experience that anymore. Imagine a few hundreds angry customers, who are bombing your support and writing all over the internet about your awful services. The worst thing is, that you can't do anything about it, but wait to some authority to confirm your delist request. Then you spend few days/weeks searching the newly created discusion threads and keep explaining what happened. That costs a lot of money and energy. The prevention is the best solution.
Nowadays IPS can be handled by the owner to filter just what he wants to be filtered. It's not a rocket science. We are using IPS for our webhosting and mailserver segment and I can say it can save work of 2-3 people, who would otherwise constantly write to clients to put some hotfix to their system / change their password / etc.
It would be fine, if you start seek for solution how to stop malicious activity comming out of the tor exit nodes and stop seeking reasons why not to do that.
Freedom is very important to me, but freedom of one ends where the other begins.
Petr
100% agreed.
Just let us kick out the bots ...
Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
I am not in for free speech for bots and anything without a pulse.
markus
Hello!
=== You are receiving this e-mail in regard to abuse issues against our clients coming from the host at IP 95.85.45.159. ===
--- Automated Message - To get a response or report issues with the reports, please see the contact info below. --- --- Report details are at the bottom of the e-mail. For web attacks see the "bot" links for more details about the attack. ----
Webiron is a security service and this e-mail is being sent on behalf of our customers. We do not control how our clients configure their protection and as a result do not control how blocks and bans are generated.
We are committed to providing useful information on abuse issues on behalf of our clients to help stop issues related to issues that seem to originate from within your network.
We value your time and effort and appreciate your assistance in handling these issues!
If you are responsible for abuse issues however the IP being reported does not belong to you, please open a ticket or email us to let us know of the error and we'll correct it as soon as possible.
Please note due to the retaliatory nature of attackers and the abundance of internet abuse havens and fake hosting companies, we do not give out the exact IP of our clients. If you require further assistance we will be more than happy to work with you. Just open a ticket our contact us with the details below.
-- Who We Are -- A little about our service, we are a server protection solution designed to help hosting companies, their customers, and SoC departments improve their system security, stability and lower TCO and support costs.
Please feel free to send us your comments or responses. If you are inquiring for more information you must disclosed the offending IP. To contact us via e-mail, use <support@webiron.com>, however if you require a ticket tracked response you can open one at https://www.webiron.com/abuse-soc-issues.html
-- Abuse Criteria -- To be considered abusive a bot must either be a clear danger (IE: exploit attempts, flooding, etc) or match at least two items from the list athttps://www.webiron.com/supporthome/view-article/33-criteria-for-what-makes-...
-- Removal Requests -- To be removed entirely from future reports reply to this e-mail with REMOVE (in all caps) in the subject line. Please note this will only stop the e-mail to the address the e-mail was sent to and public notices will remain as your abuse address will be listed on our BABL blacklist.
-- Feed/History Links -- IP Abuse Feed: https://www.webiron.com/abuse_feed/95.85.45.159 IP Detailed Information: https://www.webiron.com/iplookup/95.85.45.159 Your Abuse Report History: https://www.webiron.com/abuse_feed/abuse@digitalocean.com
--- Blacklist Warning --- In an ongoing effort to stop chronic abuse we maintain several blacklists available as flat data or free public DNSRBL.
For more information see: https://www.webiron.com/rbl.html
To check the blacklist status of the offending IP, see: https://www.webiron.com/iplookup/95.85.45.159
-- NEW -- We have now opened access to our RBL API allowing direct access to the entire RBL database. For more information please see:https://www.webiron.com/rbl.html
Thank you for your support,
The WebIron Team
---------------------------------------------------------- *** Note *** - All times are in America/Phoenix (-07:00) ----------------------------------------------------------
Unwanted and or Abusive Web Requests:
Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot - Block Type: New Ban - Time: 2016-10-04 00:33:54-07:00 - Port: 80 - Service: http - Report ID: ff681d81-5ce4-4329-8890-49642bd24a77 - Bot Fingerprint: d5930168c39511ee975f5943a5f3faac - Bot Information: https://www.webiron.com/bot_lookup/d5930168c39511ee975f5943a5f3faac - Bot Node Feed: https://www.webiron.com/bot_feed/d5930168c39511ee975f5943a5f3faac - Abused Range: 45.79.79.0/24 - Requested URI: / - User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
2016-10-04 18:46 GMT+02:00 Moritz Bartl <moritz@torservers.net>:
On 10/04/2016 06:23 PM, Tristan wrote:
Wouldn't it be interesting if we could set up some kind of central "Tor Abuse Center" where all the complaints go, and all the relay operators can help respond to them. I suppose it would be pretty chaotic though...
We actually discussed this briefly again at the recent Tor developers meeting, and it comes up every once in a while. It's an interesting thought experiment, and it would not take much to turn ourselves into an Abuse Management provider. I've seen this actually exists in the commercial space.
One thing that makes it hard is that there's no assurance that someone is really only running an exit on a certain IP address; even if the Abuse Management Service verified that that IP address was a Tor exit at that point in time, it cannot in all honesty state that in fact the exit relay process caused a particular network activity or not.
I do think we can operate this "in good faith", and we simply cannot set it up in a way that we can make it impossible to misuse.
Still, this will not help in this (and related) cases: I have not yet seen proven cases where the reputation of the netblock was endangered, but if an ISP is afraid of that, there's no good way to cooperate. An IDS is their obvious suggestion, which just shows that they don't understand how Tor works. I argue strongly against deploying such systems on Tor exits. It will mess up more than it does good, and it won't be able to reliably detect *and block* bad behaviour.
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ 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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
And I'm not against you (tor admins/operators) ;) I'm really glad that this discussion started, let's see, if we can find some solution. "Just 2 make 1 thing clear: Its not we against you (ISPs). Working myself years ago at an ISP I know the trouble and I understand the issues. Markus 2016-10-04 19:49 GMT+02:00 <oconor@email.cz>:
Hello,
I'm the ISP technician who is negotiating with Paul who started this thread. I just read this whole discussion and I think that there are few things which need to be mentioned.
The threat of blocked subnet is real. It happened once to us and we don't want to experience that anymore. Imagine a few hundreds angry customers, who are bombing your support and writing all over the internet about your awful services. The worst thing is, that you can't do anything about it, but wait to some authority to confirm your delist request. Then you spend few days/weeks searching the newly created discusion threads and keep explaining what happened. That costs a lot of money and energy. The prevention is the best solution.
Nowadays IPS can be handled by the owner to filter just what he wants to be filtered. It's not a rocket science. We are using IPS for our webhosting and mailserver segment and I can say it can save work of 2-3 people, who would otherwise constantly write to clients to put some hotfix to their system / change their password / etc.
It would be fine, if you start seek for solution how to stop malicious activity comming out of the tor exit nodes and stop seeking reasons why not to do that.
Freedom is very important to me, but freedom of one ends where the other begins.
Petr
100% agreed.
Just let us kick out the bots ...
Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot
I am not in for free speech for bots and anything without a pulse.
markus
Hello!
=== You are receiving this e-mail in regard to abuse issues against our clients coming from the host at IP 95.85.45.159. ===
--- Automated Message - To get a response or report issues with the reports, please see the contact info below. --- --- Report details are at the bottom of the e-mail. For web attacks see the "bot" links for more details about the attack. ----
Webiron is a security service and this e-mail is being sent on behalf of our customers. We do not control how our clients configure their protection and as a result do not control how blocks and bans are generated.
We are committed to providing useful information on abuse issues on behalf of our clients to help stop issues related to issues that seem to originate from within your network.
We value your time and effort and appreciate your assistance in handling these issues!
If you are responsible for abuse issues however the IP being reported does not belong to you, please open a ticket or email us to let us know of the error and we'll correct it as soon as possible.
Please note due to the retaliatory nature of attackers and the abundance of internet abuse havens and fake hosting companies, we do not give out the exact IP of our clients. If you require further assistance we will be more than happy to work with you. Just open a ticket our contact us with the details below.
-- Who We Are -- A little about our service, we are a server protection solution designed to help hosting companies, their customers, and SoC departments improve their system security, stability and lower TCO and support costs.
Please feel free to send us your comments or responses. If you are inquiring for more information you must disclosed the offending IP. To contact us via e-mail, use <support@webiron.com>, however if you require a ticket tracked response you can open one at https://www.webiron.com/abuse-soc-issues.html
-- Abuse Criteria -- To be considered abusive a bot must either be a clear danger (IE: exploit attempts, flooding, etc) or match at least two items from the list athttps://www.webiron.com/supporthome/view-article/33-criteria-for-what- makes-a-bot-bad.html
-- Removal Requests -- To be removed entirely from future reports reply to this e-mail with REMOVE (in all caps) in the subject line. Please note this will only stop the e-mail to the address the e-mail was sent to and public notices will remain as your abuse address will be listed on our BABL blacklist.
-- Feed/History Links -- IP Abuse Feed: https://www.webiron.com/abuse_feed/95.85.45.159 IP Detailed Information: https://www.webiron.com/iplookup/95.85.45.159 Your Abuse Report History: https://www.webiron.com/abuse_feed/abuse@digitalocean.com
--- Blacklist Warning --- In an ongoing effort to stop chronic abuse we maintain several blacklists available as flat data or free public DNSRBL.
For more information see: https://www.webiron.com/rbl.html
To check the blacklist status of the offending IP, see: https://www.webiron.com/iplookup/95.85.45.159
-- NEW -- We have now opened access to our RBL API allowing direct access to the entire RBL database. For more information please see:https://www.webiron.com/rbl.html
Thank you for your support,
The WebIron Team
---------------------------------------------------------- *** Note *** - All times are in America/Phoenix (-07:00) ----------------------------------------------------------
Unwanted and or Abusive Web Requests:
Offending/Source IP: 95.85.45.159 - Issue: Source has attempted the following botnet activity: Semalt Referrer Spam Tor Exit Bot - Block Type: New Ban - Time: 2016-10-04 00:33:54-07:00 - Port: 80 - Service: http - Report ID: ff681d81-5ce4-4329-8890-49642bd24a77 - Bot Fingerprint: d5930168c39511ee975f5943a5f3faac - Bot Information: https://www.webiron.com/bot_lookup/d5930168c39511ee975f5943a5f3faac - Bot Node Feed: https://www.webiron.com/bot_feed/d5930168c39511ee975f5943a5f3faac - Abused Range: 45.79.79.0/24 - Requested URI: / - User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
2016-10-04 18:46 GMT+02:00 Moritz Bartl <moritz@torservers.net>:
On 10/04/2016 06:23 PM, Tristan wrote:
Wouldn't it be interesting if we could set up some kind of central "Tor Abuse Center" where all the complaints go, and all the relay operators can help respond to them. I suppose it would be pretty chaotic though...
We actually discussed this briefly again at the recent Tor developers meeting, and it comes up every once in a while. It's an interesting thought experiment, and it would not take much to turn ourselves into an Abuse Management provider. I've seen this actually exists in the commercial space.
One thing that makes it hard is that there's no assurance that someone is really only running an exit on a certain IP address; even if the Abuse Management Service verified that that IP address was a Tor exit at that point in time, it cannot in all honesty state that in fact the exit relay process caused a particular network activity or not.
I do think we can operate this "in good faith", and we simply cannot set it up in a way that we can make it impossible to misuse.
Still, this will not help in this (and related) cases: I have not yet seen proven cases where the reputation of the netblock was endangered, but if an ISP is afraid of that, there's no good way to cooperate. An IDS is their obvious suggestion, which just shows that they don't understand how Tor works. I argue strongly against deploying such systems on Tor exits. It will mess up more than it does good, and it won't be able to reliably detect *and block* bad behaviour.
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ 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
_______________________________________________ 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"
Just for shits and giggles: Do you have a good, easy, workable solution to this complex problem? Markus 2016-10-04 22:19 GMT+02:00 <oconor@email.cz>:
And I'm not against you (tor admins/operators) ;)
I'm really glad that this discussion started, let's see, if we can find some solution.
Just 2 make 1 thing clear: Its not we against you (ISPs).
Working myself years ago at an ISP I know the trouble and I understand the issues.
Markus
Everything is easy when you hit the base of the problem and you're able to change it. I don't know what kind of community gathers here. Let's see where the discussion leads. Petr "Just for shits and giggles: Do you have a good, easy, workable solution to this complex problem? Markus 2016-10-04 22:19 GMT+02:00 <oconor@email.cz>:
And I'm not against you (tor admins/operators) ;)
I'm really glad that this discussion started, let's see, if we can find some solution.
Just 2 make 1 thing clear: Its not we against you (ISPs).
Working myself years ago at an ISP I know the trouble and I understand the issues.
Markus
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
What if someone who doesnt like Tor project is deliberately accessing honeypots in order to get exit nodes shut down? We need to establish some sort of legal or political solidarity to tell ISPs to be net neutral with us. It is not our problem if someone uses the telecom network to read/write data to a vulnerable server - it is the vulnerable server's problem to fix. The ISP (and Tor network) are only responsible for delivering the packets and handling abuse of *network* resources such as DDoS - content is irrelevant. Tor publishes exit node ip addresses so that destinations that dont want to deal with anonymous traffic can block it. Did you try these answers: https://trac.torproject.org/projects/tor/wiki/doc/TorAbuseTemplates On 04/10/16 12:01 PM, pa011 wrote:
Me too Markus -could fill a folder with that tax issue :-(( Costing a lot of time to answer and restrict the IPs
Plus my ISP moaning with good reason: "It's not just about you, but you're giving a bad reputation to one /21 and one /22 subnet. That's ~ 3000 IPs which are potentionaly endagered to be marked as source of malicious content / blacklisted / whatever ... so you see, this is quite critical for us."
Am 04.10.2016 um 18:24 schrieb krishna e bera:
What if someone who doesnt like Tor project is deliberately accessing honeypots in order to get exit nodes shut down?
That seems kind of easy, because there are some certain spots where you can assume those pots to be and depending on the response of the host of the honeypot more or less pressure on the ISP could arise
We need to establish some sort of legal or political solidarity to tell ISPs to be net neutral with us.
I still cant judge the pressure and burdens apart from economical on ISP side. In June I asked here those questions which still didn’t find an answer: - is it just the more work for rather poor money handling(forwarding) those abuses ? - to whom else does 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?
It is not our problem if someone uses the telecom network to read/write data to a vulnerable server - it is the vulnerable server's problem to fix. The ISP (and Tor network) are only responsible for delivering the packets and handling abuse of *network* resources such as DDoS - content is irrelevant.
Tor publishes exit node ip addresses so that destinations that dont want to deal with anonymous traffic can block it. Did you try these answers: https://trac.torproject.org/projects/tor/wiki/doc/TorAbuseTemplates
I only shortly began to send a copy of my response not only to the ISP, but also to the sender of the abuse - how do other people here handle this? Obviously the attacked target needs an other explanation as the ISP.
On 04/10/16 12:01 PM, pa011 wrote:
Me too Markus -could fill a folder with that tax issue :-(( Costing a lot of time to answer and restrict the IPs
Plus my ISP moaning with good reason: "It's not just about you, but you're giving a bad reputation to one /21 and one /22 subnet. That's ~ 3000 IPs which are potentionaly endagered to be marked as source of malicious content / blacklisted / whatever ... so you see, this is quite critical for us."
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
@keb:
It is not our problem if someone uses the telecom network to read/write data to a vulnerable server - it is the vulnerable server's problem to fix.
Sounds great, but this is not how it works in the real world.
The ISP (and Tor network) are only responsible for delivering the packets and handling abuse of *network* resources such as DDoS - content is irrelevant.
Again, not how it works, at least not in all parts of the world. In the US in particular, there is the Digital Millennium Copyright Act (DMCA), under which the ISP does have obligations regarding content.
I am receiving more and more trouble from running an exit node here. Perhaps we should refuse to support US legislation? On 10/04/2016 06:35 PM, Green Dream wrote:
@keb:
It is not our problem if someone uses the telecom network to read/write data to a vulnerable server - it is the vulnerable server's problem to fix.
Sounds great, but this is not how it works in the real world.
The ISP (and Tor network) are only responsible for delivering the packets and handling abuse of *network* resources such as DDoS - content is irrelevant.
Again, not how it works, at least not in all parts of the world. In the US in particular, there is the Digital Millennium Copyright Act (DMCA), under which the ISP does have obligations regarding content. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Alecks Gates
On Oct 4, 2016, at 7:48 AM, pa011 <pa011@web.de> wrote:
One of my main ISP is going mad with the number of abuses he gets from my Exits (currently most on port 80). He asks me to install "Intrusion Prevention System Software" or shutting down the servers. He personally recommends Snort or Suricata.
As far as I understand implementing such a software is not going together with Tor - am I right? Somebody having same or any experience?
Yes, no, and maybe. Yes, you can run IPS on a Tor relay, but you have to be very careful doing it, because a standard implementation of IPS would end up blocking Tor exits, which would obviously be problematic. You really need to exclude the (dynamic) Tor exit node list from IPS monitoring—which ends up not solving your problem…so, no, IPS won’t really help you. Maybe IPS would be a fantastic thing to integrate into Tor, because it would answer the primary overall objection to Tor, which is that it enables abusive internet behavior. We market the “attractive” uses of Tor—personal privacy, protecting dissidents & whistleblowers, gathering intelligence—but when abuse issues arise (brute force SSH attacks, DOS attacks, HTTP/PHP hacks, copyright infringements, etc. etc.), we shrug them off as “the cost of freedom” and cite statistics to justify the status quo. The end result is that major players—even in the free world—completely block access to/from Tor nodes. Abuse issues create a very strong public perception that Tor has a high cost vs. benefit. If we’re fine with the status quo, no problem. But if we want broader adoption/acceptance of Tor, we need to address the abuse issue somehow. The technical problem is that implementing IPS in Tor would be massively non-trivial. In order for IPS to function properly within Tor, while maintaining strict anonymity, a Tor node detecting an IPS trigger would have to pass the event back up the relay chain until the entry relay (the only node that “knows” the actual initiating host) was finally able to block the offending host/port. The political problem is, what gets blocked by TIPS and what doesn’t? Who gets to decide? What if some of those brute-force SSH or DOS attacks are “good guys” trying to crack the “bad guy” servers? Is that legitimate Tor traffic? Who gets to decide who are the good/bad guys? Could we agree on a base level of protection, perhaps by relay operator consensus? Etc. These problems are not insurmountable, but they are significant. Jon
On Tue, Oct 04, 2016 at 10:21:14AM -0500, BlinkTor wrote:
The technical problem is that implementing IPS in Tor would be massively non-trivial.[...]
The political problem is, what gets blocked by TIPS and what doesn???t? Who gets to decide? What if some of those brute-force SSH or DOS attacks are ???good guys??? trying to crack the ???bad guy??? servers? Is that legitimate Tor traffic? Who gets to decide who are the good/bad guys? Could we agree on a base level of protection, perhaps by relay operator consensus? Etc.
Another challenge here is that many lawyers have told us that you change your legal situation if you start choosing which traffic to allow through. Specifically, if you just pass bytes back and forth, you're essentially in the common carrier situation, like backbone telcos and backbone Internet providers. But if you make a list of topics or messages or patterns to block, then it becomes your responsibility to make that list perfect, and your fault if you leave something out of your list. So it would seem that using an IPS is fundamentally dangerous for relay operators. I've heard that this logic applies both in the US and in Europe. But it's been a while since we've had an actual lawyer look at the topic. Maybe this is a great question for each of the torservers.net umbrella orgs to ask their friendly nearby lawyers who are wanting to help them? There is also the separate but related question of wiretapping: blocking some traffic based on patterns in the request content implies looking at the traffic, which relay operators typically do not have permission to do. While ISPs typically make their customers sign an agreement that they will be surveilled (and I guess they ignore the concept of jurisdictions that require consent from both sides), Tor relay operators do not have that agreement -- and they can't really get it, because their 'users' are all the Tor users. In summary, I totally get why hosting providers would want to ask relay operators to monitor their traffic and block certain activities by examining connection payloads, and that's to make their lives easier, not for any legal requirement. But it would appear there are some legal reasons why Tor relay operators might (should?) hesitate to deploy an IPS on their traffic, and those legal reasons are probably not as well-understood as they could be. Do any of the torservers umbrella orgs want to pick this one up and do something with it? I remember hearing Pepijn cite a specific EU law that says European relay operators aren't liable for their traffic so long as they don't mess with it. One of the goals would be for relay operators to better understand the tradeoff they should consider when deciding whether to do the thing that their ISP asks for. Another goal would be for the ISP to better understand what they're asking from the relay operators. --Roger
Everyone is running a reduced exit policy ... I only allow HTTP + HTTPS and I know nobody who allows port 25 .... at the end of the day we all shape our exit traffic. Markus 2016-10-04 21:42 GMT+02:00 Roger Dingledine <arma@mit.edu>:
On Tue, Oct 04, 2016 at 10:21:14AM -0500, BlinkTor wrote:
The technical problem is that implementing IPS in Tor would be massively non-trivial.[...]
The political problem is, what gets blocked by TIPS and what doesn???t? Who gets to decide? What if some of those brute-force SSH or DOS attacks are ???good guys??? trying to crack the ???bad guy??? servers? Is that legitimate Tor traffic? Who gets to decide who are the good/bad guys? Could we agree on a base level of protection, perhaps by relay operator consensus? Etc.
Another challenge here is that many lawyers have told us that you change your legal situation if you start choosing which traffic to allow through. Specifically, if you just pass bytes back and forth, you're essentially in the common carrier situation, like backbone telcos and backbone Internet providers. But if you make a list of topics or messages or patterns to block, then it becomes your responsibility to make that list perfect, and your fault if you leave something out of your list.
So it would seem that using an IPS is fundamentally dangerous for relay operators.
I've heard that this logic applies both in the US and in Europe. But it's been a while since we've had an actual lawyer look at the topic. Maybe this is a great question for each of the torservers.net umbrella orgs to ask their friendly nearby lawyers who are wanting to help them?
There is also the separate but related question of wiretapping: blocking some traffic based on patterns in the request content implies looking at the traffic, which relay operators typically do not have permission to do. While ISPs typically make their customers sign an agreement that they will be surveilled (and I guess they ignore the concept of jurisdictions that require consent from both sides), Tor relay operators do not have that agreement -- and they can't really get it, because their 'users' are all the Tor users.
In summary, I totally get why hosting providers would want to ask relay operators to monitor their traffic and block certain activities by examining connection payloads, and that's to make their lives easier, not for any legal requirement. But it would appear there are some legal reasons why Tor relay operators might (should?) hesitate to deploy an IPS on their traffic, and those legal reasons are probably not as well-understood as they could be.
Do any of the torservers umbrella orgs want to pick this one up and do something with it? I remember hearing Pepijn cite a specific EU law that says European relay operators aren't liable for their traffic so long as they don't mess with it.
One of the goals would be for relay operators to better understand the tradeoff they should consider when deciding whether to do the thing that their ISP asks for. Another goal would be for the ISP to better understand what they're asking from the relay operators.
--Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, Oct 04, 2016 at 09:55:01PM +0200, Markus Koch wrote:
Everyone is running a reduced exit policy ... I only allow HTTP + HTTPS and I know nobody who allows port 25 .... at the end of the day we all shape our exit traffic.
Choosing what to do with your traffic based on headers is fundamentally different, legally, than choosing what to do with it based on payload. In the US, it's the difference between the "pen register" category and the "wiretap" category. I imagine there are similar terms in many other countries. In the telephone metaphor (which is what many of these laws are fundamentally based on), it's the difference between "I won't let you call Germany" and "when you call Germany, I'll cut the connection if you start talking about surveillance". You'll notice that all of the Tor mechanisms for limiting abuse work on the header level, not the payload level. --Roger
Thank you very much, interesting. So I could block URLs but not on deep packet inspection? Markus 2016-10-04 22:04 GMT+02:00 Roger Dingledine <arma@mit.edu>:
On Tue, Oct 04, 2016 at 09:55:01PM +0200, Markus Koch wrote:
Everyone is running a reduced exit policy ... I only allow HTTP + HTTPS and I know nobody who allows port 25 .... at the end of the day we all shape our exit traffic.
Choosing what to do with your traffic based on headers is fundamentally different, legally, than choosing what to do with it based on payload.
In the US, it's the difference between the "pen register" category and the "wiretap" category. I imagine there are similar terms in many other countries.
In the telephone metaphor (which is what many of these laws are fundamentally based on), it's the difference between "I won't let you call Germany" and "when you call Germany, I'll cut the connection if you start talking about surveillance".
You'll notice that all of the Tor mechanisms for limiting abuse work on the header level, not the payload level.
--Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, Oct 04, 2016 at 10:08:25PM +0200, Markus Koch wrote:
Thank you very much, interesting. So I could block URLs but not on deep packet inspection?
That's where it starts to get murky: where do headers end and contents begin? It depends what protocol layer you're looking at. Law-makers spend a lot of time debating exactly that question. In Tor's world, since Tor transports TCP streams, we think the headers are what the TCP layer thinks of as headers, e.g. destination IP and destination port. And the URL is way down in the payload. (After all, what business is it of Tor's whether that stream you send over port 80 is http or is something else?) --Roger
Okay, I am getting confused. (OSI model here) ATM we are traffic shaping/blocking at layer 3 DNS is layer 7. destination IP and port should be layer 1-4, right? Markus 2016-10-04 22:18 GMT+02:00 Roger Dingledine <arma@mit.edu>:
On Tue, Oct 04, 2016 at 10:08:25PM +0200, Markus Koch wrote:
Thank you very much, interesting. So I could block URLs but not on deep packet inspection?
That's where it starts to get murky: where do headers end and contents begin? It depends what protocol layer you're looking at. Law-makers spend a lot of time debating exactly that question.
In Tor's world, since Tor transports TCP streams, we think the headers are what the TCP layer thinks of as headers, e.g. destination IP and destination port. And the URL is way down in the payload. (After all, what business is it of Tor's whether that stream you send over port 80 is http or is something else?)
--Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
This is really interesting. I just don't understand, how you can be responsible for the traffic, when you use the IPS. Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic. Can you be more specific about some real case, when this was used against someone? Tomorrow I'm going to ask a lawyer (europe - Czech rep). Petr "On Tue, Oct 04, 2016 at 10:21:14AM -0500, BlinkTor wrote:
The technical problem is that implementing IPS in Tor would be massively non-trivial.[...]
The political problem is, what gets blocked by TIPS and what doesn???t? Who gets to decide? What if some of those brute-force SSH or DOS attacks are ???good guys??? trying to crack the ???bad guy??? servers? Is that legitimate Tor traffic? Who gets to decide who are the good/bad guys? Could we agree on a base level of protection, perhaps by relay operator consensus? Etc.
Another challenge here is that many lawyers have told us that you change your legal situation if you start choosing which traffic to allow through. Specifically, if you just pass bytes back and forth, you're essentially in the common carrier situation, like backbone telcos and backbone Internet providers. But if you make a list of topics or messages or patterns to block, then it becomes your responsibility to make that list perfect, and your fault if you leave something out of your list. So it would seem that using an IPS is fundamentally dangerous for relay operators. I've heard that this logic applies both in the US and in Europe. But it's been a while since we've had an actual lawyer look at the topic. Maybe this is a great question for each of the torservers.net umbrella orgs to ask their friendly nearby lawyers who are wanting to help them? There is also the separate but related question of wiretapping: blocking some traffic based on patterns in the request content implies looking at the traffic, which relay operators typically do not have permission to do. While ISPs typically make their customers sign an agreement that they will be surveilled (and I guess they ignore the concept of jurisdictions that require consent from both sides), Tor relay operators do not have that agreement -- and they can't really get it, because their 'users' are all the Tor users. In summary, I totally get why hosting providers would want to ask relay operators to monitor their traffic and block certain activities by examining connection payloads, and that's to make their lives easier, not for any legal requirement. But it would appear there are some legal reasons why Tor relay operators might (should?) hesitate to deploy an IPS on their traffic, and those legal reasons are probably not as well-understood as they could be. Do any of the torservers umbrella orgs want to pick this one up and do something with it? I remember hearing Pepijn cite a specific EU law that says European relay operators aren't liable for their traffic so long as they don't mess with it. One of the goals would be for relay operators to better understand the tradeoff they should consider when deciding whether to do the thing that their ISP asks for. Another goal would be for the ISP to better understand what they're asking from the relay operators. --Roger _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
On 04.10.16 22:37, oconor@email.cz wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to colloquially as the "provider privilege". One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means. According to two lawyers I spoke to, exit policies might already be borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data? That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad". -Ralph
If I understand that well ... if tor operator is avare, that his tor node is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity? "On 04.10.16 22:37, oconor@email.cz wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to colloquially as the "provider privilege". One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means. According to two lawyers I spoke to, exit policies might already be borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data? That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad". -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
What should a tor exit op do? Ban the user? exits get the traffic from middle nodes and we cant tell (by design) who anyone is. We can block ips but that is not really helping with bots who tries to find vulnerabilities and scan large blocks. markus Sent from my iPad
On 4 Oct 2016, at 23:55, <oconor@email.cz> <oconor@email.cz> wrote:
If I understand that well ... if tor operator is avare, that his tor node is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity?
On 04.10.16 22:37, oconor@email.cz wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to colloquially as the "provider privilege".
One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means.
According to two lawyers I spoke to, exit policies might already be borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data?
That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad".
-Ralph _______________________________________________ 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
We're back to IPS, which can drop the specific malicious traffic. I've been speaking with the lawyer few minutes ago. He told me that there is a pressure to put all the responsibility for the traffic to the ISPs. Well ... what are the ISPs most probably going to do ... ? They can ban all tor exit nodes, or they will force the owners to clear the traffic. When you're worried about being accused, why you don't use fake information during registration and payments with bitcoins? Then you can also filter the traffic by IPS ... and everybory will be happy. " What should a tor exit op do? Ban the user? exits get the traffic from middle nodes and we cant tell (by design) who anyone is. We can block ips but that is not really helping with bots who tries to find vulnerabilities and scan large blocks. markus Sent from my iPad On 4 Oct 2016, at 23:55, <oconor@email.cz(mailto:oconor@email.cz)> <oconor@ email.cz(mailto:oconor@email.cz)> wrote: " If I understand that well ... if tor operator is avare, that his tor node is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity? "On 04.10.16 22:37, oconor@email.cz(mailto:oconor@email.cz) wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html (http://www.gesetze-im-internet.de/tmg/__8.html) -- sometimes referred to colloquially as the "provider privilege". One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means. According to two lawyers I spoke to, exit policies might already be borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data? That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad". -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org(mailto:tor-relays@lists.torproject.org) https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays (https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays)"= "" _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org(mailto:tor-relays@lists.torproject.org) https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays (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 5 Oct 2016, at 18:10, <oconor@email.cz> <oconor@email.cz> wrote:
We're back to IPS, which can drop the specific malicious traffic. I've been speaking with the lawyer few minutes ago. He told me that there is a pressure to put all the responsibility for the traffic to the ISPs. Well ... what are the ISPs most probably going to do ... ? They can ban all tor exit nodes, or they will force the owners to clear the traffic.
When you're worried about being accused, why you don't use fake information during registration and payments with bitcoins? Then you can also filter the traffic by IPS ... and everybory will be happy.
There are a few things wrong with your suggested solution: * it's really, really hard to stay anonymous on the Internet as an individual, and impossible for many corporations (it's hard to be transparent about how you spend money as a charity, and be anonymous at the same time), * if all Tor Exit Nodes are anonymous, ISPs may block them more, not less, * filtering will likely get your Exit marked as a BadExit, * IPS aren't perfect - they let some unwanted traffic through, and block other traffic that is totally ok. Tim
What should a tor exit op do? Ban the user? exits get the traffic from middle nodes and we cant tell (by design) who anyone is. We can block ips but that is not really helping with bots who tries to find vulnerabilities and scan large blocks.
markus
Sent from my iPad
On 4 Oct 2016, at 23:55, <oconor@email.cz> <oconor@email.cz> wrote:
If I understand that well ... if tor operator is avare, that his tor node is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity?
On 04.10.16 22:37, oconor@email.cz wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to colloquially as the "provider privilege".
One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means.
According to two lawyers I spoke to, exit policies might already be borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data?
That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad".
-Ralph _______________________________________________ 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 _______________________________________________ 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
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
On 10/05/2016 01:27 AM, teor wrote:
On 5 Oct 2016, at 18:10, <oconor@email.cz> <oconor@email.cz> wrote:
We're back to IPS, which can drop the specific malicious traffic. I've been speaking with the lawyer few minutes ago. He told me that there is a pressure to put all the responsibility for the traffic to the ISPs. Well ... what are the ISPs most probably going to do ... ? They can ban all tor exit nodes, or they will force the owners to clear the traffic.
When you're worried about being accused, why you don't use fake information during registration and payments with bitcoins? Then you can also filter the traffic by IPS ... and everybory will be happy.
There are a few things wrong with your suggested solution: * it's really, really hard to stay anonymous on the Internet as an individual, and impossible for many corporations (it's hard to be transparent about how you spend money as a charity, and be anonymous at the same time),
Truth.
* if all Tor Exit Nodes are anonymous, ISPs may block them more, not less,
Yes. But at least there's less risk to exit operators.
* filtering will likely get your Exit marked as a BadExit,
Yes, I get that. What happens if it's the hosting provider or their ISP that does the filtering? With end-to-end encryption, of course, it's less effective. But there are some pretty decent protocol detectors.
* IPS aren't perfect - they let some unwanted traffic through, and block other traffic that is totally ok.
That is an issue. But there are many exits, so eventually users should find one that works well enough for their purposes.
Tim
What should a tor exit op do? Ban the user? exits get the traffic from middle nodes and we cant tell (by design) who anyone is. We can block ips but that is not really helping with bots who tries to find vulnerabilities and scan large blocks.
markus
Sent from my iPad
On 4 Oct 2016, at 23:55, <oconor@email.cz> <oconor@email.cz> wrote:
If I understand that well ... if tor operator is avare, that his tor node is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity?
On 04.10.16 22:37, oconor@email.cz wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to colloquially as the "provider privilege".
One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means.
According to two lawyers I spoke to, exit policies might already be borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data?
That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad".
-Ralph _______________________________________________ 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 _______________________________________________ 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
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
@Mirimir:
IPS aren't perfect - they let some unwanted traffic through, and block other traffic that is totally ok.
That is an issue. But there are many exits, so eventually users should find one that works well enough for their purposes.
Re-read what you said and think about this from the user's perspective. This is a recipe for disaster when it comes to Tor user experience. Perhaps it seems suitable to you, as a technical person and a relay operator, but just think about this problem for a barely technical user, or someone new to Tor. What will actually happen is people will try Tor, hit a shitty exit with random performance problems from an IPS, log off and never use Tor again. Tor needs all the help it can get with regards to usability and reliability. It's gotten better over the years but I still get circuits that are borderline unusable. Adding a hodgepodge of blocking IPS systems into the mix isn't going to help this problem. No offense to the ISP here (I do think they are within their rights to take this position), but I think relay/exit operators should find ISPs that understand Tor and don't demand an IPS.
These are getting rare. It is much easier to get a seedbox than a tor exit. I had even bulletproof ISPs who dont want to host exits. Believe me, I was chatting /mailing ISPs for days and its a mess. Markus PS: Tor changed years ago the exit policy and since then Tor is not anymore one big torrent. But we cant do this with bots? Because bots have rights?
No offense to the ISP here (I do think they are within their rights to take this position), but I think relay/exit operators should find ISPs that understand Tor and don't demand an IPS. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Be that as it may, there must be *something* we can do about this as relay operators. If you get caught doing something illegal on your home Internet connection, there are warnings, and eventually consequences (like being disconnected). Just because you run a Tor relay doesn't mean the rules don't apply to you, and if we can't do anything to stop illegal activity, eventually relays are going to be disconnected. I understand both sides of the argument, and why no solution would be perfect, but we need to figure something out. This problem will not go away on its own, and I expect it to only get worse as time goes on. Personally, I don't like the idea of filtering traffic at the exit node, because it seems to undermine the whole purpose of Tor: unrestricted anonymous access. However, there must be some way to identify at least some malicious traffic, such as bots. If Tor relays start filtering traffic, I think it should be opt-in, and it should happen at the guard relay. That way not all relays filter by default, and if something gets blocked, it happens *before* it gets routed through the network. Of course, we could always identify what constitutes as filtering. As already stated, each exit relay has its own exit policy, so technically everyone already filters traffic based on port. If an IPS only logs non-identifiable information, I don't think it would compromise anonymity, but at the same time, people may not trust Tor if it starts scanning traffic. On Wed, Oct 5, 2016 at 1:58 PM, Green Dream <greendream848@gmail.com> wrote:
@Mirimir:
IPS aren't perfect - they let some unwanted traffic through, and block other traffic that is totally ok.
That is an issue. But there are many exits, so eventually users should find one that works well enough for their purposes.
Re-read what you said and think about this from the user's perspective. This is a recipe for disaster when it comes to Tor user experience. Perhaps it seems suitable to you, as a technical person and a relay operator, but just think about this problem for a barely technical user, or someone new to Tor. What will actually happen is people will try Tor, hit a shitty exit with random performance problems from an IPS, log off and never use Tor again.
Tor needs all the help it can get with regards to usability and reliability. It's gotten better over the years but I still get circuits that are borderline unusable. Adding a hodgepodge of blocking IPS systems into the mix isn't going to help this problem.
No offense to the ISP here (I do think they are within their rights to take this position), but I think relay/exit operators should find ISPs that understand Tor and don't demand an IPS. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
@Tristan:
there must be something we can do about this as relay operators.
No, we don't need to do anything. Tor has been running under these principles of uncensored access for a long time. Find an ISP that understands Tor, appreciates the nature of the service and its value, and is willing to work with you in a reasonable manner on abuse complaints. It's that simple.
If you get caught doing something illegal on your home Internet connection, there are warnings, and eventually consequences (like being disconnected). Just because you run a Tor relay doesn't mean the rules don't apply to you, and if we can't do anything to stop illegal activity, eventually relays are going to be disconnected.
Apples and oranges; the logic doesn't work for me. The rules (laws) *are* different for relay operators. See Roger's earlier comments in this thread. Relay operators are closer to common carrier / ISP laws, in that there is some degree of legal immunity if you're just passing bits. This is why an ISP in the United States isn't liable for illegal activity from a customer (broadly speaking, IANAL, etc). Yes we need to be responsive to abuse complaints, but no, we don't have to implement IPS systems or proactively block traffic just to appease an ISP who gets stressed out by automated abuse complaints.
No, we don't need to do anything. Tor has been running under these principles of uncensored access for a long time. Find an ISP that understands Tor, appreciates the nature of the service and its value, and is willing to work with you in a reasonable manner on abuse complaints. It's that simple.
You are ignoring completely reality, aren't you?
No, you are not. Its not that simple as "just find a ISP" The Tor network is made up of volunteers, so you need a: 1. ISP with more than laughable traffic limits 2. Tor friendly 3. Cheap 4. and with traffic connections that the Tor network likes Thats not easy. OVH (the biggest in Tor) is pissed off, Online.net does kick exits faster than you can "freedom of speech" , Hetzner hosts you and will bet on your first police raid.Its a complete mess. Do not tell me about the good/bad isp wiki. these are old data and I personally burned 2 ISPs there because of abuse mails. Btw, my only open ports were/are http and https... 2016-10-05 23:35 GMT+02:00 Green Dream <greendream848@gmail.com>:
You are ignoring completely reality, aren't you?
No, I'm describing the status quo, how Tor already operates. "Don't run IPS/Snort on exits" has been a long standing response from the Tor folks. It looks to me like that response is essentially unchanged. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
@Markus Okay, so you are offended by the phrase "it's that simple". Sorry, if I could remove that sentence I would. I didn't mean to imply that running an exit was trivial or easy. Otherwise, I stand by my argument -- automated filtering or blocking is not the right answer. The co-founder of Tor already said as much in this thread: "it would seem that using an IPS is fundamentally dangerous for relay operators".
Then what _can_ we do? Because as it stands, Tor is the perfect tool for criminals, and your stand is "do nothing." An ISP can trace illegal activity to a user, we can't. Even if Tor is considered an ISP in that sense, the rules vary by country, maybe even by provider. I'm being to think there is no real solution to the problem. As long as Tor serves its purpose of providing uncensored access to the Internet, bad guys will always abuse it, and the operators will almost always be at odds with their ISP. Anything we try to do to block abuse will destroy the very concept of Tor. On Oct 5, 2016 4:51 PM, "Green Dream" <greendream848@gmail.com> wrote:
@Markus
Okay, so you are offended by the phrase "it's that simple". Sorry, if I could remove that sentence I would. I didn't mean to imply that running an exit was trivial or easy.
Otherwise, I stand by my argument -- automated filtering or blocking is not the right answer. The co-founder of Tor already said as much in this thread: "it would seem that using an IPS is fundamentally dangerous for relay operators". _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I'm being to think there is no real solution to the problem. As long as Tor serves its purpose of providing uncensored access to the Internet, bad guys will always abuse it, and the operators will almost always be at odds with their ISP. Anything we try to do to block abuse will destroy the very concept of Tor.
Ding ding ding. You're getting it now. :-) Criminals using Tor is not a new problem. It's addressed as the first question in the Abuse FAQ, here: https://www.torproject.org/docs/faq-abuse.html.en#WhatAboutCriminals and it's discussed by the EFF here: https://www.eff.org/deeplinks/2014/07/7-things-you-should-know-about-tor There are a lot of smart people who have been talking about this for a long time. I won't list more sources but they are easy to find.
Well, this sentence from the EFF gives me some peace of mind: "You are not helping criminals by using Tor any more than you are helping criminals by using the Internet." I still wish there was a better way to handle things, but at this point I'm just begging the question. On Wed, Oct 5, 2016 at 5:20 PM, Green Dream <greendream848@gmail.com> wrote:
I'm being to think there is no real solution to the problem. As long as Tor serves its purpose of providing uncensored access to the Internet, bad guys will always abuse it, and the operators will almost always be at odds with their ISP. Anything we try to do to block abuse will destroy the very concept of Tor.
Ding ding ding. You're getting it now. :-)
Criminals using Tor is not a new problem. It's addressed as the first question in the Abuse FAQ, here:
https://www.torproject.org/docs/faq-abuse.html.en#WhatAboutCriminals
and it's discussed by the EFF here:
https://www.eff.org/deeplinks/2014/07/7-things-you-should-know-about-tor
There are a lot of smart people who have been talking about this for a long time. I won't list more sources but they are easy to find. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
On 05/10/16 06:20 PM, Green Dream wrote:
Criminals using Tor is not a new problem. It's addressed as the first question in the Abuse FAQ, here: https://www.torproject.org/docs/faq-abuse.html.en#WhatAboutCriminals
and it's discussed by the EFF here: https://www.eff.org/deeplinks/2014/07/7-things-you-should-know-about-tor
Exactly, but criminals/dissidents/spies/researchers a.k.a. arguably legal content, is only half the issue. The other half is something that maybe Tor people can and should do something about (carefully of course) when we can detect it, namely disruption of the network. This means things like - floods - DDoS - active timing attacks - messing with DNS - re-routing Since these are mostly also problems for ISPs, there may be room for cooperation. One sample question is, if we didnt have to rely only on the information from Tor nodes, could we do better at automatically dealing with certain problems?
On 05.10.16 23:18, Green Dream wrote:
Yes we need to be responsive to abuse complaints, but no, we don't have to implement IPS systems or proactively block traffic just to appease an ISP who gets stressed out by automated abuse complaints.
That. Blocking traffic should be a last resort, and not done reflexively on a Tor exit because some random person who can very well do his own blocking is complaining. Like I said in another list message, I don't like the idea of automatic censorship. -Ralph
You still propably don't see that it consumes a lot of time to deal even with automaticly generated messages. During last years all network attacks graduates, if you're not going to solve that, every wise ISP is going to refuse to host you. ---------- Původní zpráva ---------- Od: Green Dream <greendream848@gmail.com> Komu: tor-relays@lists.torproject.org Datum: 5. 10. 2016 23:18:55 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata "@Tristan:
there must be something we can do about this as relay
operators.
No, we don't need to do anything. Tor has been running under these principles of uncensored access for a long time. Find an ISP that understands Tor, appreciates the nature of the service and its value, and is willing to work with you in a reasonable manner on abuse complaints. It's that simple.
If you get caught doing something illegal on your home Internet
connection, there are warnings, and eventually consequences (like being
disconnected). Just because you run a Tor relay doesn't mean the rules don't
apply to you, and if we can't do anything to stop illegal activity,
eventually relays are going to be disconnected.
Apples and oranges; the logic doesn't work for me. The rules (laws) *are* different for relay operators. See Roger's earlier comments in this thread. Relay operators are closer to common carrier / ISP laws, in that there is some degree of legal immunity if you're just passing bits. This is why an ISP in the United States isn't liable for illegal activity from a customer (broadly speaking, IANAL, etc). Yes we need to be responsive to abuse complaints, but no, we don't have to implement IPS systems or proactively block traffic just to appease an ISP who gets stressed out by automated abuse complaints. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
On 10/05/2016 12:58 PM, Green Dream wrote:
@Mirimir:
IPS aren't perfect - they let some unwanted traffic through, and block other traffic that is totally ok.
That is an issue. But there are many exits, so eventually users should find one that works well enough for their purposes.
Re-read what you said and think about this from the user's perspective. This is a recipe for disaster when it comes to Tor user experience. Perhaps it seems suitable to you, as a technical person and a relay operator, but just think about this problem for a barely technical user, or someone new to Tor. What will actually happen is people will try Tor, hit a shitty exit with random performance problems from an IPS, log off and never use Tor again.
True. But increased risk of hitting bad exits is arguably better than having fewer exits.
Tor needs all the help it can get with regards to usability and reliability. It's gotten better over the years but I still get circuits that are borderline unusable. Adding a hodgepodge of blocking IPS systems into the mix isn't going to help this problem.
Yes, I do too. And I wouldn't be happy if poorly implemented IPS made exits unpredictably unreliable. On the other hand, IPS that only blocked automated crap would be a win for real users, relay operators and ISPs, no? Why should "... ssh foo@w.x.y.z ... ssh bar@w.x.y.z ... ssh baz@w.x.y.z ..." get through, if it destroys exits? Maybe someone could forget their username. But maybe after 10-20 tries, can't we safely assume that they're brute forcing logins?
No offense to the ISP here (I do think they are within their rights to take this position), but I think relay/exit operators should find ISPs that understand Tor and don't demand an IPS. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Wed, 05 Oct 2016 13:48:19 +0000, Mirimir wrote: ...
exits unpredictably unreliable. On the other hand, IPS that only blocked automated crap would be a win for real users, relay operators and ISPs, no? Why should "... ssh foo@w.x.y.z ... ssh bar@w.x.y.z ... ssh baz@w.x.y.z ..." get through, if it destroys exits? Maybe someone could forget their username. But maybe after 10-20 tries, can't we safely assume that they're brute forcing logins?
No. for i in subdir/*; do ssh host mkdir -p "$i"; done with an ssh-agent would look pretty exactly the same to the exit node. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On 10/05/2016 02:39 PM, Andreas Krey wrote:
On Wed, 05 Oct 2016 13:48:19 +0000, Mirimir wrote: ...
exits unpredictably unreliable. On the other hand, IPS that only blocked automated crap would be a win for real users, relay operators and ISPs, no? Why should "... ssh foo@w.x.y.z ... ssh bar@w.x.y.z ... ssh baz@w.x.y.z ..." get through, if it destroys exits? Maybe someone could forget their username. But maybe after 10-20 tries, can't we safely assume that they're brute forcing logins?
No.
for i in subdir/*; do ssh host mkdir -p "$i"; done
with an ssh-agent would look pretty exactly the same to the exit node.
OK, so I left out the "Permission denied, please try again." bits :)
Andreas
On Wed, 05 Oct 2016 14:52:53 +0000, Mirimir wrote: ...
no? Why should "... ssh foo@w.x.y.z ... ssh bar@w.x.y.z ... ssh baz@w.x.y.z ..." get through, if it destroys exits? Maybe someone could ... for i in subdir/*; do ssh host mkdir -p "$i"; done
with an ssh-agent would look pretty exactly the same to the exit node.
OK, so I left out the "Permission denied, please try again." bits :)
The exit node doesn't see that - that's the point of ssh. It can at best look at the session length and timing and infer flakily from that. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
for i in subdir/*; do ssh host mkdir -p "$i"; done
with an ssh-agent would look pretty exactly the same to the exit node.
OK, so I left out the "Permission denied, please try again." bits :)
The exit node doesn't see that - that's the point of ssh. It can at best look at the session length and timing and infer flakily from that.
Exactly. There isn't a 100% effective way to accurately filter out "bad ssh" on the wire. It's a good example of where intrusion prevention systems fail. I worked at a public university where Bro (https://www.bro.org/) was in use. One of the enabled rules was for ssh brute-force / failed-login. It was mostly false positives. Bro was flagging legitimate ssh traffic. Turns out Bro is notorious for this (ref: http://mailman.icsi.berkeley.edu/pipermail/bro/2013-September/006026.html and many other similar posts). I've also worked with Snort and Cisco and Palo Alto IPS/IDS systems, and I've come to hate all of them for a couple of reasons: 1) The rulesets are finicky, always in flux, highly variant between vendors, and wildly inaccurate. 2) At the end of the day they are just tools for censorship. The way these systems work: the admin is presented with an assortment of rulesets, usually broadly categorized, and you just go through and start checking off boxes with labels like "adult content", "violence", "hacking", "tor", or if you're using an open source variant it may be a bit more refined like "ssh brute force", "syn flood", "tcp scan", etc. At the end of the day though someone is just checking off boxes. The underlying regex applied to packets may or may not have even been looked at. Multiply that chaos by the number of Tor exit operators who might implement such a thing. Think about the different experience levels of operators too; how many would know that the Bro rule for ssh was mostly going to block legitimate ssh traffic? We have technical and highly qualified Exit operators who could install an IPS, sure. But we have others fairly new to being sysadmins. One other huge problem -- where there's IPS there are IPS logs. Every IPS tool I know of has an option to log, and they're all going to log by default. That's bad. I'd vote BadExit flag (if I had a vote, ha). There's too much metadata that this would leave behind, and it may open up the operator to legal liabilities.
Or you simply block port 22 and everyone everyone lived happily ever after. I do not care about a script kiddie trying to hack something. Bots are what I am afraid of, you get the same abuse over and over and over. Markus 2016-10-06 6:43 GMT+02:00 Green Dream <greendream848@gmail.com>:
for i in subdir/*; do ssh host mkdir -p "$i"; done
with an ssh-agent would look pretty exactly the same to the exit node.
OK, so I left out the "Permission denied, please try again." bits :)
The exit node doesn't see that - that's the point of ssh. It can at best look at the session length and timing and infer flakily from that.
Exactly. There isn't a 100% effective way to accurately filter out "bad ssh" on the wire. It's a good example of where intrusion prevention systems fail.
I worked at a public university where Bro (https://www.bro.org/) was in use. One of the enabled rules was for ssh brute-force / failed-login. It was mostly false positives. Bro was flagging legitimate ssh traffic. Turns out Bro is notorious for this (ref: http://mailman.icsi.berkeley.edu/pipermail/bro/2013-September/006026.html and many other similar posts).
I've also worked with Snort and Cisco and Palo Alto IPS/IDS systems, and I've come to hate all of them for a couple of reasons:
1) The rulesets are finicky, always in flux, highly variant between vendors, and wildly inaccurate.
2) At the end of the day they are just tools for censorship.
The way these systems work: the admin is presented with an assortment of rulesets, usually broadly categorized, and you just go through and start checking off boxes with labels like "adult content", "violence", "hacking", "tor", or if you're using an open source variant it may be a bit more refined like "ssh brute force", "syn flood", "tcp scan", etc.
At the end of the day though someone is just checking off boxes. The underlying regex applied to packets may or may not have even been looked at.
Multiply that chaos by the number of Tor exit operators who might implement such a thing. Think about the different experience levels of operators too; how many would know that the Bro rule for ssh was mostly going to block legitimate ssh traffic?
We have technical and highly qualified Exit operators who could install an IPS, sure. But we have others fairly new to being sysadmins.
One other huge problem -- where there's IPS there are IPS logs. Every IPS tool I know of has an option to log, and they're all going to log by default. That's bad. I'd vote BadExit flag (if I had a vote, ha). There's too much metadata that this would leave behind, and it may open up the operator to legal liabilities. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 10/05/2016 10:43 PM, Green Dream wrote:
for i in subdir/*; do ssh host mkdir -p "$i"; done
with an ssh-agent would look pretty exactly the same to the exit node.
OK, so I left out the "Permission denied, please try again." bits :)
The exit node doesn't see that - that's the point of ssh. It can at best look at the session length and timing and infer flakily from that.
Oh :(
Exactly. There isn't a 100% effective way to accurately filter out "bad ssh" on the wire. It's a good example of where intrusion prevention systems fail.
I worked at a public university where Bro (https://www.bro.org/) was in use. One of the enabled rules was for ssh brute-force / failed-login. It was mostly false positives. Bro was flagging legitimate ssh traffic. Turns out Bro is notorious for this (ref: http://mailman.icsi.berkeley.edu/pipermail/bro/2013-September/006026.html and many other similar posts).
Actually, that thread concerns Bro notifications that are, in the context of this discussion, false negatives. That is, OP was concerned about a successful SSH login reported by Bro. And the tentative conclusion was: | Right, if the ssh connection's response bytes are above this | threshold it'll log the session as having a successful login. If | you have a large pre-auth login banner (usually for compliance | reasons) it will very likely report as a false positive. So maybe Bro can be tuned to flag failed logins reliably. Also, a few failed logins doesn't matter. It's rapid-fire failed logins from the same IP that need to be blocked. More generally, it seems doable to block all sorts of automated activity in ways that don't impact Tor project's target userbase. If someone wants to scrape stuff, they can bloody well learn how to do it in ways that don't burn down exit relays.
I've also worked with Snort and Cisco and Palo Alto IPS/IDS systems, and I've come to hate all of them for a couple of reasons:
1) The rulesets are finicky, always in flux, highly variant between vendors, and wildly inaccurate.
2) At the end of the day they are just tools for censorship.
Some of the rules are censorship, certainly. But I can't imagine how it's censorship to block SSH brute force attacks.
The way these systems work: the admin is presented with an assortment of rulesets, usually broadly categorized, and you just go through and start checking off boxes with labels like "adult content", "violence", "hacking", "tor", or if you're using an open source variant it may be a bit more refined like "ssh brute force", "syn flood", "tcp scan", etc.
At the end of the day though someone is just checking off boxes. The underlying regex applied to packets may or may not have even been looked at.
Multiply that chaos by the number of Tor exit operators who might implement such a thing. Think about the different experience levels of operators too; how many would know that the Bro rule for ssh was mostly going to block legitimate ssh traffic?
We have technical and highly qualified Exit operators who could install an IPS, sure. But we have others fairly new to being sysadmins.
One other huge problem -- where there's IPS there are IPS logs. Every IPS tool I know of has an option to log, and they're all going to log by default. That's bad. I'd vote BadExit flag (if I had a vote, ha). There's too much metadata that this would leave behind, and it may open up the operator to legal liabilities. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Let me ask you a short question. Have you ever worked with IPS? ---------- Původní zpráva ---------- Od: Green Dream <greendream848@gmail.com> Komu: tor-relays@lists.torproject.org Datum: 5. 10. 2016 20:58:36 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata "@Mirimir:
IPS aren't perfect - they let some unwanted traffic through, and
block other traffic that is totally ok.
That is an issue. But there are many exits, so eventually users should
find one that works well enough for their purposes.
Re-read what you said and think about this from the user's perspective. This is a recipe for disaster when it comes to Tor user experience. Perhaps it seems suitable to you, as a technical person and a relay operator, but just think about this problem for a barely technical user, or someone new to Tor. What will actually happen is people will try Tor, hit a shitty exit with random performance problems from an IPS, log off and never use Tor again. Tor needs all the help it can get with regards to usability and reliability. It's gotten better over the years but I still get circuits that are borderline unusable. Adding a hodgepodge of blocking IPS systems into the mix isn't going to help this problem. No offense to the ISP here (I do think they are within their rights to take this position), but I think relay/exit operators should find ISPs that understand Tor and don't demand an IPS. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
@oconor:
Let me ask you a short question. Have you ever worked with IPS?
Yes. Please see my later email in this thread. I have experience with Snort, Bro and proprietary IPS/IDS systems from Cisco and Palo Alto. I also worked at a university's network operations helpdesk, where we received hundreds of DCMA and abuse requests every week. I'm entirely aware of the work required. I understand fully you have a job to do, and I'm not immune to your or other provider concerns. I just don't think IPS is the right solution for Tor exits. If we're going to change anything I think it needs to happen within Tor software. Operators could leverage the existing "Exitpolicy reject" rules, or Tor could add functionality there if it's missing. Whatever we do, I think it needs to be uniform and transparent.
On 7 Oct 2016, at 05:07, Green Dream <greendream848@gmail.com> wrote:
If we're going to change anything I think it needs to happen within Tor software. Operators could leverage the existing "Exitpolicy reject" rules, or Tor could add functionality there if it's missing. Whatever we do, I think it needs to be uniform and transparent.
I had a conversation with someone at the recent tor meeting about rate-limiting Tor traffic. There are all sorts of drawbacks (blocking popular sites, for example), but I wonder if there are rate-limiting settings that would eliminate the majority of abuse reports based on default fail2ban and similar reporting system settings. For example, I wonder if the complaints I receive about SSH could be eliminated by slowing down repeated SSH connections to the same host by a second or so. Clearly more research is needed to work out if this is even feasible, and, if it is, what rate limits should apply to what ports. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
Would not help. These are bots, you can slow them down but this will not stop them at all. Markus 2016-10-09 1:57 GMT+02:00 teor <teor2345@gmail.com>:
On 7 Oct 2016, at 05:07, Green Dream <greendream848@gmail.com> wrote:
If we're going to change anything I think it needs to happen within Tor software. Operators could leverage the existing "Exitpolicy reject" rules, or Tor could add functionality there if it's missing. Whatever we do, I think it needs to be uniform and transparent.
I had a conversation with someone at the recent tor meeting about rate-limiting Tor traffic. There are all sorts of drawbacks (blocking popular sites, for example), but I wonder if there are rate-limiting settings that would eliminate the majority of abuse reports based on default fail2ban and similar reporting system settings.
For example, I wonder if the complaints I receive about SSH could be eliminated by slowing down repeated SSH connections to the same host by a second or so.
Clearly more research is needed to work out if this is even feasible, and, if it is, what rate limits should apply to what ports.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
True, but slowing them down could still be useful. At any rate, Suricata is a no-go for low-end relays that only have 500MB of RAM. It just hammers the pagefile. On Sat, Oct 8, 2016 at 7:00 PM, Markus Koch <niftybunny@googlemail.com> wrote:
Would not help. These are bots, you can slow them down but this will not stop them at all.
Markus
2016-10-09 1:57 GMT+02:00 teor <teor2345@gmail.com>:
On 7 Oct 2016, at 05:07, Green Dream <greendream848@gmail.com> wrote:
If we're going to change anything I think it needs to happen within Tor software. Operators could leverage the existing "Exitpolicy reject" rules, or Tor could add functionality there if it's missing. Whatever we do, I think it needs to be uniform and transparent.
I had a conversation with someone at the recent tor meeting about rate-limiting Tor traffic. There are all sorts of drawbacks (blocking popular sites, for example), but I wonder if there are rate-limiting settings that would eliminate the majority of abuse reports based on default fail2ban and similar reporting system settings.
For example, I wonder if the complaints I receive about SSH could be eliminated by slowing down repeated SSH connections to the same host by a second or so.
Clearly more research is needed to work out if this is even feasible, and, if it is, what rate limits should apply to what ports.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ 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
-- Finding information, passing it along. ～SuperSluether
On 9 Oct 2016, at 11:00, Markus Koch <niftybunny@googlemail.com> wrote:
Would not help. These are bots, you can slow them down but this will not stop them at all.
Ah, but the point isn't to stop the bots, it's to stop the abuse complaints by coming in under the abuse report automated thresholds. In my experience, the abuse complaints are auto-generated, and no-one replies to my offer to block the site. So why not eliminate the complaints? Then everyone will be happy. Except the bot-herders. Tim
Markus
2016-10-09 1:57 GMT+02:00 teor <teor2345@gmail.com>:
On 7 Oct 2016, at 05:07, Green Dream <greendream848@gmail.com> wrote:
If we're going to change anything I think it needs to happen within Tor software. Operators could leverage the existing "Exitpolicy reject" rules, or Tor could add functionality there if it's missing. Whatever we do, I think it needs to be uniform and transparent.
I had a conversation with someone at the recent tor meeting about rate-limiting Tor traffic. There are all sorts of drawbacks (blocking popular sites, for example), but I wonder if there are rate-limiting settings that would eliminate the majority of abuse reports based on default fail2ban and similar reporting system settings.
For example, I wonder if the complaints I receive about SSH could be eliminated by slowing down repeated SSH connections to the same host by a second or so.
Clearly more research is needed to work out if this is even feasible, and, if it is, what rate limits should apply to what ports.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ 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
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
I am more of a fan of closing certain URL paths. So we could at least stop these very old Apache directory bug attacks. Or forbid accessing whatever.com/admin/ Markus 2016-10-09 2:03 GMT+02:00 teor <teor2345@gmail.com>:
On 9 Oct 2016, at 11:00, Markus Koch <niftybunny@googlemail.com> wrote:
Would not help. These are bots, you can slow them down but this will not stop them at all.
Ah, but the point isn't to stop the bots, it's to stop the abuse complaints by coming in under the abuse report automated thresholds.
In my experience, the abuse complaints are auto-generated, and no-one replies to my offer to block the site. So why not eliminate the complaints? Then everyone will be happy. Except the bot-herders.
Tim
Markus
2016-10-09 1:57 GMT+02:00 teor <teor2345@gmail.com>:
On 7 Oct 2016, at 05:07, Green Dream <greendream848@gmail.com> wrote:
If we're going to change anything I think it needs to happen within Tor software. Operators could leverage the existing "Exitpolicy reject" rules, or Tor could add functionality there if it's missing. Whatever we do, I think it needs to be uniform and transparent.
I had a conversation with someone at the recent tor meeting about rate-limiting Tor traffic. There are all sorts of drawbacks (blocking popular sites, for example), but I wonder if there are rate-limiting settings that would eliminate the majority of abuse reports based on default fail2ban and similar reporting system settings.
For example, I wonder if the complaints I receive about SSH could be eliminated by slowing down repeated SSH connections to the same host by a second or so.
Clearly more research is needed to work out if this is even feasible, and, if it is, what rate limits should apply to what ports.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ 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
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Let's take it from the end. - nowadays we use IPS to filter over 130k webhosting accounts. It's up to the admin who set what exactly should be filtered. It's definitely not about the used sw. - I don't know how this BadExit evaluation thing works - if it values nodes automatically by accessing something over it, the IPS shouldn't be detected - During my praxis, I've met only like 10% of customers (tor exit node) with real data - unfortunately ISP is not the one who can judge that - we have to trust our customer - I say only one thing, it's necesarry to solve the legality of the traffic. The mood around tor service, of all ISPs I know, is below zero. It would be great to do something about that and I think that IPS with rules open to community is a way to go. "> On 5 Oct 2016, at 18:10, <oconor@email.cz> <oconor@email.cz> wrote:
We're back to IPS, which can drop the specific malicious traffic. I've
been speaking with the lawyer few minutes ago. He told me that there is a pressure to put all the responsibility for the traffic to the ISPs. Well ... what are the ISPs most probably going to do ... ? They can ban all tor exit nodes, or they will force the owners to clear the traffic.
When you're worried about being accused, why you don't use fake
information during registration and payments with bitcoins? Then you can also filter the traffic by IPS ... and everybory will be happy. There are a few things wrong with your suggested solution: * it's really, really hard to stay anonymous on the Internet as an individual, and impossible for many corporations (it's hard to be transparent about how you spend money as a charity, and be anonymous at the same time), * if all Tor Exit Nodes are anonymous, ISPs may block them more, not less, * filtering will likely get your Exit marked as a BadExit, * IPS aren't perfect - they let some unwanted traffic through, and block other traffic that is totally ok. Tim
What should a tor exit op do? Ban the user? exits get the traffic from
middle nodes and we cant tell (by design) who anyone is. We can block ips but that is not really helping with bots who tries to find vulnerabilities and scan large blocks.
markus
Sent from my iPad
On 4 Oct 2016, at 23:55, <oconor@email.cz> <oconor@email.cz> wrote:
If I understand that well ... if tor operator is avare, that his tor node
is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity?
On 04.10.16 22:37, oconor@email.cz wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to colloquially as the "provider privilege".
One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means.
According to two lawyers I spoke to, exit policies might already be borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data?
That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad".
-Ralph _______________________________________________ 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 _______________________________________________ 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
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org____________________________________________ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
- During my praxis, I've met only like 10% of customers (tor exit node) with real data - unfortunately ISP is not the one who can judge that - we have to trust our customer
TIL that I am an idiot for using my real data. How do they pay? With all of my webhosting companies I pay with PayPal or creditcard and with both I am clearly singled out because you cant get it anonymous. Markus
usualy bitcoins ... but there were also many cases of strawperson accounts via stolen ID card or other techniques. We solve that almost on daily basis with police. "> - During my praxis, I've met only like 10% of customers (tor exit node) with
real data - unfortunately ISP is not the one who can judge that - we have to trust our customer
TIL that I am an idiot for using my real data. How do they pay? With all of my webhosting companies I pay with PayPal or creditcard and with both I am clearly singled out because you cant get it anonymous. Markus _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
But this is not only related to Tor sites? May I asked for your websites so I can understand why you get so much fraud? Working with an ISP years ago, we didnt had this issue so often. There were users not paying but it was less fraud and more broke. Markus 2016-10-05 13:19 GMT+02:00 <oconor@email.cz>:
usualy bitcoins ... but there were also many cases of strawperson accounts via stolen ID card or other techniques. We solve that almost on daily basis with police.
- During my praxis, I've met only like 10% of customers (tor exit node) with real data - unfortunately ISP is not the one who can judge that - we have to trust our customer
TIL that I am an idiot for using my real data.
How do they pay? With all of my webhosting companies I pay with PayPal or creditcard and with both I am clearly singled out because you cant get it anonymous.
Markus _______________________________________________ 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
Nope I'm speaking generally about frauds we have to solve. Just few cases were connected directly to offenders who run tor on fake ID and use it purpousely as a cover for illegal activity. Other cases usualy use tor as a medium to anonymize their activity (unfortunately no IPS would help here). The last, but the major thing we solve are constant various exploits / bruteforcing / floods comming out from the exit nodes - this is the area where would some IPS really help. I'm sending you the name of the company on your email. "But this is not only related to Tor sites? May I asked for your websites so I can understand why you get so much fraud? Working with an ISP years ago, we didnt had this issue so often. There were users not paying but it was less fraud and more broke. Markus 2016-10-05 13:19 GMT+02:00 <oconor@email.cz>:
usualy bitcoins ... but there were also many cases of strawperson accounts via stolen ID card or other techniques. We solve that almost on daily basis with police.
- During my praxis, I've met only like 10% of customers (tor exit node) with real data - unfortunately ISP is not the one who can judge that - we have to trust our customer
TIL that I am an idiot for using my real data.
How do they pay? With all of my webhosting companies I pay with PayPal or creditcard and with both I am clearly singled out because you cant get it anonymous.
Markus _______________________________________________ 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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
Is the distinction between knowledge after the fact and knowledge at the time of occurence of "bad traffic" not important? I'm all for reducing bad traffic, but where does the line get drawn? I've also been dealing with multiple abuse reports on Digital Ocean. Quite a few common abuse ports are already disallowed (in fact I have only a small white list); most of the problems originate from port 80. And of course there's nothing we can do for encrypted web traffic anyway. For what it's worth, I'm glad this thread came up and I've notified Digital Ocean of it in one of my support tickets. It's really not up to lowly little me to decide whos traffic gets to pass. Alecks Gates On Tue, 2016-10-04 at 23:55 +0200, oconor@email.cz wrote:
If I understand that well ... if tor operator is avare, that his tor node is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity?
On 04.10.16 22:37, oconor@email.cz wrote:
Tor and IPS has both it's own nature and you shouldn't be punished, if your intension was just to filter the bad traffic.
And who is to decide what constitutes "bad traffic"? I am not a lawyer, but in Germany one of the cornerstones of not being held responsible for traffic passing through a Tor node is § 8 of the Telemediengesetz: http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to colloquially as the "provider privilege".
One only is free of responsibility if one neither initiates a transfer, nor selects the transfer's destination, nor selects or modifies the transmitted data. That's what "passing through" means.
According to two lawyers I spoke to, exit policies might already be
borderline breaking these rules for exit nodes, but the technical basis at least guarantees that traffic will never reach an exit node that does not let it pass. Now think of a firewall that interferes with transfers once the data has already reached the exit node. Wouldn't you agree that this means selecting/modifiying the transmitted data?
That's just one national law that I am aware of, I imagine other countries have similar regulations in place. Any internet service
provider interfering with net neutrality risks lawsuits, because it is not an ISP's prerogative to decide what traffic is "good" or "bad".
-Ralph _______________________________________________ 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 04.10.2016 23:55, oconor@email.cz wrote:
If I understand that well ... if tor operator is avare, that his tor node is used for illegal activity (when their ISP told them about that) and he's not going to do anything abou that, he wont be guity by complicity?
Like I said, I am no lawyer. However, I do know that German national law protects service providers from being held responsible as long as they only pass traffic through. There is an ongoing debate if Tor exit admins are service providers in the same sense as Internet backbone providers. Nobody in their right mind would dream of holding Internet exchanges like DE-CIX responsible for letting "bad traffic" (deliberately using this nebulous term) pass. Why should Tor operators be treated any different, only because they operate on a smaller scale? Both pass traffic from A to B without initiating the transfers, selecting the destinations, or manipulating the content. Note well that *deliberately* abusing network infrastructure for unlawful purposes is not protected. Another important issue: ISPs are not in the position to "tell me about illegal activity". I work with ISPs in what I believe is generally a friendly and mutually respectful fashion, and I value the technical service ISPs provide. However, the question of illegality is determined by courts alone, no ISP has that right. I had some discussions with one particular ISP who thought differently, mistakenly thinking that his tech staff could make the distinction between lawful and illegal. No dice. As far as abuse complaints go, I encourage ISPs to pass these along to the Tor operators and not spend any time and resources beyond that. Most Tor operators are hopefully responsible enough to process complaints in a reasonable fashion. That, in my opinion, does not mean blocking every destination IP out of sheer reflex, but rather informing the complaining party about Tor. The CP is free to block Tor exits, but I believe that it is their own job, not the job of every Tor operator or ISP. Also, I don't feel any obligation to spend time making the life of some person running an outdated, unprotected WordPress installation easier. ;-) -Ralph
Sounds great, but the reality is many sites will not block Tor traffic but will send (automated) abuse mails over and over and over again. Had this with a bank in South Korea who sent weekly abuse mails with "we will sue you in the USA, we will sue you in South Kora and we will never ending suing you all over the world" besides my e-mail to multiple bank e-mail accounts how to block Tor traffic from reaching the banks website. For whatever reason they dont block Tor traffic and thats their right. And the ISP gets abuse mails with the content "We sue you motherfucker" and gets mad. I completely understand that. Its easier to send out automated abuse mails and tell my boss "look, 1000 abuse mails, I am protected this website like Godzilla". Looks good on every weekly work report. Numbers count. Markus 2016-10-05 13:01 GMT+02:00 Ralph Seichter <tor-relays-ml@horus-it.de>:
On 04.10.2016 23:55, oconor@email.cz wrote:
As far as abuse complaints go, I encourage ISPs to pass these along to the Tor operators and not spend any time and resources beyond that. Most Tor operators are hopefully responsible enough to process complaints in a reasonable fashion. That, in my opinion, does not mean blocking every destination IP out of sheer reflex, but rather informing the complaining party about Tor. The CP is free to block Tor exits, but I believe that it is their own job, not the job of every Tor operator or ISP. Also, I don't feel any obligation to spend time making the life of some person running an outdated, unprotected WordPress installation easier. ;-)
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 05.10.16 13:16, Markus Koch wrote:
reality is many sites will not block Tor traffic but will send (automated) abuse mails over and over and over again.
True, sadly. And like you said it is their right not to block Tor based traffic. But it is your right not to heed their ongoing complaints and sabre-rattling, like it is your right to voluntarily update your exit policies. My point is that none of these choices requires your ISP to spend time, money or even thought on the issue, all that is required is passing it along to the Tor operators. -Ralph
Different viewpoint: I pay $5 + Taxes (WTF?) for an droplet with DigitalOcean I pay $7,5 for a VPS with Hostwinds Someone has to get the abuse mail, check where to send them and then make this issue as solved. From an economic standpoint this is a shitty idea. I cost them more than I pay. Even if we exclude the trouble with blocked IP ranges and the other stuff. Markus PS: Yes, the Tor wiki says: Get your own IP with your own data so the ISP is not involved. That's easier said than done. 2016-10-05 13:44 GMT+02:00 Ralph Seichter <tor-relays-ml@horus-it.de>:
On 05.10.16 13:16, Markus Koch wrote:
reality is many sites will not block Tor traffic but will send (automated) abuse mails over and over and over again.
True, sadly. And like you said it is their right not to block Tor based traffic. But it is your right not to heed their ongoing complaints and sabre-rattling, like it is your right to voluntarily update your exit policies. My point is that none of these choices requires your ISP to spend time, money or even thought on the issue, all that is required is passing it along to the Tor operators.
-Ralph
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Unfortunately for us (as an ISP) it's not just about passing these messages. If we don't want to be accused from not stopping something illegal we knew about, we need some feedback - what have been done to prevent this to happen in the future. If there is no feedback, we usualy disconnect the server from network.Anyway blocking ips via policy isn't usualy sufficient and the problem will appear soon again. Then we also randomly monitor the traffic to se if it is really clean as promissed. It's really time consuming and that's why I would like to combine tor with some IPS for automation of the "policy set process". "On 05.10.16 13:16, Markus Koch wrote:
reality is many sites will not block Tor traffic but will send (automated) abuse mails over and over and over again.
True, sadly. And like you said it is their right not to block Tor based traffic. But it is your right not to heed their ongoing complaints and sabre-rattling, like it is your right to voluntarily update your exit policies. My point is that none of these choices requires your ISP to spend time, money or even thought on the issue, all that is required is passing it along to the Tor operators. -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
Okay, I´ll volunteer as an guinea pig if you are okay with it, I´ll get 2 VPSs and you do your Snort magic on them. Worst case is that we all know it isnt working and we have learned something :) Markus 2016-10-05 14:06 GMT+02:00 <oconor@email.cz>: It's really time consuming and that's
why I would like to combine tor with some IPS for automation of the "policy set process".
I wish I had spare time for doing that magic ... I think, that easier solution for me as an ISP is to shut the node down. ---------- Původní zpráva ---------- Od: Markus Koch <niftybunny@googlemail.com> Komu: tor-relays <tor-relays@lists.torproject.org> Datum: 5. 10. 2016 15:07:37 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata "Okay, I´ll volunteer as an guinea pig if you are okay with it, I´ll get 2 VPSs and you do your Snort magic on them. Worst case is that we all know it isnt working and we have learned something :) Markus 2016-10-05 14:06 GMT+02:00 <oconor@email.cz>: It's really time consuming and that's
why I would like to combine tor with some IPS for automation of the "policy
set process".
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
On 05.10.2016 14:06, oconor@email.cz wrote:
Unfortunately for us (as an ISP) it's not just about passing these messages. If we don't want to be accused from not stopping something illegal we knew about, we need some feedback - what have been done to prevent this to happen in the future.
If you pass on the complaint to me, I'll give you the feedback that I will deal with it (using "you" and "I" as examples, obviously). While I do have the responsibility to verify that my server has not been compromised, I am not obliged to provide detailed information on how I deal with complaints. Also, just because some complaining party does not like the traffic passing through my server, it does not mean that I automatically have a legally binding obligation to prevent that traffic. Don't get me wrong, I do take complaints seriously, and I always strive to work with my ISPs to resolve issues in an amicable manner. However, I do that because I choose to be a good netizen. Sometimes I don't do anything at all, because it either does not make any sense or would violate the "just passing through" concept (e.g. I never use any form of traffic content inspection).
It's really time consuming and that's why I would like to combine tor with some IPS for automation of the "policy set process".
I can see what motivates you. Personally, I can't think of a scenario where I would use automation to set outbound traffic policies (inbound traffic is a different matter, fail2ban comes to mind). I am interested in other people's opinion regarding the prospect of an automated tool to generate exit policies. -Ralph
On Wed, 05 Oct 2016 15:40:49 +0000, Ralph Seichter wrote: ...
I can see what motivates you. Personally, I can't think of a scenario where I would use automation to set outbound traffic policies (inbound traffic is a different matter, fail2ban comes to mind).
How this? Everything to the OR port needs to pass in, esp. when you act as a guard, and fail2banning the ssh port, hmm. Everything else is closed anyway. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On 05.10.2016 16:03, Andreas Krey wrote:
Everything to the OR port needs to pass in, esp. when you act as a guard, and fail2banning the ssh port, hmm. Everything else is closed anyway.
What I meant is that I can see a use for automation when it comes to securing a server -- not necessarily a dedicated Tor node, which, like you correctly mentioned, probably only has ports for SSH and Tor opened anyway -- from malicious inbound traffic. Outbound traffic is a different beast. In a Tor server context, I don't see what kind of automation might be able to generate policies. Also, I don't like the idea of automated (self-)censorship on Tor exits. -Ralph
There is a possibility of parsing log of IPS a do actions with the policies. "On 05.10.2016 16:03, Andreas Krey wrote:
Everything to the OR port needs to pass in, esp. when you act as a guard, and fail2banning the ssh port, hmm. Everything else is closed anyway.
What I meant is that I can see a use for automation when it comes to securing a server -- not necessarily a dedicated Tor node, which, like you correctly mentioned, probably only has ports for SSH and Tor opened anyway -- from malicious inbound traffic. Outbound traffic is a different beast. In a Tor server context, I don't see what kind of automation might be able to generate policies. Also, I don't like the idea of automated (self-)censorship on Tor exits. -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
On 06.10.16 12:12, oconor@email.cz wrote:
There is a possibility of parsing log of IPS a do actions with the policies.
I don't trust any IPS that I have seen so far to come up with smart enough exit policies. If I were to use an IPS to dynamically limit inbound traffic (on a non-Tor server) and the IPS gets things wrong, only my own server is affected. If an IPS gets outbound Tor policies wrong, it potentially affects a lot of people. Manually dealing with complaints is a chore, but I am willing to invest the necessary time and work to be able to make an informed decision. I can understand that not every service provider has the manpower (or willingness) to do the same, but I consider Tor's purpose to be too important to leave decisions to a piece of software. -Ralph
What have you been working with? :) When the IPS is working wrong, it's because of the admin ... :) You probably will invest your time, but the ISP won't. The amount of the problems is multiplying. Tor should evolve, or it will extinct like dinosaurs. I think that this IPS should be done by community (or at least the setting of some IPS product). It should be completely open and transparent - the code and rules. ---------- Původní zpráva ---------- Od: Ralph Seichter <tor-relays-ml@horus-it.de> Komu: tor-relays@lists.torproject.org Datum: 6. 10. 2016 12:34:02 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata "On 06.10.16 12:12, oconor@email.cz wrote:
There is a possibility of parsing log of IPS a do actions with the
policies.
I don't trust any IPS that I have seen so far to come up with smart enough exit policies. If I were to use an IPS to dynamically limit inbound traffic (on a non-Tor server) and the IPS gets things wrong, only my own server is affected. If an IPS gets outbound Tor policies wrong, it potentially affects a lot of people. Manually dealing with complaints is a chore, but I am willing to invest the necessary time and work to be able to make an informed decision. I can understand that not every service provider has the manpower (or willingness) to do the same, but I consider Tor's purpose to be too important to leave decisions to a piece of software. -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
On 06.10.16 12:57, oconor@email.cz wrote:
You probably will invest your time, but the ISP won't. The amount of the problems is multiplying. Tor should evolve, or it will extinct like dinosaurs.
I don't think that Tor has a problem. It works as designed. One might say that service providers have a problem dealing with Tor, because of the effort involved, or that complaining parties have a problem with Tor, because they don't understand or care that a Tor exit is not the real source of "bad traffic", or that they can block Tor based traffic by using the already existing information provided by the Tor project (see https://www.torproject.org/docs/faq-abuse.html.en#Bans). Pointing fingers is not going to help, and neither is implementing automated self-censorship on Tor exits. If somebody wants me to block his destination IP on my Tor exit nodes, he'll have to explicitly tell me so, and explain why he's not blocking my exit nodes instead. -Ralph
On 10/06/2016 05:39 AM, Ralph Seichter wrote:
On 06.10.16 12:57, oconor@email.cz wrote:
You probably will invest your time, but the ISP won't. The amount of the problems is multiplying. Tor should evolve, or it will extinct like dinosaurs.
I don't think that Tor has a problem. It works as designed. One might say that service providers have a problem dealing with Tor, because of the effort involved, or that complaining parties have a problem with Tor, because they don't understand or care that a Tor exit is not the real source of "bad traffic", or that they can block Tor based traffic by using the already existing information provided by the Tor project (see https://www.torproject.org/docs/faq-abuse.html.en#Bans).
Why does "real source" matter? To the extent that Tor works as designed, the "real source" is unknown (ideally "unknowable"). What matters for "complaining parties" is that they're getting crap from some exit relay. So they complain.
Pointing fingers is not going to help, and neither is implementing automated self-censorship on Tor exits. If somebody wants me to block his destination IP on my Tor exit nodes, he'll have to explicitly tell me so, and explain why he's not blocking my exit nodes instead.
Well, that's the other problem. Your exit nodes, on average, are not much better or worse than others. Exit policy matters, I admit, but exits that don't allow 80, 443, 22 and other mainstream ports are not very useful. So more and more sites either block Tor exits entirely, or label activity from them as fraudulent. Just telling complainers to block Tor exits may resolve your issues, but it creates others. Arguably, it's the complainers that should be implementing IPS and/or other measures that block whatever they don't like. Rather than just blocking Tor exits, or filing abuse reports. But expecting that to happen is probably unrealistic.
-Ralph
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 06.10.16 14:29, Mirimir wrote:
What matters for "complaining parties" is that they're getting crap from some exit relay. So they complain.
Sure, and I don't have a problem with that. If I get complaints, I tell the CP about Tor, and point them to the relevant information. All good until that point.
Just telling complainers to block Tor exits may resolve your issues, but it creates others.
It is a question of perspective. I don't have issues with a percentage of "bad traffic" passing through my exits. I have come to accept this as a unfortunate but necessary downside of how Tor works. The majority is "good traffic", and that's why I -- like others -- support Tor in the first place. I would not dream of removing ports 80 or 443 from my exit policies just because some malicious clients are trying to break into WordPress installations.
Arguably, it's the complainers that should be implementing IPS and/or other measures that block whatever they don't like.
Quite so. If somebody places a server on the Internet, he accepts public access. That includes the necessity to deal with "bad traffic" in one way or other. Complaining to a Tor exit operator with "you are doing a bad thing" is factually incorrect. I willingly help CPs if they show an interest, because that is polite and helps the Tor project. However, under national law, I do not have an obligation to block traffic until a court tells me to. Obviously I have no interest in lawsuits and prefer talking to people to find a solution. I just don't jump because some CP says "hop". ;-) -Ralph
It's apparent, that you're definitely not going to solve that ... you're more into searching reasons why not to do that, than possibility how to do that :) (btw you haven't mentioned you IPS experiences) I just say facts - the amount of malicious traffic is rising (during last 5 years it's multiplying its volume) - to be exact in last two years we filtered just in our network over 300000 various DDOS attack - before we used non automated system (tcpdump on backbone routers and iptables) because anything automated wasn't necessary!, the amount of malicious traffic (not DDoS) against our webhosting servers is nowadays ~15% (that's 300Mbit/s), in last year it rised 3x. - I know about every tor server in our VPS segment - it's not difficult - the warnings about malicious traffic keeps comming. The amount of reported problems grows with the same trend as the amount of the malicious traffic on the internet. - The traffic going out of tor exit nodes in our network is even worse that the one which is comming out of the internet. Paul who started this thread has constant flow over 50kpps. It consists mostly from various DoS attacks + exploits against many known CMS. I wouldn't wonder if there could come an attack against our infrastructure. Anyway it would be really interesting to analyze that flow completely. - The next thing (already mentioned) is that these Pauls tor nodes in our case can worse reputation of one /22 and one /21 subnets. That's a crucial problem for us, nineties are bye bye, we got just few 21 subnets and we can' t afford to have IP banned by some widely used authority. This is the short summary ... the only thing I say as an ISP is, that if this is not going to change, we're going to ban tor in our network. The amount of resources we have to give for managing something like that, doesn' t have economical sense for us. I would wonder if there will be an ISP in 3- 5 years who is going to have another oppinion. ---------- Původní zpráva ---------- Od: Ralph Seichter <tor-relays-ml@horus-it.de> Komu: tor-relays@lists.torproject.org Datum: 6. 10. 2016 13:39:54 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata "On 06.10.16 12:57, oconor@email.cz wrote:
You probably will invest your time, but the ISP won't. The amount of
the problems is multiplying. Tor should evolve, or it will extinct
like dinosaurs.
I don't think that Tor has a problem. It works as designed. One might say that service providers have a problem dealing with Tor, because of the effort involved, or that complaining parties have a problem with Tor, because they don't understand or care that a Tor exit is not the real source of "bad traffic", or that they can block Tor based traffic by using the already existing information provided by the Tor project (see https://www.torproject.org/docs/faq-abuse.html.en#Bans). Pointing fingers is not going to help, and neither is implementing automated self-censorship on Tor exits. If somebody wants me to block his destination IP on my Tor exit nodes, he'll have to explicitly tell me so, and explain why he's not blocking my exit nodes instead. -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
On Oct 6, 2016, at 7:45 AM, <oconor@email.cz> <oconor@email.cz> wrote:
- The traffic going out of tor exit nodes in our network is even worse that the one which is comming out of the internet. Paul who started this thread has constant flow over 50kpps. It consists mostly from various DoS attacks + exploits against many known CMS. I wouldn't wonder if there could come an attack against our infrastructure. Anyway it would be really interesting to analyze that flow completely.
This is a useful point. Tor IPS wouldn't need to "censor" anything, or even scan Tor traffic. Tor nodes are under constant attack, they're natural "honeypot" servers. TIPS could detect a base set of commonly-known malicious attacks _on_the_node_itself_ (not on internal Tor traffic), and then determine if those attacks were coming from another Tor node (easily done). If so, TIPS could "run it up the chain" to block the actual offending host at the other end of the Tor connection, (probably) without compromising anonymity, and without breaking the Tor network. Attacks coming from a non-Tor node could optionally be ignored or processed like a "standard" IPS, depending on how it's implemented. I recognize that the actual implementation is still non-trivial, but this would at least give the Tor network a base level of IPS capability without breaking anything. More important, it would demonstrate to the Internet community that Tor is actually doing something proactive about abuse. Tor claims to operate like a specialized ISP, and any good ISP protects its own servers. Jon
On 06.10.16 14:45, oconor@email.cz wrote:
It's apparent, that you're definitely not going to solve that ... you're more into searching reasons why not to do that, than possibility how to do that :)
It is not my job to solve "that", whatever that is exactly. ;-)
(btw you haven't mentioned you IPS experiences)
I was not aware that you had asked me about my IPS experiences. I have used various tools as the Internet evolved (and I was in the "computer business" before the Internet even existed, by the way). Discussing IPS would be something for a different mailing list.
the only thing I say as an ISP is, that if this is not going to change, we're going to ban tor in our network.
I respect your position, and I think that I can understand the point of view of internet service providers. My personal take is that I rent many servers (as do my customers), with only a small number of Tor exits, and overall I am still generating enough profit for service providers. My Tor exits are a fly in the ointment. -Ralph
The subject of this thread is: Intrusion Prevention System Software - Snort or Suricata I'll be more than glad, if we can have some productive discussion about these two contemporaly IPS and their implementation along with tor. If the only thing you wanted to say was, that you're against that, we're probably done ;) ---------- Původní zpráva ---------- Od: Ralph Seichter <tor-relays-ml@horus-it.de> Komu: tor-relays@lists.torproject.org Datum: 6. 10. 2016 15:39:55 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata "On 06.10.16 14:45, oconor@email.cz wrote:
It's apparent, that you're definitely not going to solve that ...
you're more into searching reasons why not to do that, than possibility
how to do that :)
It is not my job to solve "that", whatever that is exactly. ;-)
(btw you haven't mentioned you IPS experiences)
I was not aware that you had asked me about my IPS experiences. I have used various tools as the Internet evolved (and I was in the "computer business" before the Internet even existed, by the way). Discussing IPS would be something for a different mailing list.
the only thing I say as an ISP is, that if this is not going to
change, we're going to ban tor in our network.
I respect your position, and I think that I can understand the point of view of internet service providers. My personal take is that I rent many servers (as do my customers), with only a small number of Tor exits, and overall I am still generating enough profit for service providers. My Tor exits are a fly in the ointment. -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
On 06.10.16 16:24, oconor@email.cz wrote:
The subject of this thread is: Intrusion Prevention System Software - Snort or Suricata
Fixed that for you. ;-)
If the only thing you wanted to say was, that you're against that, we're probably done ;)
Stating that I oppose the idea of IPS as means of automatic censorship of Tor exit nodes is part of the discussion. -Ralph
Suricata allows direct access via the Tor network, Snort's website gave me multiple failed Captchas before I could access anything. I'm going to do some further research before I even think about implementing anything. How does one detect false positives when running an IPS? Do you just frequently check the alerts and change the rules when necessary? On Thu, Oct 6, 2016 at 9:45 AM, Ralph Seichter <tor-relays-ml@horus-it.de> wrote:
On 06.10.16 16:24, oconor@email.cz wrote:
The subject of this thread is: Intrusion Prevention System Software - Snort or Suricata
Fixed that for you. ;-)
If the only thing you wanted to say was, that you're against that, we're probably done ;)
Stating that I oppose the idea of IPS as means of automatic censorship of Tor exit nodes is part of the discussion.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
Our implementation of suricata is a little different. We've got one as IPS (just few rules) and second as IDS (all rules (block of rules) are switched on). In the log of IDS we determine which chains should be filtered and then we filter them one by one on IPS. The main thing is to not to cut of any of the customers (in our case). ---------- Původní zpráva ---------- Od: Tristan <supersluether@gmail.com> Komu: tor-relays@lists.torproject.org Datum: 6. 10. 2016 16:50:33 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata or no IPS at all " Suricata allows direct access via the Tor network, Snort's website gave me multiple failed Captchas before I could access anything. I'm going to do some further research before I even think about implementing anything. How does one detect false positives when running an IPS? Do you just frequently check the alerts and change the rules when necessary? On Thu, Oct 6, 2016 at 9:45 AM, Ralph Seichter <tor-relays-ml@horus-it.de (mailto:tor-relays-ml@horus-it.de)> wrote: "On 06.10.16 16:24, oconor@email.cz(mailto:oconor@email.cz) wrote:
The subject of this thread is: Intrusion Prevention System Software -
Snort or Suricata
Fixed that for you. ;-)
If the only thing you wanted to say was, that you're against that,
we're probably done ;)
Stating that I oppose the idea of IPS as means of automatic censorship of Tor exit nodes is part of the discussion. -Ralph ______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org(mailto:tor-relays@lists.torproject.org) https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays (https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays) " -- Finding information, passing it along. ～SuperSluether _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
I may have just found a bigger problem: I can't access the Suricata rulesets from my exit node. The website replies with "Error code 15, This request was blocked by the security rules." When I try to wget the ruleset from my exit node, I get error 403 forbidden. Even if Suricata ships with some basic rulesets, it looks like I wouldn't be able to update them, because they block Tor exit nodes. Any ideas how to get around that? On Thu, Oct 6, 2016 at 9:57 AM, <oconor@email.cz> wrote:
Our implementation of suricata is a little different. We've got one as IPS (just few rules) and second as IDS (all rules (block of rules) are switched on). In the log of IDS we determine which chains should be filtered and then we filter them one by one on IPS. The main thing is to not to cut of any of the customers (in our case).
---------- Původní zpráva ---------- Od: Tristan <supersluether@gmail.com> Komu: tor-relays@lists.torproject.org Datum: 6. 10. 2016 16:50:33 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata or no IPS at all
Suricata allows direct access via the Tor network, Snort's website gave me multiple failed Captchas before I could access anything. I'm going to do some further research before I even think about implementing anything.
How does one detect false positives when running an IPS? Do you just frequently check the alerts and change the rules when necessary?
On Thu, Oct 6, 2016 at 9:45 AM, Ralph Seichter <tor-relays-ml@horus-it.de> wrote:
On 06.10.16 16:24, oconor@email.cz wrote:
The subject of this thread is: Intrusion Prevention System Software - Snort or Suricata
Fixed that for you. ;-)
If the only thing you wanted to say was, that you're against that, we're probably done ;)
Stating that I oppose the idea of IPS as means of automatic censorship of Tor exit nodes is part of the discussion.
-Ralph ______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org <tor-relays@lists.torproject.org> https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
-- Finding information, passing it along. ～SuperSluether _______________________________________________ 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
-- Finding information, passing it along. ～SuperSluether
You can't access suricata directly? ---------- Původní zpráva ---------- Od: Tristan <supersluether@gmail.com> Komu: tor-relays@lists.torproject.org Datum: 6. 10. 2016 17:02:19 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata or no IPS at all " I may have just found a bigger problem: I can't access the Suricata rulesets from my exit node. The website replies with "Error code 15, This request was blocked by the security rules." When I try to wget the ruleset from my exit node, I get error 403 forbidden. Even if Suricata ships with some basic rulesets, it looks like I wouldn't be able to update them, because they block Tor exit nodes. Any ideas how to get around that? On Thu, Oct 6, 2016 at 9:57 AM, <oconor@email.cz(mailto:oconor@email.cz)> wrote: " Our implementation of suricata is a little different. We've got one as IPS (just few rules) and second as IDS (all rules (block of rules) are switched on). In the log of IDS we determine which chains should be filtered and then we filter them one by one on IPS. The main thing is to not to cut of any of the customers (in our case). ---------- Původní zpráva ---------- Od: Tristan <supersluether@gmail.com(mailto:supersluether@gmail.com)> Komu: tor-relays@lists.torproject. org (mailto:tor-relays@lists.torproject.org) Datum: 6. 10. 2016 16:50:33 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata or no IPS at all " Suricata allows direct access via the Tor network, Snort's website gave me multiple failed Captchas before I could access anything. I'm going to do some further research before I even think about implementing anything. How does one detect false positives when running an IPS? Do you just frequently check the alerts and change the rules when necessary? On Thu, Oct 6, 2016 at 9:45 AM, Ralph Seichter <tor-relays-ml@horus-it.de (mailto:tor-relays-ml@horus-it.de)> wrote: "On 06.10.16 16:24, oconor@email.cz(mailto:oconor@email.cz) wrote:
The subject of this thread is: Intrusion Prevention System Software -
Snort or Suricata
Fixed that for you. ;-)
If the only thing you wanted to say was, that you're against that,
we're probably done ;)
Stating that I oppose the idea of IPS as means of automatic censorship of Tor exit nodes is part of the discussion. -Ralph ______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org(mailto:tor-relays@lists.torproject.org) https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays (https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays) " -- Finding information, passing it along. ～SuperSluether ______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org(mailto:tor-relays@lists.torproject.org) https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays (https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays)" ______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org(mailto:tor-relays@lists.torproject.org) https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays (https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays) " -- Finding information, passing it along. ～SuperSluether _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
I think I'm doing this wrong. I was trying to access the ruleset links from this page: https://suricata.readthedocs.io/en/latest/rules/intro.html But I think I'm actually supposed to get the rulesets from somewhere else: https://suricata.readthedocs.io/en/latest/oinkmaster.html I can access Suricata, I'm just trying to figure out how all this works before I actually start to mess around with it on a server. On Thu, Oct 6, 2016 at 10:09 AM, <oconor@email.cz> wrote:
You can't access suricata directly?
---------- Původní zpráva ---------- Od: Tristan <supersluether@gmail.com> Komu: tor-relays@lists.torproject.org Datum: 6. 10. 2016 17:02:19 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata or no IPS at all
I may have just found a bigger problem: I can't access the Suricata rulesets from my exit node. The website replies with "Error code 15, This request was blocked by the security rules." When I try to wget the ruleset from my exit node, I get error 403 forbidden.
Even if Suricata ships with some basic rulesets, it looks like I wouldn't be able to update them, because they block Tor exit nodes. Any ideas how to get around that?
On Thu, Oct 6, 2016 at 9:57 AM, <oconor@email.cz> wrote:
Our implementation of suricata is a little different. We've got one as IPS (just few rules) and second as IDS (all rules (block of rules) are switched on). In the log of IDS we determine which chains should be filtered and then we filter them one by one on IPS. The main thing is to not to cut of any of the customers (in our case).
---------- Původní zpráva ---------- Od: Tristan <supersluether@gmail.com> Komu: tor-relays@lists.torproject. org <tor-relays@lists.torproject.org> Datum: 6. 10. 2016 16:50:33 Předmět: Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata or no IPS at all
Suricata allows direct access via the Tor network, Snort's website gave me multiple failed Captchas before I could access anything. I'm going to do some further research before I even think about implementing anything.
How does one detect false positives when running an IPS? Do you just frequently check the alerts and change the rules when necessary?
On Thu, Oct 6, 2016 at 9:45 AM, Ralph Seichter <tor-relays-ml@horus-it.de> wrote:
On 06.10.16 16:24, oconor@email.cz wrote:
The subject of this thread is: Intrusion Prevention System Software - Snort or Suricata
Fixed that for you. ;-)
If the only thing you wanted to say was, that you're against that, we're probably done ;)
Stating that I oppose the idea of IPS as means of automatic censorship of Tor exit nodes is part of the discussion.
-Ralph ______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org <tor-relays@lists.torproject.org> https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
-- Finding information, passing it along. ～SuperSluether ______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org <tor-relays@lists.torproject.org> https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
______________________________ _________________ tor-relays mailing list tor-relays@lists.torproject. org <tor-relays@lists.torproject.org> https://lists.torproject.org/ cgi-bin/mailman/listinfo/tor- relays <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
-- Finding information, passing it along. ～SuperSluether _______________________________________________ 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
-- Finding information, passing it along. ～SuperSluether
participants (15)
-
Alecks Gates -
Andreas Krey -
BlinkTor -
Green Dream -
Jon Gardner
-
krishna e bera -
Markus Koch -
Mirimir -
Moritz Bartl -
oconor＠email.cz -
pa011 -
Ralph Seichter -
Roger Dingledine -
teor -
Tristan