As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node. Prior to today I'd receive on average 1-2 complaints a month (I had a fairly strict exit policy). It saddens me that I have to shut it down, especially as it's one of very few running on BSD, but I just don't have the time to constantly respond to abuse complaints to ensure I don't get shut down by the upstream provider. If there are any devs on this list, some kind of mechanism to detect and block abuse traffic on exit would go a long way to ensuring legitimate use of the network, that is after all why people run exit nodes. It's at least why I did.
Thank you to everyone else running an exit node. I hope you're able to keep yours going for a lot longer than I.
James
Hi James,
Have you considered running a super restrictive exit policy? I had the same trouble you have, with EFF's restrictive exit policy. So I wrote my own, which also blocks port 80:
ExitPolicy accept *:443 ExitPolicy accept *:6667 ExitPolicy accept *:7000 ExitPolicy accept *:5222 ExitPolicy accept *:5223 ExitPolicy accept *:110 ExitPolicy accept *:143 ExitPolicy accept *:220 ExitPolicy accept *:993 ExitPolicy accept *:995 ExitPolicy accept *:9418 ExitPolicy accept *:53 ExitPolicy reject *:*
Now I deal with maybe 1 complaint per quarter. And since 443 is still in there, it's still contributing substantially to the network (maybe more so than with port 80 enabled).
Consider giving it a try ;-)
Tom
Op 04/12/2017 om 11:59 schreef James:
As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node. Prior to today I'd receive on average 1-2 complaints a month (I had a fairly strict exit policy). It saddens me that I have to shut it down, especially as it's one of very few running on BSD, but I just don't have the time to constantly respond to abuse complaints to ensure I don't get shut down by the upstream provider. If there are any devs on this list, some kind of mechanism to detect and block abuse traffic on exit would go a long way to ensuring legitimate use of the network, that is after all why people run exit nodes. It's at least why I did.
Thank you to everyone else running an exit node. I hope you're able to keep yours going for a lot longer than I.
James
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 4 Dec 2017, at 22:18, Tom van der Woerdt info@tvdw.eu wrote:
Hi James,
Have you considered running a super restrictive exit policy? I had the same trouble you have, with EFF's restrictive exit policy. So I wrote my own, which also blocks port 80:
ExitPolicy accept *:443 ExitPolicy accept *:6667
A restricted exit policy is a good idea, but Exits must include port 80. (If they don't, they will mainly be used as guard and middle relays.)
Blocking port 80 isn't safe for users: it doubles the number of exits that they must use, which doubles their risk of a malicious exit.
So, when directory authorities update to 0.3.2, they will only vote Exit for relays that allow both port 80 and 443.
Background: https://trac.torproject.org/projects/tor/ticket/23637
T
On Mon, Dec 4, 2017 at 12:39 PM, teor teor2345@gmail.com wrote:
Blocking port 80 isn't safe for users: it doubles the number of exits that they must use, which doubles their risk of a malicious exit.
The risk of using port 443 is much lower than the risk of using port 80, because information passed through 443 port is normally encrypted and authenticated.
How does the number of exits being affect the risk for users (given only 443 port is used)? IIUC the more servers the better, because harder to spy on a significant part of them.
I was only allowing 80 and 443 anyway.
https://atlas.torproject.org/#details/7723B1B4B2B4D9D161209F770079A6F0A5A929...
J
I so far have got away with no abuse with quite a wide range of ports open, avoiding obvious abuse ports and only allowing port 80 to a single Class A, chosen belonging to a benign country/service: x.x.x.x/8:80 Gets the server listed as an exit. I have not seen, via arm, anyone use port 80 as an exit, but exit on 443 and the other open ports are used a lot.
Perhaps my ISP is eating the abuse. I doubt it
Gerry
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Nagaev Boris Sent: 04 December 2017 12:58 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] So long and thanks for all the abuse complaints
On Mon, Dec 4, 2017 at 12:39 PM, teor teor2345@gmail.com wrote:
Blocking port 80 isn't safe for users: it doubles the number of exits that they must use, which doubles their risk of a malicious exit.
The risk of using port 443 is much lower than the risk of using port 80, because information passed through 443 port is normally encrypted and authenticated.
How does the number of exits being affect the risk for users (given only 443 port is used)? IIUC the more servers the better, because harder to spy on a significant part of them.
-- Best regards, Boris Nagaev _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Op 04/12/2017 om 13:39 schreef teor:
On 4 Dec 2017, at 22:18, Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu> wrote:
Hi James,
Have you considered running a super restrictive exit policy? I had the same trouble you have, with EFF's restrictive exit policy. So I wrote my own, which also blocks port 80:
ExitPolicy accept *:443 ExitPolicy accept *:6667
A restricted exit policy is a good idea, but Exits must include port 80. (If they don't, they will mainly be used as guard and middle relays.)
Blocking port 80 isn't safe for users: it doubles the number of exits that they must use, which doubles their risk of a malicious exit.
So, when directory authorities update to 0.3.2, they will only vote Exit for relays that allow both port 80 and 443.
Background: https://trac.torproject.org/projects/tor/ticket/23637
T
Sorry to hear that :-( Guess I'll also have to stop running my exit, then.
Tom
On 04.12.17 11:59, James wrote:
As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node.
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days. I can understand that they are pissed off, and the whole thing resulted in this particular exit being shut down by the hoster. If I could detect and prevent these scans, it would go a long way to avoid having my exit nodes shut down by hosting services.
-Ralph
On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 04.12.17 11:59, James wrote:
As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node.
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days. I can understand that they are pissed off, and the whole thing resulted in this particular exit being shut down by the hoster. If I could detect and prevent these scans, it would go a long way to avoid having my exit nodes shut down by hosting services.
With my exit node operator hat on, I too would like to see some sort of port-scanning prevention built into the network. In my case, I had to turn off exiting to the SSH port because we were getting daily complaints about abusive scanning for devices with weak admin passwords. Which is a shame, since there are plenty of legitimate uses for SSH-over-Tor.
The tricky part is designing some sort of exit-node-controlled new-connection rate limiting that's content-blind and won't interfere with legitimate uses. And "legitimate uses" include things like a web browser generating a burst of TCP connections to the same HTTP/1.1 server cluster, exitmap connecting to the same test server repeatedly via every exit node in the network, and so on. I would want to see any proposal document include a long list of known non-abusive traffic scenarios and an argument that the mechanism would not interfere with each.
zw
Zack Weinberg wrote:
On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 04.12.17 11:59, James wrote:
As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node.
Thanks for running the exit and I am sorry you took the decision to shut it down. However, 4th abuse complaint in few days is really not a big deal, I could say I swim in such reports, but then again it's up to each and every one when to stop.
What I want to point out is a HUGE difference between:
1. *Abuse Reports* aka *Serious complaints*, those that are addressed directly and formally, sent by a human, and explicitly require action or at least reply with explanation. These are very rare.
2. *Junk NOTIFICATIONS* aka *WARNINGS* aka *Simple Notifications to safely ignore*, those that are not addressed formally ("to whomever it may concern..."), are sent by bots or automated scripts (firewalls, intrusion systems, fail2ban, etc) which simply run a whois on an IP address and bomb the abuse mailbox with spam, most sent from addresses that even if a reply is sent the message is discarded - these DO NOT require action nor reply. These are the 99% ones.
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days. I can understand that they are pissed off, and the whole thing resulted in this particular exit being shut down by the hoster. If I could detect and prevent these scans, it would go a long way to avoid having my exit nodes shut down by hosting services.
This is just a defective policy of that hoster. If a hoster goes mad because it receives some useless junk notifications, that is not much of a hoster. The first problem is that one who feels port-scanned or probed needs to implement defenses at their end, not bomb with automated spam messages everyone that is connecting to them. You cannot rely on everyone else doing something in order to ensure your security when you can implement protections for yourself.
A large exit node (big consensus weight) is almost guaranteed a false positive to trigger such a dumb warning system, even in legitimate cases where simply more users pick it as Exit and the service (end point) is popular.
With my exit node operator hat on, I too would like to see some sort of port-scanning prevention built into the network. In my case, I had to turn off exiting to the SSH port because we were getting daily complaints about abusive scanning for devices with weak admin passwords. Which is a shame, since there are plenty of legitimate uses for SSH-over-Tor.
I agree it's annoying but it is very hard to implement port-scanning prevention directly in Tor especially because new connections should not be distinguishable if they come from the same user or multiple users. The exit relay should have no definition about this, otherwise you have to go deeper into streams attached to each circuit which is totally different. This will be over-engineering with absolutely no gains because someone that wants to abuse simply does not care about the network and will just keep port-scanning with isolated requests / different circuits (might be slower, but still work) and will consume even more resources in the network.
I don't think this is the way to go, under any circumstances. Better to learn to make difference between junk notification and serious reports that require action or reply.
On 04.12.2017 19:00, s7r wrote:
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days.
This is just a defective policy of that hoster. If a hoster goes mad because it receives some useless junk notifications, that is not much of a hoster.
This is not about third party X complaining to the hoster about their network being scanned. The hoster itself is automatically monitoring all their machines for outgoing network scans, as these scans are prohibited by their terms of use. If an outgoing scan is detected, the hoster sends log excerpts to the "offending" customer, and if it happens repeatedly over a longer period, the scan's source server is automatically prevented from opening further outbound connections that match this pattern. Getting these restrictions lifted unfortunately requires a lot of time and energy. :-P
-Ralph
Hi,
On 04/12/17 18:19, Ralph Seichter wrote:
This is not about third party X complaining to the hoster about their network being scanned. The hoster itself is automatically monitoring all their machines for outgoing network scans, as these scans are prohibited by their terms of use.
I do wonder how much of this is related to the scarcity of IPv4 address space, prevalence of reputation systems and fear of ending up being labeled as "bad". When we move to IPv6, perhaps hosting providers would be more relaxed knowing that it doesn't matter so much if a /64 or even a /56 ends up bad in a reputation system, because for other customers you have other address space.
Thanks, Iain.
On 04.12.17 20:00, Iain Learmonth wrote:
I do wonder how much of this is related to the scarcity of IPv4 address space, prevalence of reputation systems and fear of ending up being labeled as "bad".
I remember that last year I was notified by said hoster that the IP address of one of my exit nodes had ended up on a blacklist and that I was expected to get the address off that list. Turns out the exit had made connections to a sinkhole address not yet listed with tornull.org.
This hoster obviously keeps track of the reputations of the IP addresses assigned to customers' servers. I imagine you are correct to assume that prohibiting outbound network scans has a similar motivation. Also, scans consume resources and hence cost money.
-Ralph
On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 04.12.17 11:59, James wrote:
As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node.
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days. I can understand that they are pissed off, and the whole thing resulted in this particular exit being shut down by the hoster. If I could detect and prevent these scans, it would go a long way to avoid having my exit nodes shut down by hosting services.
With my exit node operator hat on, I too would like to see some sort of port-scanning prevention built into the network. In my case, I had to turn off exiting to the SSH port because we were getting daily complaints about abusive scanning for devices with weak admin passwords. Which is a shame, since there are plenty of legitimate uses for SSH-over-Tor.
The tricky part is designing some sort of exit-node-controlled new-connection rate limiting that's content-blind and won't interfere with legitimate uses. And "legitimate uses" include things like a web browser generating a burst of TCP connections to the same HTTP/1.1 server cluster, exitmap connecting to the same test server repeatedly via every exit node in the network, and so on. I would want to see any proposal document include a long list of known non-abusive traffic scenarios and an argument that the mechanism would not interfere with each.
Previous proposals have become bogged down in the process of trying to define "abuse".
Let's limit excessive use of scarce resources instead. It should have a similar effect, is easily made content-neutral, and doesn't require any agreed definition of legitimate and illegitimate uses.
Here's a quick sketch of a proposal - I would be happy to work with others to turn it into a Tor proposal and post it to tor-dev@. Here's what Tor proposals look like: https://gitweb.torproject.org/torspec.git/tree/proposals
Background:
Relays currently have token buckets that limit the number of bytes that can be sent per second. This limits relay bandwidth, but does not limit the use of other scarce resources, like file descriptors, TCP ports, and CPU time. (There is an existing file descriptor limit, but it is an absolute maximum, not a rate limit.)
Proposal:
We define relay-wide token buckets for circuit and stream creation. These token buckets are refilled on a regular basis. Every time a circuit or stream is created, a token is removed from the bucket. When the bucket is empty, the relay takes some action that slows down circuit or stream creation. (This could be a delay until the next refill, a randomised delay, or some more sophisticated exponential backoff system.)
We set these limits at default values that are unlikely to be exceeded during normal exit usage. (This needs measurement on live exits.)
This provides operators with tools to limit excessive usage, while we work on more fine-grained solutions.
Alternatives:
We could also define a stream limit per circuit, destination IP address, or destination port. However, this may be a level of complexity which we don't need. It also significantly increases the number of buckets required to implement the scheme. And it moves away from the original goal of limiting resource usage towards a scheme that allocates these resources more fairly between competing circuits or destinations. Designing a fairness scheme like this requires more research, including more sophisticated data collection on live exits.
There are also privacy concerns inherent in storing destination IP addresses and ports which would have to be addressed.
On 5 Dec 2017, at 06:00, Iain Learmonth irl@torproject.org wrote:
On 04/12/17 18:19, Ralph Seichter wrote: This is not about third party X complaining to the hoster about their network being scanned. The hoster itself is automatically monitoring all their machines for outgoing network scans, as these scans are prohibited by their terms of use.
I do wonder how much of this is related to the scarcity of IPv4 address space, prevalence of reputation systems and fear of ending up being labeled as "bad". When we move to IPv6, perhaps hosting providers would be more relaxed knowing that it doesn't matter so much if a /64 or even a /56 ends up bad in a reputation system, because for other customers you have other address space.
Tor already supports exiting over IPv6, and Tor Browser prefers IPv6 by default. Now we need Exit operators and major websites to enable IPv6.
I suspect the IP reputation space may take a few years to catch up with IPv6 - we should take advantage of that as much as we can.
T
On Mon, Dec 4, 2017 at 1:00 PM, s7r s7r@sky-ip.org wrote:
Zack Weinberg wrote:
With my exit node operator hat on, I too would like to see some sort of port-scanning prevention built into the network. In my case, I had to turn off exiting to the SSH port because we were getting daily complaints about abusive scanning for devices with weak admin passwords. Which is a shame, since there are plenty of legitimate uses for SSH-over-Tor.
...
I don't think this is the way to go, under any circumstances. Better to learn to make difference between junk notification and serious reports that require action or reply.
For the record, those daily complaints about abusive SSH scanning were serious reports requiring a reply. And they were not all from the same source.
zw
Zack Weinberg:
On Mon, Dec 4, 2017 at 1:00 PM, s7r s7r@sky-ip.org wrote:
Zack Weinberg wrote:
With my exit node operator hat on, I too would like to see some sort of port-scanning prevention built into the network. In my case, I had to turn off exiting to the SSH port because we were getting daily complaints about abusive scanning for devices with weak admin passwords. Which is a shame, since there are plenty of legitimate uses for SSH-over-Tor.
...
I don't think this is the way to go, under any circumstances. Better to learn to make difference between junk notification and serious reports that require action or reply.
For the record, those daily complaints about abusive SSH scanning were serious reports requiring a reply. And they were not all from the same source.
I realize this issue of SSH brute forcing via exit nodes is old news, but what is remarkable to me is that:
1. anyone cares about SSH brute force attacks if they are using keys and passwords for SSH authentication
2. who in the world has the time to investigate SSH brute force attacks, and if they do, maybe they had enough time to notice that it was from a Tor exit IP?
/rant
g
On Mon, Dec 04, 2017 at 01:55:56PM -0500, Zack Weinberg wrote:
:For the record, those daily complaints about abusive SSH scanning were :serious reports requiring a reply. And they were not all from the :same source.
The only reply ever required is a form letter stating this is a Tor exit, here's a link to how to block tor exits if that's what you want.
Our standard response is:
---
Hello,
The source address 128.31.0.13 is a Tor exit node, and is not the origin point for the traffic in question. See http://tor-exit.csail.mit.edu (which is the host in your logs) for details. Any action taken on this node would simply result in the problem traffic using a different exit.
For further information please read http://tor-exit.csail.mit.edu/ the bottom of this page includes information on how to block all Tor exits should you wish to do so (including links to get a list of all current Tor exits).
Sincerely, The Infrastructure Group MIT Computer Science and Artificial Intelligence Laboratory
---
Very few people enguage in further discussion (like <1 per year).
-Jon
On Mon, Dec 04, 2017 at 02:57:25PM -0500, Jonathan Proulx wrote:
:The only reply ever required is a form letter stating this is a Tor :exit, here's a link to how to block tor exits if that's what you want.
I recognize this doesn't help with "meta-complaints" from hosting providers, but has worked very well with direct complaints.
-Jon
Quoting myself:
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days.
I had the former exit node unlocked an ran it in relay mode for a day. Today I switched back to exit mode, and a few hours after the exit flag was reassigned, I already received the next complaint about an outgoing network scan. The logs sent to me clearly confirm scans taking place, this is not about the hoster being obstinate.
Looks like I will have to shut down this particular exit for good if I cannot find a way to prevent it from being abused as network scan central. :-(
-Ralph
Port scans are part of internet life in my opinion. One cannot have internet access and no (occasional) port scan, spam mails, worms, ... Having servers on-line and complaining about such things is just unreasonable and laziness on the operator side: don't want scans, then setup proper firewall rules. Done.
Just a "food for thought": how does one distinguishes between slow port scan (as is possible with for example nmap) and actual connection attempts?
Regards
On Tue, 5 Dec 2017 at 17:38 Ralph Seichter m16+tor@monksofcool.net wrote:
Quoting myself:
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days.
I had the former exit node unlocked an ran it in relay mode for a day. Today I switched back to exit mode, and a few hours after the exit flag was reassigned, I already received the next complaint about an outgoing network scan. The logs sent to me clearly confirm scans taking place, this is not about the hoster being obstinate.
Looks like I will have to shut down this particular exit for good if I cannot find a way to prevent it from being abused as network scan central. :-(
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 05.12.17 19:24, r1610091651 wrote:
Having servers on-line and complaining about such things is just unreasonable and laziness on the operator side: don't want scans, then setup proper firewall rules. Done.
Your comment is not applicable in this particular case; please read my other messages in this thread to see why.
-Ralph
I think it is relevant.
There are two sides to creating a connection and traffic can be filtered on both ends. On the initiator: any invalid outgoing packets can be filtered On the receiver: any not expected / invalid packets can be filtered
Just a question: how can the hoster determine whether a packet is part of a port scan or valid connection request? Unless the packet is mangled/invalid (ex: out of sequence like fin / syn scan) it can't as it is unaware what services are running at the other end. Effectively what the hoster is also doing, is imposing a rate limit on rate and number of connections.
On Tue, 5 Dec 2017 at 19:51 Ralph Seichter m16+tor@monksofcool.net wrote:
On 05.12.17 19:24, r1610091651 wrote:
Having servers on-line and complaining about such things is just unreasonable and laziness on the operator side: don't want scans, then setup proper firewall rules. Done.
Your comment is not applicable in this particular case; please read my other messages in this thread to see why.
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 05.12.17 20:21, r1610091651 wrote:
how can the hoster determine whether a packet is part of a port scan or valid connection request?
One common example of automatically detectable port scans for /24 IPv4 subnets are consecutive connections, in a small amount of time, to
aaa.bbb.ccc.1:80 aaa.bbb.ccc.2:80 aaa.bbb.ccc.3:80 [etc.]
Looking at the logs I received, this traversal of subnets to find open ports is the most common type of scan for which my exit is being abused.
The logs sometimes show variations like scanning odd-numbered addresses in one pass and even-numbered in the next, or scans for several subnets mixed together, but the hoster's monitoring software is quite good at automatically identifying patterns.
-Ralph
Hello,
Thanks to everyone that operates relays and jungles with the abuse complains. Indeed is a very cumbersome approach and people are getting easily/hard frustrated but at some point people are unfortunately decide that cannot operate any more these relays.
From personal experience it really varies from ISP to ISP network and quite often many administrators and NOCs suspend or terminate the network services for a specific server, VM, device when they see abuse alerts even if there are automated (quite often SPAM) email reports.
Suggestions: Do you think that it makes sense to co-ordinate and post a blog about the abuse reports, some countermeasures and explanations on why people should _perhaps_ not freak out when they receive automated abuse emails?
Going a bit further we can categorize and catalog common automatic abuse emails sent to relays operators and a short explanation of this was counteracted. I'm sure there will be a website that does collect general ISP abuse emails but not only related to Tor relays. Some trac wiki pages were we may integrate this information to: https://www.torservers.net/wiki/abuse/templates https://trac.torproject.org/projects/tor/wiki/OperatorsTips https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs https://trac.torproject.org/projects/tor/wiki/doc/ISPCorrespondence
Cheers, ~Vasilis
tor-relays@lists.torproject.org
-
Dr Gerard Bulger -
George -
Iain Learmonth -
James -
Jonathan Proulx -
Nagaev Boris -
r1610091651 -
Ralph Seichter -
s7r -
teor -
Tom van der Woerdt -
Vasilis -
Zack Weinberg