[tor-relays] G-Core Labs and their humanoid robots
TL;DR: G-Core Labs does not understand their abuse detection software and their support agents are a bunch of humanoid robots. Dear customer, Due to suspicious activity SMTP ports have been blocked. Affected service ID: . Destination port: 25, 465, 587. To unblock contact support. Me: hello, i guess you are referring to a recent spamhaus entry? i do not use ports 25, 465, 587 so it likely is a false positive. I don't need these ports open but i would prefer if you could unlock them in case i would like to use them in the future. otherwise i might wonder why they don't work without remembering that they got blocked on your end. Thanls Support agent 1: Hello, In terms of Acceptable Use Policy (AUP), clause 2(d), we reserve a right to block SMTP ports if your service is not located at our platform. Please, find the list of blockage cases and solutions. 1) Service belongs to third parties. Unfortunately, we have to deny your request of unblocking SMTP ports according to AUP. 2) Service belongs to our platform. Please, specify domain you send emails to. If domain is fine, we'll unblock ports accordingly. 3) You didn't send any emails. Please, check your server to find the reason of spamming. As soon you resolve the issue, we'll unblock ports. However if our automated system identifies spamming on your server again, we'll have to block SMTP ports permanently. We kindly ask you to send a reply in a detailed manner so we could analyze your case accordingly. Me: I will repeat myself: I do not send emails. Please unblock the SMTP ports or specify why you blocked the SMTP ports. Thanks. Support agent 1: Check your network settings, perhaps something could cause it. Tell us what you will found and we will figure it out. Me: I do not have a reason to believe the server got hacked and i do not use the server to send emails so it likely is a false positive. Why were the SMTP ports blocked? Support agent 1: It was blocked because automatic monitoring system find your activity suspicious. Now, trust level of your traffic for IP has been increased however the traffic is still automatically monitored. If the system of automatization identifies your traffic as illegitimate or if we receive an infringement report, we'll have to disable ports once again. Me: Please do not block any ports without my consent when you do not have any logfiles that prove any misbehavior. "Automatic monitoring system find your activity suspicious" does not help in debugging any possible misbehavior coming from my server. Do you have information about where i can read up about the function of your automatic monitoring system to prevent this problem? Support agent 1: We can't share information about algorithm. Four days later, different support agent: Dear customer, Due to suspicious activity SMTP ports have been blocked. Affected service ID: . Destination port: 25, 465, 587. To unblock contact support. Me: hello, can you please give me more details about the suspicious activity? Support agent 1: Hello, In terms of Acceptable Use Policy (AUP), clause 2(d), we reserve a right to block SMTP ports if your service is not located at our platform. Please, find the list of blockage cases and solutions. 1) Service belongs to third parties. Unfortunately, we have to deny your request of unblocking SMTP ports according to AUP. 2) Service belongs to our platform. Please, specify domain you send emails to. If domain is fine, we'll unblock ports accordingly. 3) You didn't send any emails. Please, check your server to find the reason of spamming. As soon you resolve the issue, we'll unblock ports. However if our automated system identifies spamming on your server again, we'll have to block SMTP ports permanently. We kindly ask you to send a reply in a detailed manner so we could analyze your case accordingly. Me: Thanks but i know the AUP. The server does not send any emails and i do not have a reason to believe the server got hacked so please tell me the timestamp and destination of the connection that triggered your automatic monitoring system. Support agent 1: Let us please discuss your issue with our colleagues. We will inform you on this ticket. Support agent 1: Hello! Thank you for waiting! Unfortunately, we have to decline your unblocking request. As we see there is a second block on the same server. We couldn't unblock ports if they were blocked once Me: My question was: What triggered the block? Support agent 1: We couldn't provide you detailed information about SMTP-blocking system, sorry. The block is triggered if your server has suspicious activity on SMTP ports. Me: i understood that. What does "suspicious activity" means? Support agent 1: Let us, please, clarify this information with our engineers Me: Thank you. I hope you understand that it's an unfortunate situation when i do not find any misbehavior on the server but your "automatic monitoring system" accuses me of misbehavior and the answer is "there was suspicious activity
Re: [tor-relays] Relay consensus weight drop
mikefloyd2: > Hi, > I've noticed that my relay's bandwidth has been continuously dropping during > the last couple of weeks. > My bandwidth has been stable during that time, and I haven't changed anything > in terms of configuration. > I've also noticed that bastet, longclaw and maatuska are showing lower > weights for my relay. > Have been any changes recently in the network that could cause this? > > My relay - > https://metrics.torproject.org/rs.html#details/671A68ABADA1402FB00676055F48EA123B9B060C Hrm. I am not sure. bastet, longclaw, and maatuska are running sbws, our new and simple bandwidth scanner (bastet switched over to it on 05/28). So, there could be a still existing underlying sbws bug that is causing the decline. I've opened a ticket[1] to investigate the issue. Thanks, Georg > Thanks in advance, > Mike > > Sent with [ProtonMail](https://protonmail.com/) Secure Email. > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay consensus weight drop
Mike is not the only one - I've been seeing the exact same thing. My relay is https://metrics.torproject.org/rs.html#details/A2F5DF163132CF8FFC1F6343135D3397CA85CF89 Cheers Claus Den ons. 9. jun. 2021 kl. 14.38 skrev Georg Koppen : > mikefloyd2: > > Hi, > > I've noticed that my relay's bandwidth has been continuously dropping > during the last couple of weeks. > > My bandwidth has been stable during that time, and I haven't changed > anything in terms of configuration. > > I've also noticed that bastet, longclaw and maatuska are showing lower > weights for my relay. > > Have been any changes recently in the network that could cause this? > > > > My relay - > https://metrics.torproject.org/rs.html#details/671A68ABADA1402FB00676055F48EA123B9B060C > > Hrm. I am not sure. bastet, longclaw, and maatuska are running sbws, our > new and simple bandwidth scanner (bastet switched over to it on 05/28). > So, there could be a still existing underlying sbws bug that is causing > the decline. > > I've opened a ticket[1] to investigate the issue. > > Thanks, > Georg > > > Thanks in advance, > > Mike > > > > Sent with [ProtonMail](https://protonmail.com/) Secure Email. > > > > > > ___ > > 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] Relay consensus weight drop
Hi, I've noticed that my relay's bandwidth has been continuously dropping during the last couple of weeks. My bandwidth has been stable during that time, and I haven't changed anything in terms of configuration. I've also noticed that bastet, longclaw and maatuska are showing lower weights for my relay. Have been any changes recently in the network that could cause this? My relay - https://metrics.torproject.org/rs.html#details/671A68ABADA1402FB00676055F48EA123B9B060C Thanks in advance, Mike Sent with [ProtonMail](https://protonmail.com/) Secure Email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] G-Core Labs and their humanoid robots
Thank you for sharing that. It's obvious that they are either using third-parties or that they are afraid of being bullied by the Spamhaus gang. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running Tor exit nodes on university networks
On Tue, Jun 08, 2021 at 09:26:28AM +0200, Matthias Fetzer wrote: > Hi Andreas, > Hello Matthias, > There is a mailing list for tor & universities: > https://lists.torproject.org/pipermail/tor-relays-universities/ its not very > high traffic and the archives do not hold many e-mails. > > It's maybe worth to ask there too and to read through the archives. > We have looked at the archives and the one mail that was fairly recent and relevant was https://lists.torproject.org/pipermail/tor-relays-universities/2020-December/57.html which only got one SPAM reply. We decided it would be better if I post on this list instead. > I'd also suggest to check for EDU relays on relay search and contact some of > the bigger EDU relays directly. It would probably be good to have some > catalog of questions ready. > > Edu AS that I remember to run tor exit relays: > > - AS3 (MIT, US) > - AS680 (DFN, DE) > - AS12093 (UWaterloo, CA) > - AS36850 (UNC, US) > > There are probably dozens more. So I'd suggest to browse through relay > search yourself :-) > Thank you for the concrete suggestion regarding relevant AS numbers to look at. We were keeping direct contact as plan B if we wouldn't receive any replies on the list. On Tue, Jun 08, 2021 at 05:06:43PM -0300, gus wrote: > Hi, > Hello, > That's awesome, Andreas! > > We have this page with some tips: > https://community.torproject.org/relay/community-resources/tor-relay-universities/ > I read through the page before mailing the list and I especially appreciate the template letter from EFF. I am hoping that a system of standardised response e-mails can be realised to lessen the burden of handling complaints. Maybe with some degree of automation? > Here's a project that other members of our community have used in > the past and that you could adapt for your university: > https://www.overleaf.com/project/541e42eddb749944790bd16d > > And as Matthias said, you can find more relays outside .EDU, for > example, this non-exit node hosted by our friends in University of > Campinas, in Brazil: > https://metrics.torproject.org/rs.html#details/1E7BDE03151AAB779CB4AFEAEEA52536FFAA9400 > I don't think running a non-exit node would be an issue since they won't generate nearly as much abuse. I have considered looking at running normal nodes or possibly bridges if we hit a wall regarding exit nodes. > Regarding your specific questions, we can chat on #tor-relays / > irc.oftc.net[1] (or #tor-relays:matrix.org, if you use matrix). > I'm present on oftc and will get in touch. Thank you both for your answers! Cordially, Andreas Kempe signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] G-Core Labs and their humanoid robots
On Tue, Jun 08, 2021 at 01:56:33PM +0200, Tor Relays wrote: > Support agent 1: > It was blocked because automatic monitoring system find your activity > suspicious. > Now, trust level of your traffic for IP has been increased however the > traffic is still automatically monitored. If the system of automatization > identifies your traffic as illegitimate or if we receive an infringement > report, we'll have to disable ports once again. Right, this is the key part of the explanation. Typically the way these blocklists work is that they run "honey services" somewhere secret on the internet, often on ports like 80 that are different from the ones they will apply the blocklist to. And if anybody connects to their secret honey IP address on port 80, they call them a likely spammer and refuse to allow emails/etc to their other services from that address. And Tor exits are particularly susceptible to getting put on these kind of blocklists, because all it takes is one person trying to connect to the honey address, and bam the exit relay's IP address gets on the blocklist. And the "cross-protocol" nature of the blocking, where they see you do one protocol and then block you from doing a different protocol, also does not match well with Tor's notion of exit policies. I guess that the scale of jerks on the internet is huge compared to what they imagine is the scale of non-jerks on Tor, and so they have little incentive to change the design of their honeypot systems. :( --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays