31 ms·
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
by nullc 4y ago
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).
[1] https://github.com/bitcoin/bitcoin/blob/master/src/node/eviction.cpp#L178 https://github.com/bitcoin/bitcoin/blob/master/src/node/evic...
- pbear2k21 4y agoi 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.
- CommitSyn 4y agoThere are many tools that will help you answer things like this i.e. Wireshark.
- nullc 4y agoA large portion of a nodes connections live as long as possible given the uptime of the connected nodes. Care is taken it protect long working connections to provide as strong a protection against new and short lived attacks as possible-- a working network should stay working. A sustained attack can frustrate newly connecting/restarting hosts when the recipient is publicly reachable and known to the attacker, but I think that's essentially insoluble (if nothing else, a volumetric attack would guarantee it). If you're going to be making announcements and whatever, you probably should have taken the time to characterize your observations completely! The failure to do so makes it kinda just look like more lamesauce attempts at market manipulation (not to lob an accusation, it's just what it looks like -- there is a long history of that kind of activity). > it's too early, at least for me, to know whether peers would drop a node under attack over timeouts, Do your homework! You're not the first person who ever thought of attacking a bitcoin node. While I'm sure there are areas for improvement, you're not likely to be able to make useful suggestions from a position of almost total ignorance.
- pbear2k21 4y ago>Do your homework! You're not the first person who ever thought of attacking a bitcoin node. While I'm sure there are areas for improvement, you're not likely to be able to make useful suggestions from a position of almost total ignorance. again, i've successfully found remote crashes and dos issues in 25 - 30 blockchains. i don't care if you're a biased developer who takes this to heart. i'm going to see to brutalizing bitcoind and making it clear to you what happens when i attack nodes. cocky academics like you motivate me. he who laughs last etc.
- nullc 4y agoFantastic, I'm sure the bitcoin developers will appreciate the free labor. But if you care you have any reputation as anything but a hotheaded fool-- you should probably tone the public announcements down until you've actually completed your work! Otherwise, even when you do carry work though until you find something interesting (and I'm sure you would if you work at it long enough)-- you'll still have earned a poor reputation regardless.