Re: [tor-relays] G-Core Labs and their humanoid robots

2021-06-11 Thread tor-opera...@urdn.com.ua
Roger Dingledine  wrote:

> 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.

I don't think that it is the reason.

Most likely G-Core Labs received automatic abuse reports from hosts
that complained that there were attempts to scan some website or brute
force an SMTP relay.

Then they triggered the filtering in fear of being put in blacklists.
___
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

2021-06-11 Thread Tobias Höller

On 11.06.21 11:06, Ningú wrote:
Also, maybe someone is running a relay on port 25/465/587/whatnot and 
that is what triggered G-Core Labs alarms? I don't know how to find 
this with relay search. Orport shows in the results but searches for 
orport:NNN will fail.


Since I just had a fairly recent consensus file (June 9th 2021 01:00) 
open, I took the liberty of quickly running grep to check up on your 
theory: There is only one relay with an ORport of 25, 4 relays with 
ORport 465 and 4 relays with ORport 587. I find that interesting because 
I just remembered that my provider started dropping outgoing traffic on 
port 25 a while ago (https://www.drei.at/de/info/umstellung-port-25/) 
and I imagine there are other providers with similar (stupid) policies 
out there.


Tobias


___
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

2021-06-11 Thread Ningú

On 10/6/21 22:50, Tor Relays wrote:


On Tue, Jun 08, 2021 at 01:56:33PM +0200, Tor Relays wrote:
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.

--Roger

This would explain it when the relay in question would be an exit 
relay, but it is an ordinary relay.


Maybe it impacts your own trust level when you frequently connect to 
IPs with a bad reputation (e.g. exits).


Or maybe they flagged as suspicious the activity towards ports 9001? 
Maybe its worth the effort to debug this by only accepting tor circuits 
involving downstream relays over port 443 for some time so as to see if 
G-Core Labs whitelists you again? (No idea how to actually do this) This 
could mean an additional point to encourage people to deploy relays on 
port 443.


Also, maybe someone is running a relay on port 25/465/587/whatnot and 
that is what triggered G-Core Labs alarms? I don't know how to find this 
with relay search. Orport shows in the results but searches for 
orport:NNN will fail.



When they don't provide any information it's only speculation


That's it :(

Salut

___
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

2021-06-11 Thread Tor Relays
> 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
>

This would explain it when the relay in question would be an exit relay,
but it is an ordinary relay.

Maybe it impacts your own trust level when you frequently connect to IPs
with a bad reputation (e.g. exits).
Or they analyzed too much traffic they don't understand so they mark it
"suspicious" and when the trust level falls under some threshold their
first line of defense is blocking the SMTP ports and check back later.
Or a silent hack and the server indeed sent emails.
IP address spoofing.
A bug in Tor that allows exiting when it shouldn't.

When they don't provide any information it's only speculation and as a
customer you can't do anything but watch and keep up the security level.
___
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

2021-06-09 Thread Roger Dingledine
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


Re: [tor-relays] G-Core Labs and their humanoid robots

2021-06-09 Thread tor-opera...@urdn.com.ua
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


[tor-relays] G-Core Labs and their humanoid robots

2021-06-09 Thread Tor Relays
 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