3 ms·
Implementing sample_infohashes opens your torrent client to abuse. UDP responses are much larger than queries and this protocol (BEP51) allows attackers that ca
by jesprenj 3y ago
Implementing sample_infohashes opens your torrent client to abuse. UDP responses are much larger than queries and this protocol (BEP51) allows attackers that can spoof source IP addresses to use a large number of clients as mules for amplified distributed denial of service attacks.
- mgdigital 3y agoBitmagnet has rate limiting on incoming UDP requests (both overall and per-IP) so I don't know that it would be vulnerable; if there's anything else that should be done to mitigate any risk I'd like to know.
- pluto_modadic 3y agooutgoing rate limits, and also it could exhaust the overall rate with useless traffic.
- mgdigital 3y agoIncoming and outgoing are both limited, I think the worst such an attack could do is prevent responding to legitimate incoming queries - this shouldn't slow down the DHT crawler in a noticeable way.
- jesprenj 3y agoI do not mean bitmagnet here, I mean other bittorrent clients that respond to sample_infohashes.
- p1mrx 3y agoHas anyone tried to fix this by making queries bigger, and limiting the response to the size of the query?
- the8472 3y agoIndividual DHT nodes should only see a trickle of packets. A few kilobytes per second. Even less per remote IP. So they can set fairly strict rate limits. And ISPs are in a much better position to solve this problem anyway. They should ask for higher peering fees from peers that don't do source-filtering.
- jesprenj 3y agoTrue. Although an ISP can say they do source filtering and then fail to implement it properly. For example my ISP at home implements source filtering on IPv4, but not on IPv6.