Dear Nepenthes Development Team,

Do you know anything about the 55 Tor Relays called "Relay127001"? https://atlas.torproject.org/#search/Relay127001 They appeared around the 23rd of June 2016.

It looks like the relays have a self-signed HTTPS certificate called "Nepenthes Development Team" on port 443.

If you know about these relays, there are a few things you can do to help the Tor network: * let us know if the relays are doing anything other than relaying traffic * provide a ContactInfo in the torrc, typically an email address * declare the relays to be part of a family using "MyFamily fingerprint0, … fingerprint54" in the torrc

Previous discussion on the tor-relays list is below:

On 24 Jun 2016, at 16:44, simon komsat@kalidasa.klamath.ch wrote:

On 23.06.2016 22:47, yandereson@riseup.net wrote:

...

I check torstatus/atlas regularly and this was showing up : https://atlas.torproject.org/#search/Relay127001 i just thought i report it here.

I copypasted some of the IP addresses into my webbrowser's url bar to check for a dirfrontpage; but what actually shows up is "Directory listing for /" for several of them.

None of them have a DirPort, so Tor won't serve any front page. You're seeing the output from some other web server running on port 80. No identifying headers. It looks like a very basic server that serves HTML 3.2.

The HTTPS is more interesting: a self-signed "Nepenthes Development Team" certificate. It's apparently a malware collection platform that "emulates only the vulnerable parts of a service". Here's the relevant paper: https://www1.cs.fau.de/filepool/publications/collecting-malware-final.pdf

I've seen something similar for "involuntary" FTP servers before. Bonnet?

Or a honeypot. Or a series of cloned servers. It's hard to tell. But there do seem to be a large number of them, 55 in a recent consensus. And no contact info, either.

We might want to remove these relays from the network before they pick up too many more flags.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n

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 nusenu@openmailbox.org 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

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 komsat@kalidasa.klamath.ch 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

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

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

On 7/6/16, Green Dream greendream848@gmail.com 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.

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 <bad-onions> { 0.0.0.0 }

block in quick on egress from <bad-onions> to any block out quick on egress from any to <bad-onions> }}}

-- Ivan Markin

On 7/5/16, Ivan Markin twim@riseup.net 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.

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

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

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