arvidn
Automatically block idle peer connections to resist denial-of-service attacks
Earlier, one of my torrents was subjected to a denial-of-service attack by malicious peers. The attackers bound random addresses under an IPv6 subnet using FreeBind (or something like that) and initiated incoming connections to me. After my BT client (qBittorrent) established a connection with them, they simply remained idle and refused to engage in any meaningful communication. This eventually exhausted my connection pool, preventing me from connecting to any other good peers and making it impossible to seed or download.
(There are more connections below the scroll bar, but I didn't screenshot them because aside from having different IP addresses and ports, all the other details are completely identical.)
At the same time, another one of my torrents also appears to be experiencing the exact same issue, However, since the connection pool has been exhausted, only a small number of malicious connections were successfully established for the following torrent:
Unfortunately, I am constrained by my ISP's connection limit, which prevents me from further expanding my connection pool to accept more connections and mitigate the impact of the malicious attackers. If I were to remove the limit, these peers would directly exhaust my ISP's connection quota, resulting in a complete loss of internet access.
By manually blocking these IP addresses, the situation has been alleviated, but this is ultimately not an optimal solution. I believe libtorrent should implement measures to automatically disconnect such connections and welcome new incoming ones.
Regardless, thank you very much for your work.
Have a nice day!
I can see a few different ways to mitigate this.
- when banning an IPv6 address, ban a whole /64 (or something wider than a single address)
- have more aggressive timeouts for peers that are idle (these timeouts exists, but they may be very forgiving)
- have a lower limit of incoming connections than outgoing. i.e. don't let incoming connections prevent outgoing ones
when banning an IPv6 address, ban a whole /64 (or something wider than a single address)
I've seen it happen with /52 addresses, but /52 seems to be a bit of a wide range, and many users only have /60 or /64
have more aggressive timeouts for peers that are idle (these timeouts exists, but they may be very forgiving)
I agree with this, it can alleviate this problem, but it is not the ultimate solution. If a Peer is inactive, it should be removed in reasonable time.
have a lower limit of incoming connections than outgoing. i.e. don't let incoming connections prevent outgoing ones
Yeah. It's a great idea, but it still won't completely solve the problem.
Can we introduce a setting to limit the maximum number of connections from the same address segment of v4/v6? Once a reasonable number is exceeded, we should reject new connections from that address segment (whether outgoing or incoming).
Especially when they are highly likely to originate from the same LAN, this does not seem to cause significant issues (assuming they share resources within the same LAN or close in geolocation).