forum.bittorrent.org

Fredrik Neij

Member

DHT Hacking and Security

Me and a few others have been abusing, hacking and doing all the stuff you are not supposed to do with DHT, it turns out it's scary, it's almost at the state SMTP was at in the early days of the 90s, aka wide open for abuse.

It turns out you can use DHT enabled clients for all sorts of stuff, like using them as an amplifier to a DDoS, as well as an initiators, and even worse you could easily disrupt the established pseudo network.

We have discovered alot of stuff you can use the DHT network to that it were never intended to be used for.

We found alot of data pointing to that well funded abusive operations, such as governments (like Iran or China) or lobby organizations could easily cause, at least at the info_hash level (or at least the first 32bits), globally, entirely or partially disruptions of the DHT network operations.

Is there a secure invite-only place to discuss this, before too many others discovers the abuse potential of the current state of the HUGE resource that the DHT network is, and could become in the hands of abusers.

With the amount DHT enabled clients rapidly growing, and by far overshadows any malicious network in numbers, the security issues should be taken care of before someone that is not all that friendly discovers this potential.

But all the problems and way to abuse them, should defiantly not be discussed in public until there is a solution all can agree on.

Any ideas suggestions, or maybe there is other groups already looking in to this, do you need input, we are doing some weird stuff I bet you never tough of.

// Fredrik

The 8472

Azureus Developer

Re: DHT Hacking and Security

As requested, I created an appropriate section for such discussions.

Though most security flaws of the DHT are quite obvious and have already been pointed out in IRC discussions, so they're not really secret.

---

Az dev

Choy Kloun

Member

Re: DHT Hacking and Security

What I'd like to do is a good study of certain saboteurs of free information exchange that are known to harass P2P services. Didn't Fredrik have some data on them? We should set up a couple of logging nodes at strategic "locations" in DHT and see what turns up.

Certain of the current DHT deficiencies may very well be positive when it comes to chasing certain elements away from messing with DHT. :-)

And having some monitoring established should also give a good early warning if someone starts to do nasty things to the actual DHT structure. It could even be possible to do automated counter-measures for certain kinds of misbehavior.

As DHT is today I would compare it to Usenet/NNTP. Maybe DHT needs its own equivalency of cancelbots ... ?

There are some fixes that can be implemented in the current clients without breaking compatibility though. I'll play around a bit using my DHT implementation.

However - I must add that there is one issue that needs to be dealt with ASAP, and that's the various possibilities for DDoS amplification / generation. The millions of active BT clients with DHT support can pose a very real threat to the rest of the Net. Not to mention what widespread attacks and the following publicity would do for the future of BT.
I can tell from personally defending against them that the existing amplified DDoS attacks, such as those using DNS, are very real and amongst the more difficult to defend against. And unlike DNS, BT has a lot of people who certainly wouldn't miss it and certain providers would be more than happy to block it totally, etc.

Last edited by Choy Kloun (2009-11-28 21:19:03)

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

adrian

Member

Re: DHT Hacking and Security

> It turns out you can use DHT enabled clients for all sorts of stuff, like using them as an
> amplifier to a DDoS, as well as an initiators

How would that work? Sending invalid 'values' doesn't do much harm (as you would also have to perform a sybil attack and even then you won't do much bad). Sending bad 'nodes' values will do even less harm.

> and even worse you could easily disrupt the established pseudo network.

..or hijack it (-> sybil) : http://it.slashdot.org/article.pl?sid=08/11/08/1437225 (the storm worm uses/used the overnets Kademlia network)

@ The 8472

> As requested, I created an appropriate section for such discussions.

Would you mind letting me (and other DHT implementers) know where it is? :-)

Regards,
Adrian

adrian

Member

Re: DHT Hacking and Security

(deleted due to forum-software hiccup)

Last edited by adrian (2009-11-29 07:32:44)

Choy Kloun

Member

Re: DHT Hacking and Security

Obvious way of using DHT to aid in a (D)DoS attack: Use DHT nodes as amplifiers in a UDP flood. You can achieve quite decent multiplication ratios, and there are literally millions of globally distributed easy-to-locate nodes to use for it.
There are also lots of less obvious ways. I'm planning to perform some testing with actual real-life nodes and see which methods are the most viable.
Considering the huge amount of nodes available and the small amount of communications needed, even quite small rates of traffic from each node could wreak mayhem on the target.

One simple thing that really, really should be implemented is making sure the node never sends a response larger than the incoming packet (or high rates, etc) before it knows it has two-way contact with the other end. This is easy to verify if you use transaction IDs with sufficient entropy.
A good addition to the protocol would be a response that tells the sending node to cease sending ALL packets to the host for a (quite long) period of time. Obviously you need proper authentication, but that kinda solves itself with high transID entropy.
This would make life easier for those defending against any attacks. When we received multi-gigabit week-long DNS amplifier attacks I sure wished DNS had such a feature...
Consider it a "good neighbor" feature. Doing your best protocol/implementation-wise to be nice to your fellow Internet users is a very, very good thing.

There isn't anything in DHT that makes it an especially powerful DoS aid. The threat comes from the huge user base and the ease of locating nodes.
Also, there is a certain group of well-funded attackers with a clear motive for disrupting all P2P file sharing, especially DHT which lacks a single point to attack with legal or other means. This group is best known as the MAFIAA, and they have a long well-documented history of using very dirty tactics including outright technical attacks. Also consider that widespread abuse of DHT in DoS attacks would provide them with a powerful argument for blocking/banning DHT and related protocols.

Last edited by Choy Kloun (2009-11-29 11:36:56)

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

adrian

Member

Re: DHT Hacking and Security

> Use DHT nodes as amplifiers in a UDP flood.

And how would you do that?

- A $victim will only send data to $target by itself if it has been added to its own routing table.
Getting $target into $victims routing table isn't so easy because you'd first have to trick $victim into asking you about data.

- Spoofing UDP sources also doesn't sound like a good idea because most edge routers filter such stuff and it's very inefficent (1 ping -> 1 pong )

> There are also lots of less obvious ways.
Please enlighten me. I fail to see any efficient ways to perform a DDOS via Kademlia.

> This is easy to verify if you use transaction IDs with sufficient entropy.

Transaction IDs have no meaning to a peer that responds to a query.

Regards,
Adrian

adrian

Member

Re: DHT Hacking and Security

btw: I tested what would happen if $evil_node adds the IP of $victim to each find_node/get_peers reply.

I let it run for about 5 minutes ($evil_node is online 24/7h and well known in the network)

Grand totals:
----------------------------------------------------------------------
- UDP packets sent by $evil_node: 944
- UDP packets received by $victim: 222 (28054 bytes)
----------------------------------------------------------------------

You might get slightly better results if $evil_node was placed in a 'hot-spot' but even then it wouldn't be able to do much harm.

The 8472

Azureus Developer

Re: DHT Hacking and Security

> As requested, I created an appropriate section for such discussions.

Would you mind letting me (and other DHT implementers) know where it is? :-)

Regards,
Adrian

Well, idk who is who, so i only added the people who i knew to that user group.

Back to the topic. Drastic, i.e. incompatible changes to the protocol need proof that there is a serious security issue that needs to be fixed asap. Otherwise we can only provide implementation advise to make implementations less exploitable.

---

Az dev

Choy Kloun

Member

Re: DHT Hacking and Security

Spoofing UDP sources is very much doable and many edge routers (outside of broadband connections and such) certainly don't filter it. If someone doubts this I'm more than glad to provide you with a couple of hundred Mbps worth of fully spoofed UDP packets :-).
Globally, filtering of spoofed traffic is more or less a joke.

Spoofed query which results in a larger response means attack amplification - simple.
One very quick example - I just checked the debug traffic dumps from my implementation, and the 107 byte get_peers query it sends generates a 308 byte response.

It also provides the attacker with excellent distribution/spreading of the traffic sources, which is very useful in making routing-based attack mitigation much more difficult. Just using get_peers would turn an attack from a single source with a gigabit connection (not exactly rocket science to get access to for any bored kid, unlike breaking into lots of widely distributed hosts) into a poly-gigabit flood from sources all over the Net. Or maybe with sources selected to fill the weakest transit connections, etc.

Like I said, when I get the time and have finished what I'm currently working on I'll do some testing and see what if any other techniques are useful for real-life attacks. Global DHT is obviously a very complex organism (sum bigger than the parts) so fully predicting all behavior almost involves chaos theory :-).

"Transaction IDs have no meaning to a peer that responds to a query."
Well, duuh :-).
I think I wasn't being clear and/or we had some line noise :-). The purpose is for the node which sends the data to verify it in the response, obviously. Even if it normally only would receive queries from that node it can simply send a ping query to perform the verification.
Or are you referring to the 'shut up' packets? Obviously you need to take some liberties for that special case if you don't want to add a new 'shut up cookie' to the protocol (doesn't sound like a bad idea to me actually - an entry that's guaranteed to be high entropy wouldn't hurt for possible future protocol expansion when it comes to things such as authentication and crypto).

Obviously breaking backwards compatibility isn't something to be done lightly. But there are certainly small but relevant improvements (like those I suggested here) that can be done without breaking anything, or negatively affecting performance/functionality in any way. I'll start writing up a list.

I do admit that I'm a bit jumpy at times when it comes to DDoS :-) but I have the excuse of having several years experience battling attacks, some of them very creative and/or performed by very motivated attackers (FSB, the Russian security service being one of several examples).
For example, I can recall many cases where our defense would've been made much more difficult if the attack had been geographically distributed in the ways DHT enables.
And certainly there's no harm in being the best possible neighbor.

And by the way, if my explanations aren't the clearest I apologize - too much work at the moment...

Last edited by Choy Kloun (2009-11-29 17:57:27)

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

The 8472

Azureus Developer

Re: DHT Hacking and Security

Currently there are about 5M DHT nodes, assuming... regular DHT traffic is usually 3kB/s in each direction (more for very long-lived nodes). So if we would rate-limit nodes generally to 10kB/s that would be result in a max. aggregate bandwidth of 50 GB/s.

The question is can you actually harness that much... or even a fraction of that? The DHT is very transient, as attacker you have to maintain a list of live, reachable nodes that you can use to amplify your traffic. Then there is packet loss which cuts into your amplification.

The other issue here is that the threat model is limited. You assume that your attacker already has access to a 1Gbit/s internet connection and can spoof source addresses but that this alone is not enough to run a DoS attack. So you probably need a pretty big target...

Implementation optimizations such as rate-limiting requests per /24 instead of globally are the least-intrusive adjustments to prevent such attacks imo.

3-way-handshakes to check the source address just to reply to a find-nodes or get-peers request on the other hand is highly unlikely to happen. I don't think emule's Kad network has such security measures either.

And last but not least we also have to consider if we actually want to defend against such an attack since it is a high impact low probability event. The resources to mount such an attack are considerable and will most certainly trigger an investigation within the affected ISPs. I mean, i haven't heard of any 1Gbit/s > attacks that lasted for a significant amount of time without the source being identified and shut down.

---

Az dev

adrian

Member

Re: DHT Hacking and Security

@ Choy Kloun

> If someone doubts this I'm more than glad to provide you with a couple of hundred Mbps
> worth of fully spoofed UDP packets :-).

No thanks ;-)

> Spoofed query which results in a larger response means attack amplification - simple.

How does DNS/NTP solve this issue?

> I just checked the debug traffic dumps from my implementation, and the 107 byte
> get_peers query it sends generates a 308 byte response.

Ok: So you gain 2.8x . Well: Limiting the payload sent to unverified nodes would be possible without breaking any existing implementation but it might slow down the whole DHT. Hmm...

> I think I wasn't being clear and/or we had some line noise :-).
> The purpose is for the node which sends the data to verify it in the response, obviously.

Ah ok.. got it after re-reading your post.

@The 8472

> You assume that your attacker already has access to a 1Gbit/s internet
> connection and can spoof source addresses but that this alone is not
> enough to run a DoS attack.

At least it would be enough to kill many smaller sites:
You'd get ~ 2.8Gbit/s of traffic and it would be very hard to mitigate such an attack because it's spread across so many ISPs / AS

> Implementation optimizations such as rate-limiting requests per /24 instead of
> globally are the least-intrusive adjustments to prevent such attacks imo.

This would (imho) be much better than implementing a magic shut-up packet.

> I mean, i haven't heard of any 1Gbit/s > attacks that lasted for a significant
> amount of time without the source being identified and shut down.

I've used to work for a big ISP and believe me: ~3Gbit/s DDOS attacks are 'daily business'.

> Well, idk who is who, so i only added the people who i knew to that user group.

I'm the author of Bitflu and the owner of the 6to4 node in dht.wifi.pps.jussieu.fr

Regards,
Adrian

Choy Kloun

Member

Re: DHT Hacking and Security

As for NTP, the finer details of that protocol has escaped from my memory.
DNS doesn't protect against it in any way, and DNS amplifier attacks are occasionally a major headache. But it's somewhat mitigated by the fact that you aren't going to find a lot of DNS queries that generate responses with any significant amplification - the amplifier attacks use open resolvers so that the attacker can produce crafted DNS data (usually TXT or similar records filling the maximum EDNS0 packet size).
None of those protocols are running on 5M servers which are purposefully designed to distribute their IP address, though...

Obviously making DHT a better citizen is something that would be done with several small fixes and not one/a few magic bullet(s). When I suggest modification X, it doesn't exclude !X :-).

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

Choy Kloun

Member

Re: DHT Hacking and Security

As for NTP, the finer details of that protocol has escaped from my memory.
DNS doesn't protect against it in any way, and DNS amplifier attacks are occasionally a major headache. But it's somewhat mitigated by the fact that you aren't going to find a lot of DNS queries that generate responses with any significant amplification - the amplifier attacks use open resolvers so that the attacker can produce crafted DNS data (usually TXT or similar records filling the maximum EDNS0 packet size).
None of those protocols are running on 5M servers which are purposefully designed to distribute their IP address, though...

Obviously making DHT a better citizen is something that would be done with several small fixes and not one/a few magic bullet(s). When I suggest modification X, it doesn't exclude !X :-).

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

jch

Member

Re: DHT Hacking and Security

Use DHT nodes as amplifiers in a UDP flood. You can achieve quite decent multiplication ratios,

If I'm not mistaken, you get an amplification factor of 1 in packet count, and roughly 3 in packet size.  You'll get much better results with DNS, especially once people start implementing IPsec.

I'm much more concerned about the damage that the so-called security experts do by causing useless panics (I still grieve for RH0).

As requested, I created an appropriate section for such discussions.

Unless there's good reason not to, let's discuss that in public.

--Juliusz

Choy Kloun

Member

Re: DHT Hacking and Security

And idiots causing panic relates to people who have mitigated far too many DDoS attacks discussing possible protocol and implementation issues with developers in what way, exactly?

Edit to clarify: If anyone has interpreted anything I've said as panic-mongering, I apologize for that. Not at all my intention. Now lets get on with identifying problems and discussing relevant solutions!
I'll also submit a proposal for DHT protocol encryption/obfuscation shortly, but that's not relevant for this thread.

Last edited by Choy Kloun (2009-12-01 11:39:14)

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

jch

Member

Re: DHT Hacking and Security

Now lets get on with identifying problems and discussing relevant solutions!

Yes, let's.  What amplification factor are you claiming exactly?

--Juliusz

Choy Kloun

Member

Re: DHT Hacking and Security

Major issue when it comes to amplification whne doing simple spoofed queries isn't some extreme ratio (the most basic abuse would result in roughly 3x as has already been stated, although it should be possible to achieve a higher ratio), but the fact that it provides really easy distribution and targeting geographic/network-wise, because of the large number of clients and the ease of locating them.

This is very effective at bypassing several important DDoS mitigation methods
Even not taking that issue into account millions of nodes that provides decent amplification and are easily located is definitely useful for an attacker.

Unfortunately I got sick for two weeks and I'm having a hell of a time clearing up the huge backlog of work that built up during this time, so I still haven't done the testing I plan to do so we can see some empirical evidence here.
I have to eat, and while  ស្រុកខ្មែរ is a wonderful country in many ways it certainly doesn't have a dole office :-). My savings are a bit thin because of this so I need to work my ass off for the next couple of weeks.

Will get back to the DHT lab as soon as I have some spare time.

Anyways, my basic point is still that some simple non-invasive measures can effectively prevent this and other DHT-based attacks. I don't see any reason not to be the best possible Internet citizen in such a widely used protocol.

And please, try to be a bit nicer. Is this the way you greet all proposals dealing with something new and unknown? I understand that my intentions could have been misunderstood as misinformed scare-mongering, and that not everyone in this thread do know enough of my background to verify that I'm not some random hobo talking out of my ass, but isn't this cleared up by now? If I've misread your intended tone then I apologize in advance.
I'm just talking about one participant here - the others have brought up valid issues / questions which is exactly what I want.

I find decentralized networking and self-organizing systems extremely interesting, and on top of this I do really, really like BT and DHT a lot. I'd hate to see DHT being abused on a large scale which IMHO is a real possibility and would cause great harm not only to the DHT network but also to a large amount of third parties.

Last edited by Choy Kloun (2009-12-04 16:41:58)

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

jch

Member

Re: DHT Hacking and Security

> Is this the way you greet all proposals dealing with something new and unknown?

No.  This is the way I greet people who start by telling me about China and Iran and how evil they are, and then suggest that we create a private forum to discuss without the hoi polloi barging in.

--Juliusz

The 8472

Azureus Developer

Re: DHT Hacking and Security

I suggest you refrain from meta-discussion, politics, personal crusades etc. and only stick to the protocol and changes at question.
What you're doing will not lead anywhere.

---

Az dev

adrian

Member

Re: DHT Hacking and Security

> I suggest you refrain from meta-discussion, politics, personal crusades etc. [...]
> What you're doing will not lead anywhere.

To be honest: At least the first few posts sounded like the 'symantec-salesforce' tried to invade the forum in order to spew panic. And creating a secret place that excludes other DHT implementors (such as /me and jch) isn't a nice thing to do either.

But back to the topic: Let's summarize what we got so far:

-> Fredrik and Choy stated that the DHT network could be abused to start a DDOS with ~3x amplification factor IF you are able to spoof UDP Source addresses.

-> You could do exactly the same using public DNS / NTP / $anything_that_uses_udp Servers but it would be harder to mitigate an attack that uses the DHT.

-> Implementing a rate-limit could help but calculating the upper limit would be tricky (measuring 'normal' traffic while running doesn't work because the node could be under attack from the beginning)

Anything else?

Choy Kloun

Member

Re: DHT Hacking and Security

> To be honest: At least the first few posts sounded like the 'symantec-salesforce' tried to invade the
> forum in order to spew panic.

Yes - I totally agree here. Fredrik is not good at expressing himself in writing. And you kinda must understand the background - he'd seen me and others do lots of odd stuff with DHT and he's a really, really, skilled tech guy in a lot of ways but not when it comes to judging the severity of stuff like this.
We have done a range of things from severe to fun harmless experiments using DHT for stuff it wasn't intended for and just by filtering that through a third party and then adding me being pretty blunt when it comes to (D)DoS attacks simply from having spent many late nights defending against big attacks made possible by other protocol defects... well, you don't get a good start of a thread unless everyone involved knows each other from before.

I guess I kinda apologize on his behalf, without asking him first :-). And again for anything I've writtent that can be perceived in the wrong way.

Hell, I quit a promising career in the formal computer security industry (consulting doing pentesting and such (even pentesting in itself as its often done is quite a worthless way of testing high-level security!)) largely because 99.999% of the industry is Symantec/ISS/WeKnowJackShitButWeHaveAGoodSalesTeamAndOur"Experts"HaveCrispNewSuitsBigCorp. Large parts of the computer security industry is at the end of the day simply parting fools from their money. I'd even call it a fraud. I couldn't look myself in the mirror knowing I was part of that.

Computer security is still part of much of the work I do but it's totally honest work that more or less speaks for itself for the client. If I mess up doing some of my consulting jobs, the result is that literally millions of dollars and potentially human lives can be lost. Not that some bean-counter or salesdroid just has to tell a little white lie to a customer and tell them that they didn't buy a product/service that was expensive enough. I have so many horror stories from the industry to tell if anyone wants to listen... Everything from awards being given to products that would be technically impossible to advisories about non-existing vulnerabilities.

But as I'm kinda unknown here except by the few who know me, stuff like that obviously isn't knowledge amongst many of the participants in the thread and I'm not the most reliably diplomatic guy either. I try to always be modest about my skill level though, when it isn't needed to prove a point.

> And creating a secret place that excludes other DHT implementors (such
> as /me and jch) isn't a nice thing to do either.

Not my decision (I joined here after the secret society was set up and everyone got their DHT Security Stonecutter rings and had to do the secret initiation ritual ), but doing it with totally full disclosure at this stage would potentially cause what we are trying to avoid in the future. Hell, full disclosure is another thing that's wrong with the computer security industry today as it has basically turned into half scaremongering and half extortion.
And to be honest, excluding jch seems like a good idea until we make up, shake hands and get on a friendly basis :-) And maybe just agree to disagree instead of engaging in flame wars if we can't get our respective points across to each other...

To add to your list:
- I think NTP solves this actually. Atleast I have a recollection of this being the case. Haven't had time to do a single piece of BT/DHT-related work since my last post in this thread.
- Incoming DNS attacks are much easier to block at the router ACL (done in ASIC) level (constant source port). You could block ALL traffic from port 53 to say a hosting network if all servers use one specific resolver being exempted from this block (potentially being on a totally separate network
- No ISP would get the idea of totally blocking DNS and NTP and there's no one that has political motives for them doing so, but DHT on the other hand...
- Clients could use the transID and keep state (simple hash table, O(1)) to verify that it has two-way  communications, and before it does at least apply strict rate limiting. At this level it should be possible to do so as we are talking a single packet exchange. Limiting SHOULD be done on a network (/24 or possibly even shorter prefix). And/or even make sure you never send a response bigger than the query.
This should be doable while retaining full backwards compatibility. I don't have delusions of grandeur and think we can make millions of users all upgrade at once just because someone comes up with a good idea.

- More research with actual real live nodes is needed to see what other attacks are practical (we have a few in store)

- Not only discussing DoS issues, but also attacks targeted against the DHT network itself. Think MAFIAA deciding that DHT is the next big threat to their antiquated business models. I think I already mentioned this, but I have a view where DHT just like Usenet could be in need of active defensive (or offensive) measures managed by trusted users.
Maybe there will be an equivalent to killfiles and cancelbots in the DHT network in the future ?
This brings me back to my previous point. And the last sentence of my first.

- Later on, when we've reached something concrete from this, maybe get on to how to prevent ISP blocking/manipulation of DHT traffic. Does it suffice to say that the majority of traffic blocked in China is BT traffic, and it's certainly not because of piracy ... ?

No, I'm not going "China is evil, Iran is evil, blah blah blah blah lets be a liberal do-gooder" here. I'll temporarily suspend my modesty again and say that I probably have by far the best view of the situations in those countries of anyone remotely active in this thread. As for China evil blah blah, hasn't certain people even bothered to notice that my nickname and signature are both in an Asian language? A language spoken in one specific country close to China with a large Chinese population and a sizable Chinatown in the middle of the capital?

(My signature says approximately "If you don't like P2P, then go to hell" but in a much ruder way than it's possible to say it in English, and with a creative transliteration of the English pronounciation of P2P... The precise level of politeness used the one you'd use if were talking to a child or maybe someone at the higher levels of society addressing a beggar who's pestering him. Not only computer languages are fascinating!
នីងខ្ងំនិយាយភាសាខ្មែរតែខ្ងំមីនសរសេរល្អអតេ​)

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

The 8472

Azureus Developer

Re: DHT Hacking and Security

Uhm, that post still consists to > 50% of personal anecdotes and meta-discussion. Again, please stick to the topic.

---

Az dev

Choy Kloun

Member

Re: DHT Hacking and Security

I think all of it had a point, at least the first paragraph (clarifying why the thread started the wrong way) and the last paragraph (why there are good reasons to believe China will start blocking/attacking DHT) and honestly- I've never had any significant number of developers get together in the same place without sharing a lot of anecdotes. But you're the boss, and yes, it certainly strayed off-topic.
I'm still bitter with a certain industry though. Extremely.

So, do we have any comments on the actual bullet points? Just read the parts starting with '-'.
Less talk, more chalk!

Last edited by Choy Kloun (2009-12-10 07:40:31)

---

ឧងមិនចូលចិត្តភិទភិតេ?ចូយមាឧង!

adrian

Member

Re: DHT Hacking and Security

> And to be honest, excluding jch seems like a good idea until we make up,
> shake hands and get on a friendly basis :-)

jch is a friendly person and it just appers that he *also* got pissed off when someone tried to hijack this thread into a private forum.

Back to the topic:

# Verify each client:
> - Clients could use the transID and keep state (simple hash table, O(1)) to verify that it has
> two-way  communications,

I don't really like this approach: Having to verify EACH client doing a 'q' query has some bad downsides:

- It generates a lot of (otherwise unneeded) UDP-Traffic
- The client needs to maintain yet another hashtable, creating a new attack vector:
    You could just flood/overflow a clients table by using spoofed source adresses.

# Cropping responses
Adding a 'never send more than you have received' rule would hurt the DHT and treats IPv6 as a 2nd class citizen

# Rate limitation:

My vote would go to rate limitation:

- Verified clients/peers would have no rate limitation
- The client could pick some random good-nodes to see how much traffic per /24 appears to be normal
- ..and it would then enforce the guessed limit to unverified peers

Regards,
Adrian