FYI, I got this email for a non-exit relay - please share if you get them as well:
To Whom it May Concern,
You have a system on your network that is actively scanning and/or attacking external sites on the Internet. This can come from many sources and because it is often difficult to detect this activity, we are sending this E-mail in an attempt to help you solve the problem.
We have detected your system with an IP of, <relay-IP>, scanning a client we monitor. This was not a short attack but a prolonged scan and/or probe that was designed to find and intrude into the target network.
This may be someone on your network who is actively trying to hack others. This person may be a legitimate user on your network or it may be that this system has been compromised and is being used by someone to hack others. It is also likely that the system is running automated tools that have been installed to perform these actions without any human intervention.
Below is the information about the attack. Keep in mind that the source IP of our client has been sanitized for anonymity.
Date: 09/XX/2017 Time Zone: America/Chicago Source(s): relay-IP Type of Attack/Scan: Generic Hosts: <RFC1918 IP address> Log:
relay-IP:ORPort > RFC1918 IP address
Possible Cause:
Thank you for your attention to this matter,
Masergy email: esp@masergy.com mailto:esp@masergy.com
---------------
On 22 Sep 2017, at 08:49, relay 000 relay0@mailbox.org wrote:
FYI, I got this email for a non-exit relay - please share if you get them as well:
...
You have a system on your network that is actively scanning and/or attacking external sites on the Internet. This can come from many sources and because it is often difficult to detect this activity, we are sending this E-mail in an attempt to help you solve the problem.
We have detected your system with an IP of, <relay-IP>, scanning a client we monitor. This was not a short attack but a prolonged scan and/or probe that was designed to find and intrude into the target network.
There are two ways this can happen:
Someone set up a tor relay on the "client", and your relay connected to it.
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses. Specifying a remote address is a feature of the protocol. We have mitigations in place in newer tor relay versions to stop scanning of local addresses, and to provide limited information to the scanning client.
T -- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
There are two ways this can happen:
Someone set up a tor relay on the "client", and your relay connected to it.
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses. Specifying a remote address is a feature of the protocol. We have mitigations in place in newer tor relay versions to stop scanning of local addresses, and to provide limited information to the scanning client.
While the subject is not cleared, I suggest firewall rules to stop the communication between ORPort and RFC1918 ranges.
x9p
On 22 Sep 2017, at 16:41, x9p tor.relays@x9pneu.com wrote:
There are two ways this can happen:
Someone set up a tor relay on the "client", and your relay connected to it.
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses. Specifying a remote address is a feature of the protocol. We have mitigations in place in newer tor relay versions to stop scanning of local addresses, and to provide limited information to the scanning client.
While the subject is not cleared, I suggest firewall rules to stop the communication between ORPort and RFC1918 ranges.
Tor relays don't connect to RFC1918 ranges by default.
Read the man page entries for these options for more details: ExtendAllowPrivateAddresses DirAllowPrivateAddresses ExitPolicyRejectPrivate
So you could set up firewall rules, but if they're ever triggered, it's a bug, and we want to know about it.
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 22 Sep 2017, at 23:03, relay 000 relay0@mailbox.org wrote:
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses.
wow, people can misuse my *non*-exit relay to scan (aka send a TCP SYN packet) other systems on the internet?
Yes.
But please don't worry. Receiving unsolicited TCP connections is a normal part of running a server on the Internet. And anyone who sends unsolicited spammy emails in response lacks a sense of irony.
Here's how the Tor rendezvous protocol can be used like that:
People can pretend that they are a client or onion service that's connected to a particular relay address.
And then they can ask your relay to extend to that pretend relay address. There's no requirement that the relay is in the consensus that your relay has. And so your relay tries to establish a TLS connection, may or may not succeed, but definitely fails at the authentication step.
And then it tells the client it failed. Without providing much info at all. So it's pretty useless, honestly.
The alternative would be to require that every relay used in the rendezvous protocol is in the consensus. But which consensus? * the consensus that the client has * the consensus that the service has * the consensus that the relay extending to the intro point has * the consensus that the relay extending to the rend point has
It gets complicated fast.
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 ------------------------------------------------------------------------
Hi teor,
On Fri, Sep 22, 2017 at 11:14:07PM +1000, teor wrote:
On 22 Sep 2017, at 23:03, relay 000 relay0@mailbox.org wrote:
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses.
wow, people can misuse my *non*-exit relay to scan (aka send a TCP SYN packet) other systems on the internet?
Yes.
Can you clarify here that no feedback is given and that this is not a useful scan?
I assume the remote relay will return the same error whether there is something listening on the port or not, as it wasn't possible to extend the circuit.
Thanks, Iain.
On 22 September 2017 at 16:49, Iain R. Learmonth irl@torproject.org wrote:
Hi teor,
On Fri, Sep 22, 2017 at 11:14:07PM +1000, teor wrote:
On 22 Sep 2017, at 23:03, relay 000 relay0@mailbox.org wrote:
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses.
wow, people can misuse my *non*-exit relay to scan (aka send a TCP SYN packet) other systems on the internet?
Yes.
Can you clarify here that no feedback is given and that this is not a useful scan?
I assume the remote relay will return the same error whether there is something listening on the port or not, as it wasn't possible to extend the circuit.
There may be some timing difference, a faster response if the connection fails/is rejected vs if nothing is listening
Hi,
On Fri, Sep 22, 2017 at 04:52:02PM +0100, Pascal Terjan wrote:
There may be some timing difference, a faster response if the connection fails/is rejected vs if nothing is listening
Ah, I hadn't thought of that. Although I guess this would also be the case if there is congestion or a whole number of other factors?
Thanks, Iain.
On 23 Sep 2017, at 01:49, Iain R. Learmonth irl@torproject.org wrote:
Hi teor,
On Fri, Sep 22, 2017 at 11:14:07PM +1000, teor wrote:
On 22 Sep 2017, at 23:03, relay 000 relay0@mailbox.org wrote:
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses.
wow, people can misuse my *non*-exit relay to scan (aka send a TCP SYN packet) other systems on the internet?
Yes.
Can you clarify here that no feedback is given and that this is not a useful scan?
I assume the remote relay will return the same error whether there is something listening on the port or not, as it wasn't possible to extend the circuit.
Yes.
It's really much more reliable to use a Tor Exit for things like this. They're faster, and they give more detailed error messages in response.
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 ------------------------------------------------------------------------
teor teor2345@gmail.com wrote:
On 22 Sep 2017, at 23:03, relay 000 relay0@mailbox.org wrote:
Someone is using the hidden service rendezvous protocol to ask non-exit relays to scan non-tor IP addresses.
wow, people can misuse my *non*-exit relay to scan (aka send a TCP SYN packet) other systems on the internet?
Yes.
But please don't worry. Receiving unsolicited TCP connections is a normal part of running a server on the Internet. And anyone who sends unsolicited spammy emails in response lacks a sense of irony.
Here's how the Tor rendezvous protocol can be used like that:
People can pretend that they are a client or onion service that's connected to a particular relay address.
And then they can ask your relay to extend to that pretend relay address. There's no requirement that the relay is in the consensus that your relay has. And so your relay tries to establish a TLS connection, may or may not succeed, but definitely fails at the authentication step.
And then it tells the client it failed. Without providing much info at all. So it's pretty useless, honestly.
The alternative would be to require that every relay used in the rendezvous protocol is in the consensus. But which consensus?
- the consensus that the client has
- the consensus that the service has
- the consensus that the relay extending to the intro point has
- the consensus that the relay extending to the rend point has
It gets complicated fast.
There's another, more obvious reason, I think, than hidden services. Consider what happens during relay startup. The initializing relay attempts to build a number of circuits that connect back to itself for reachability and data rate testing, yet its descriptor may well not be in any relay's cached-descriptor* files, much less in either consensus document.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
tor-relays@lists.torproject.org
-
Iain R. Learmonth -
Pascal Terjan -
relay 000 -
Scott Bennett -
teor -
x9p