Re: [tor-relays] suspicious "Relay127001" relays
simon:
> As I see it, removing via directory authority consensus is still the
> cleaner way, especially in a case of ~100 similar nodes.
>
> What came to my mind was something like a bugtracker for bad nodes.
Yes, but it's too crafty and should be done by hand. Doing so is error
prone/unstable/complicated/unscalable if there is no algorithms to seed
sybils out (like ones by Philipp Winter et. al.) in automatic manner
integrated into DirAuths.
> This way, all node operators can file suspicious nodes to be excluded,
> which achieves more than blacklisting on their tiny fraction of the network.
> It would introduce more transparency because relay operators can
> actually see someone is working on getting a dir auth consensus and get
> status updates; or at least there is a discussion why there won't be any
> blocking.
As any reporting this can open new attack surface for 'report sybils'
who report against some relays to influence path selection.
With peering policy, I see it like relay operator can decide that they
do accept ('accept' policy) only 'this-group-of-relays' and nothing
more. In case when a new group of sybils appears it cannot be used with
the relay. It raises diversity in the network. So if something goes
wrong with global or fenced 'part' of the network, it can have less
damage since not all relays are affected.
It's more like not all relays on the Tor network are exits. And it's for
a reason, e.g. one can get into a legal trouble for running an Exit node
in some countries but everything is fine without exiting there.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On 06.07.2016 15:50, Ivan Markin wrote: > The introduction of peering policy definitely solves this issue in a > transparent and harmless way. Filed a ticket #19625 [1] to move this > discussion > there. On 06.07.2016 14:56, Roger Dingledine wrote: > Speaking of which, a while ago I started a discussion of how to > streamline that process: > https://trac.torproject.org/projects/tor/ticket/16558 As I see it, removing via directory authority consensus is still the cleaner way, especially in a case of ~100 similar nodes. What came to my mind was something like a bugtracker for bad nodes. This way, all node operators can file suspicious nodes to be excluded, which achieves more than blacklisting on their tiny fraction of the network. It would introduce more transparency because relay operators can actually see someone is working on getting a dir auth consensus and get status updates; or at least there is a discussion why there won't be any blocking. Lastly, it would prevent partitioning attacks or similar in contrast to per-node blacklisting. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
s7r: > The path of a circuit is selected by the client (i.e. user). So, > each and every relay / bridge, in order to be considered a valid one, > should be able to extend a circuit when requested to any other > relay, otherwise everything gets broken. So does everything break if there are connectivity issues? E.g. route leakage, country "border" blocking policy, filtering, traffic throttling, bad cabling... Relay operators do not have control over their upstream providers and the Internet routing (in most cases). > Setting this locally at relay side, with no way for the applied > change to reach the Tor client (user) will have terrible usability > effects. Is it supposed to be this way? I guess the whole scheme should be more fault-tolerant for such common network issues. Actually I've never seen any noticeable disruptions when some of my bridges were down or faulty. > Trying to come up with a way so that Tor clients / users can learn > about such changes will over complicate everything with no benefits > and additional attack surface. > By design the only clean way to deal with bad relays is to exclude > them from consensus, a consensus that everyone uses, change applied > only at directory authorities side -- this is why we use the > consensus majority system which is well studied and understood as > opposite to other more decentralized solutions. Yeah, agreed. This issue has to be researched rigorously (see #19625) and we should stick with things that we know for sure. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On 7/6/2016 4:50 PM, Ivan Markin wrote: > Andreas Krey: >> That will cause issues for everyone that happens to select your >> relay and the 'blocked' relays in a circuit - the connections will >> just fail, and the user will wonder what happened, and why TBB >> doesn't work. > > Sure, I made a notice that you shouldn't do it if you care about the > users (may be it was vague): >> [Note also, that it makes performance poorer compared to the case >> when it's defined by policy] Why will you be running a relay if you don't care about the users? Seriously now. The path of a circuit is selected by the client (i.e. user). So, each and every relay / bridge, in order to be considered a valid one, should be able to extend a circuit when requested to any other relay, otherwise everything gets broken. Setting this locally at relay side, with no way for the applied change to reach the Tor client (user) will have terrible usability effects. Trying to come up with a way so that Tor clients / users can learn about such changes will over complicate everything with no benefits and additional attack surface. By design the only clean way to deal with bad relays is to exclude them from consensus, a consensus that everyone uses, change applied only at directory authorities side -- this is why we use the consensus majority system which is well studied and understood as opposite to other more decentralized solutions. signature.asc 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] suspicious "Relay127001" relays
Andreas Krey: > That will cause issues for everyone that happens to select your > relay and the 'blocked' relays in a circuit - the connections will > just fail, and the user will wonder what happened, and why TBB > doesn't work. Sure, I made a notice that you shouldn't do it if you care about the users (may be it was vague): > [Note also, that it makes performance poorer compared to the case > when it's defined by policy] grarpamp: > If it's deemed that relay operators should have local policies such > as "ExcludePeerRelays", try discussing towards a ticket for that > instead. The introduction of peering policy definitely solves this issue in a transparent and harmless way. Filed a ticket #19625 [1] to move this discussion there. Sebastian Hahn: > This is a good way to get marked as a bad relay. Please never > actually do this on a relay in the Tor network. Curious, never knew that. Could you please send a link or whatever that explains how this marking/detection works? By the way, the only way to 'mark relay as bad' I know is to assign BadExit flag (but it's only for exits). Is there something else? [1] https://trac.torproject.org/projects/tor/ticket/19625 Thanks, -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On Tue, Jul 05, 2016 at 10:00:22PM -0700, Green Dream wrote: > So... what's going on in this particular case and what are the directory > authorities going to do, if anything? Yesterday we started the move towards blocking them. (The move takes a little while, since it needs a sufficient fraction of directory authority operators to do it.) Specifically, it looks like 3 of the dir auths have moved to reject them, and I hear a 4th will be doing it soon, and that should be sufficient. Speaking of which, a while ago I started a discussion of how to streamline that process: https://trac.torproject.org/projects/tor/ticket/16558 but it remains unclear whether that idea is a good one or a bad one. > As a relay operator near the top of the CW list, I continue to be somewhat > uncomfortable with the lack of transparency regarding the directory > authority decisions. It would be nice if the decision making process around > these types of events was a bit more transparent. First, thanks for running a relay! Second, I agree about the transparency side. Part of our challenge is that the directory authority operators, like everybody else in Tor-land, are overloaded. But that by itself is no excuse. The bigger problem is that identifying and bumping out bad relays is an inherently unbalanced situation -- unbalanced in favor of the bad relays. See https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html for more discussion on this point. I wonder if there's a good balance we can strike, e.g. where we make it clear to the world when we decided to bump out a set of relays, since those relays are going to figure it out themselves soon enough? In this case we actually found these relays misbehaving (accessing onion addresses that they learned about), and maybe that detail is reassuring to some people, but again that arms race for noticing misbehaving HSDirs is a really crummy one from our perspective. (See also the upcoming hotpets and defcon talks by Guevara Noubir et al.) --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On 7/6/16, Green Dream wrote: >> It's up to directory authority operators to deal with >> suspicious/rogue/misconfigured relays by marking them as >> invalid/rejected/badexit. > > So... what's going on in this particular case and what are the directory > authorities going to do, if anything? > > As a relay operator near the top of the CW list, I continue to be somewhat > uncomfortable with the lack of transparency regarding the directory > authority decisions. It would be nice if the decision making process around > these types of events was a bit more transparent. Every posted and confirmed traffic manipulating / abusive bad relay gets banned, just see any prior report on this list and they should all still be gone. Even highly suspicious sets of relays that get posted, like tens of anon nodes / bots all popping up at once end up being banned, again check prior reports. People confirming on tor-relays etc can take a while, or they're just busy. There are a couple pages dealing with bad exits / relays on the wiki. If suspect relays are found, reports seem forgotten, or banned relays return, please [re]post it for others to follow up on. You can bet the 90+ popup set in the subject will be banned real soon now. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On Wed, 06 Jul 2016 02:29:00 +, Ivan Markin wrote: ... > But you're still able to restrict connections with these nodes using > plain blocking at your firewall. So circuits through these relays are > not able to be built anymore. That will cause issues for everyone that happens to select your relay and the 'blocked' relays in a circuit - the connections will just fail, and the user will wonder what happened, and why TBB doesn't work. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On 7/5/16, Ivan Markin wrote: >> blacklist hosts individually (unless I'm putting them into MyFamily, That could 3rd party backfire against your relay, and must be mutual in the consensus anyway. So don't. > AFAIK, there is no option in tor itself to exclude relays from the routing. > > But you're still able to restrict connections with these nodes using > plain blocking at your firewall. So circuits through these relays are > not able to be built anymore. That will seriously break tor, and get your relay banned for it. So don't. If it's deemed that relay operators should have local policies such as "ExcludePeerRelays", try discussing towards a ticket for that instead. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
> On 06 Jul 2016, at 04:29, Ivan Markin wrote:
>
> simon:
>> If I understood the documentation correctly, as a node operator I can't
>> blacklist hosts individually (unless I'm putting them into MyFamily,
>> which I don't want to).
>
> AFAIK, there is no option in tor itself to exclude relays from the routing.
>
> But you're still able to restrict connections with these nodes using
> plain blocking at your firewall. So circuits through these relays are
> not able to be built anymore. [Note also, that it makes performance
> poorer compared to the case when it's defined by policy].
>
> In case of PF it looks like:
>
> {{{
> table { 0.0.0.0 }
>
> block in quick on egress from to any
> block out quick on egress from any to
> }}}
This is a good way to get marked as a bad relay. Please never
actually do this on a relay in the Tor network.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
simon:
> If I understood the documentation correctly, as a node operator I can't
> blacklist hosts individually (unless I'm putting them into MyFamily,
> which I don't want to).
AFAIK, there is no option in tor itself to exclude relays from the routing.
But you're still able to restrict connections with these nodes using
plain blocking at your firewall. So circuits through these relays are
not able to be built anymore. [Note also, that it makes performance
poorer compared to the case when it's defined by policy].
In case of PF it looks like:
{{{
table { 0.0.0.0 }
block in quick on egress from to any
block out quick on egress from any to
}}}
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
> It's up to directory authority operators to deal with > suspicious/rogue/misconfigured relays by marking them as > invalid/rejected/badexit. So... what's going on in this particular case and what are the directory authorities going to do, if anything? As a relay operator near the top of the CW list, I continue to be somewhat uncomfortable with the lack of transparency regarding the directory authority decisions. It would be nice if the decision making process around these types of events was a bit more transparent. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
> In good news, 91 new high speed exits means Tor network should be > truly blazing for a while :) these are non-exits relays (currently) currently 93 relays (89 running): https://gist.githubusercontent.com/nusenu/0478362226f1b74744bec8700c4a3732/raw/e8a5ed82061a2b6a83f982964794ef79c067f005/Relay127001_93-relays_2016-07.txt a few total stats for these relays: 58 unique /16 netblocks 26 unique ASes (20 unique organizations) aggregated CW fraction: 0.1529% (as of 2016-07-05 22:00) (if that doesn't tell you much, that is about at the 99th position of the current CW ranking list but that is anything but static https://raw.githubusercontent.com/ornetstats/stats/master/o/main_operators_by_cw.txt ) signature.asc 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] suspicious "Relay127001" relays
On Tue, Jul 05, 2016 at 05:10:49PM +0200, Niklas K. wrote: > It's up to directory authority operators to deal with > suspicious/rogue/misconfigured relays by marking them as > invalid/rejected/badexit. > > Relay operators are not supposed to decide what other relays they may be put > in a circuit with (apart from notifying the network which nodes belong to the > same operator using MyFamily as you mention). > > FYI, *clients* do have the ability to exclude nodes using the ExcludeNodes > directive. In good news, 91 new high speed exits means Tor network should be truly blazing for a while :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
It's up to directory authority operators to deal with suspicious/rogue/misconfigured relays by marking them as invalid/rejected/badexit. Relay operators are not supposed to decide what other relays they may be put in a circuit with (apart from notifying the network which nodes belong to the same operator using MyFamily as you mention). FYI, *clients* do have the ability to exclude nodes using the ExcludeNodes directive. On 5 July 2016 16:46:18 CEST, simon wrote: >On 05.07.2016 13:31, Xza wrote: >> 91 at the moment and they will soon gain more flags. >> https://sourceforge.net/p/nepenthes/wiki/Home/ >> Seems like some sort of honeypot. >> Most seem to be from AWS & Linode & Leaseweb USA. > >How does the process work to exclude nodes from the network? > >If I understood the documentation correctly, as a node operator I can't >blacklist hosts individually (unless I'm putting them into MyFamily, >which I don't want to). >___ >tor-relays mailing list >tor-relays@lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On 05.07.2016 13:31, Xza wrote: > 91 at the moment and they will soon gain more flags. > https://sourceforge.net/p/nepenthes/wiki/Home/ > Seems like some sort of honeypot. > Most seem to be from AWS & Linode & Leaseweb USA. How does the process work to exclude nodes from the network? If I understood the documentation correctly, as a node operator I can't blacklist hosts individually (unless I'm putting them into MyFamily, which I don't want to). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
91 at the moment and they will soon gain more flags. https://sourceforge.net/p/nepenthes/wiki/Home/ Seems like some sort of honeypot. Most seem to be from AWS & Linode & Leaseweb USA. On July 3, 2016 10:59:00 AM GMT+02:00, nusenu wrote: >some new ones: >http://article.gmane.org/gmane.network.onion-routing.ornetradar/1468 > > > > > > >___ >tor-relays mailing list >tor-relays@lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- PGP : 29A4CE52___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
some new ones: http://article.gmane.org/gmane.network.onion-routing.ornetradar/1468 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
