Opened 10 years ago

Closed 10 years ago

#4371 closed Enhancement (duplicate)

DHT communication should be filtered by loaded blocklists

Reported by: x190 Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.32
Severity: Normal Keywords: DHT communication, blocklist filtering
Cc: jch@…

Description

In the current nightlies, incoming UDP messages are not processed if found to be from an address in a loaded blocklist. jch, since this is bit like locking the barn door after the horses have escaped, and also since most of us do not have the ability to use iptables to accomplish this, we need your help in filtering any potential outgoing DHT communication such as bootstrapping, node building, and announces.

We have the function in session.h! I think we just need to extract a compatible address type to pass it. :)

bool         tr_sessionIsAddressBlocked( const tr_session        * session,
                                         const struct tr_address * addr );


Change History (8)

comment:1 Changed 10 years ago by livings124

  • Cc jch@… added

comment:2 Changed 10 years ago by jch

No.

While the Kademlia algorithm is robust in the presence of a small number of rogue nodes, it fundamentally assumes transitive connectivity. In other words, either you participate in the DHT, in which case you must collaborate with all other nodes lest you endanger the integrity of the DHT, or you don't participate in the DHT at all (which you can do by disabling the DHT in the preferences).

At any rate, I want to remind people that BitTorrent? is *not* an anonymous protocol. Please remember that if you're downloading something over BitTorrent?, you broadcast this information to the tracker, to 8 DHT nodes, and to any peer you're conencted to. A manual blocklist will not help you remain anonymous. So please don't get into trouble.

-- jch

comment:3 Changed 10 years ago by jch

  • Resolution set to wontfix
  • Status changed from new to closed

comment:4 Changed 10 years ago by Username

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I will try to reopen this ticket because: while DHT is quite robust, etc, some nodes are still malicious and would expose unpleasant/weird/problematic behavior.

Some nodes would try to flood me as long as they see I'm online and dropping their incoming packets is cool, but this does not reduces traffic. As for me, I would prefer to completely abandon all traffic to and from these nodes. Once they can't have proof that I'm still online they usually abandon flood since they do not have bandwidth to flood all dead IPs of the internet.

Some nodes are clearly trying to pollute DHT tables by injecting dozens of "malicious" nodes who're clustered around very few IPs in certain datacenters. Since DHT is not meant to be supported by datacenters in this way, this is indication that they are rather trying to direct traffic to self. Maybe to attack certain hashes, etc. It's not like if this completely succeeds, but as for me I see a very little reason to communicate with corrupted nodes.

Actually, malicious nodes could attempt to shift random hashes distribution to non-random and may apply somewhat different "rules" to our "game", like only returning closest neighbours from their own cluster.

On other hand, just blocking nodes does not changed DHT properties, it's just like if those nodes died. This does not affects uniformity of hashes distribution and does not fills anyone's buckets with corrupt nodes.

Btw, you may want to see how aMule/eMule deals with DHT abuses. They have a dozen of interesting countermeasures against malicious behaviour since their DHT has been abused by anti-p2p guys a way too much.

Well, and the reason for reopening this ticket: if I told app to block traffic to certain IP, it have to obey rather than backstab me by ignoring blocklist rules in one place and obeying in others. Blocklist either blocks all traffic or this is a snake oil, regardless of anonymity, DHT integrity and other stuff.

comment:5 Changed 10 years ago by jch

Jordan, would you care to explain r12544 to me?

-- jch

comment:6 Changed 10 years ago by jordan

As the comments say, it attempts to stop processing messages from blocked IP addresses.

I agree with comment:2 but the other side to that is that if Transmission supports blocklists, it's reasonable to be consistent about that support.

My preference for solving this question would be to remove blocklists, since the only thing they're good for is a false sense of security.

comment:7 Changed 10 years ago by jordan

  • Priority changed from High to Normal

This isn't a high priority issue.

comment:8 Changed 10 years ago by jordan

  • Resolution set to duplicate
  • Status changed from reopened to closed

I'm going to close this as a duplicate of #4016 -- after talking it over with jch, there's a Transmission-level (rather than DHT-level) way of handling this.

Note: See TracTickets for help on using tickets.