Having not followed the projects' security process, presumably this is something the author didn't think was a serious issue themselves.
This doesn't appear to be new or interesting: If you exhaust a hosts incoming sockets it temporarily can't accept new connections.
Bitcoin itself already prioritizes existing and "good" connections to a substantial extent. Networks and IPs with multiple existing connections are prioritized for disconnection to handle new connections[1]. The result is that most existing connections are undisturbed, which makes it fairly ineffectual as an attack-- unless someone has broken something in the last couple years since I worked on it. A few years ago there were some periodic waves of people attempting attacks like this that went completely unnoticed in public due to their lack of meaningful effect.
It's annoying that new connections can be frustrated while an attack is ongoing, but since bitcoin connections are extremely long lived it doesn't have much of an impact, which is the security property the software is intended to uphold. The comment about 'finalization' suggests the author of the post isn't particularly familiar with how bitcoin works.
And at least if the attack is at a high enough rate, since the exhaustion will happen at the kernel before it gets to the bitcoin software, there isn't much for the bitcoin software to do. The host can implement firewall rules to mitigate, though even that can only work to the extent that the attack hasn't just effectively become volumetric.
It might be reasonable for the bitcoin authors to recommend some standard iptables rules that people should deploy as a best practice to protect their kernel's TCP stack (and avoid the issue that people will screw them up when coming up with their own).
i considered this and needed clarification. i didn't know whether the p2p connections remained open or made frequent disconnect/reconnects. what happens to sync'd nodes with active peers is yet to be seen. it's too early, at least for me, to know whether peers would drop a node under attack over timeouts, how bitcoind behaves with peers while tcp/8333 is experiencing stress, etc.
bitcoind not having ip associated throttling edit: BUILT IN* is questionable. this attack shouldn't work on out-of-the-box installs of bitcoin. as i mentioned earlier - there is no rationale behind a single machine making 1k handshake requests per second.
nullc|3 years ago
This doesn't appear to be new or interesting: If you exhaust a hosts incoming sockets it temporarily can't accept new connections.
Bitcoin itself already prioritizes existing and "good" connections to a substantial extent. Networks and IPs with multiple existing connections are prioritized for disconnection to handle new connections[1]. The result is that most existing connections are undisturbed, which makes it fairly ineffectual as an attack-- unless someone has broken something in the last couple years since I worked on it. A few years ago there were some periodic waves of people attempting attacks like this that went completely unnoticed in public due to their lack of meaningful effect.
It's annoying that new connections can be frustrated while an attack is ongoing, but since bitcoin connections are extremely long lived it doesn't have much of an impact, which is the security property the software is intended to uphold. The comment about 'finalization' suggests the author of the post isn't particularly familiar with how bitcoin works.
And at least if the attack is at a high enough rate, since the exhaustion will happen at the kernel before it gets to the bitcoin software, there isn't much for the bitcoin software to do. The host can implement firewall rules to mitigate, though even that can only work to the extent that the attack hasn't just effectively become volumetric.
It might be reasonable for the bitcoin authors to recommend some standard iptables rules that people should deploy as a best practice to protect their kernel's TCP stack (and avoid the issue that people will screw them up when coming up with their own).
[1] https://github.com/bitcoin/bitcoin/blob/master/src/node/evic...
pbear2k21|3 years ago
pstrateman|3 years ago
Unless there's been a significant regression these issues were fixed after I found the slowloris type attacks to be an issue in 2012.
Edit: Maybe he's attacking his own RPC port, which again doesn't matter since it's not open to the internet.
pbear2k21|3 years ago
it's not an rpc port - and the computer in the screen shot using telnet is an external machine that isn't participating in the attack.
durpkingOP|3 years ago
nibbleshifter|3 years ago
News at eleven.
pbear2k21|3 years ago
xcombelle|3 years ago
[1] https://en.wikipedia.org/wiki/Slowloris_(computer_security)
unknown|3 years ago
[deleted]
yonixw|3 years ago
pbear2k21|3 years ago
8organicbits|3 years ago
https://g.livejournal.com/14363.html