7 ms·

New Bitcoin DDoS Technique

49 points by pbear2k21 4y ago

xcombelle 4y ago
it is slowloris [1] isn't it ? [1] https://en.wikipedia.org/wiki/Slowloris_(computer_security) https://en.wikipedia.org/wiki/Slowloris_(computer_security)
- deleted 4y ago
  [deleted]
pstrateman 4y ago
He's just DDoSing himself. 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 4y ago
  yes - testing his own node. that is how pen testing blockchain nodes works. from there you can make projections of scaled attacks. 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.
  - pstrateman 4y ago
    Nah all that's happening is he's using connection slots. The attacking node will have a very low score and get disconnected when other legitimate connections are made.
    - pbear2k21 4y ago
      50k sockets looping requests make the p2p port entirely inaccessible at times. with more attacking machines it is reasonable to suspect that the target node(s) could be held down in perpetuity. edit: re: child comment / syn flood; sure. bitcoind needs ip associated throttling baked in. there is no rationale behind a single machine attempting 1k handshakes a second. the attack shouldn't work at all.
      - r1ch 4y ago
        You may as well just SYN flood at that point. None of this is really new, you can take down a lot of TCP based servers with the right combination of packets and volume.
      - linuxdude314 4y ago
        It’s also reasonable to prevent this sort of abuse using a firewall or rate limiting load balancer..
      - pstrateman 4y ago
        Inaccessible from the machine doing the attack. But is it preventing the node from communicating with the rest of the network? That's a big doubt from me.
        pbear2k21 4y ago
        inaccessible to external machines that are not participating in the attack. it's yet to be seen what happens to a node that's sync'd with active peers and whether a node under attack is kicked out of the network for timeouts or how bitcoind behaves in general while tcp/8333 is under fire.
        nullc 4y ago
        > it's yet to be seen It's yet to be seen by you. But you are not the first person to have thought of characterizing this behavior in the last decade. Some other people have actually done so, including the person you're responding to! (who successfully discovered and fixed a number of vulnerabilities years ago) I tested and existing connections continue to work fine w/ a connection exhausted peer, as expected. It sounds like you're saying that you haven't tested this. If you do and get a different result, I'm sure the bitcoin devs would like to hear about it.
        pbear2k21 4y ago
        i've popped 25 - 30+ blockchains. from anecdotal experience i suspect that there could be something here and need to see it through with a sync'd node and more firepower. you seem overconfident.
- durpkingOP 4y ago
  Prove it. Setup a node and test this method on it. Otherwise this comment should be redacted.
yonixw 4y ago
I guess the punchline here is that there are no rate limits/cool downs per IP? But surely a hardened Linux VM will have those...
- pbear2k21 4y ago
  it is
nibbleshifter 4y ago
Sending lots of junk connections to a service will degrade performance. News at eleven.
- pbear2k21 4y ago
  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.
  - BenoitP 4y ago
    sudo iptables --append INPUT --source 123.123.123.123 --jump DROP
    - pbear2k21 4y ago
      node operators can implement their own throttling - sure - but how many bitcoin node operators are doing that to deflect a p2p ddos attack? even if some are, most aren't - and finality in the network could potentially suffer as a result of a massively scaled botnet attack. edit: interesting child comment here. not pushing a patch just leaves the bulk of the network vulnerable to being ddos'd by a botnet - potentially resulting in severely lagged finality at best. ip throttling can/should be implemented by being baked into bitcoind.
      - BenoitP 4y ago
        A one-liner, from a one-purpose-unix standard tool, 20 seconds fix is enough; what more do you want? This is a not a bug / won't fix
        imtringued 4y ago
        The attacker used multiple nodes. Read the GitHub issue again. You are going to need more than one line and at some point you are going to notice that you want a software solution.
8organicbits 4y ago
Slightly more details here: https://g.livejournal.com/14363.html https://g.livejournal.com/14363.html
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 ago
  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.
  - CommitSyn 4y ago
    There are many tools that will help you answer things like this i.e. Wireshark.

49 points by pbear2k21 4y ago

it is slowloris [1] isn't it ? [1] https://en.wikipedia.org/wiki/Slowloris_(computer_security) https://en.wikipedia.org/wiki/Slowloris_(computer_security)

deleted 4y ago
[deleted]

pstrateman 4y ago

He's just DDoSing himself. 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 4y ago
yes - testing his own node. that is how pen testing blockchain nodes works. from there you can make projections of scaled attacks. 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.
- pstrateman 4y ago
  Nah all that's happening is he's using connection slots. The attacking node will have a very low score and get disconnected when other legitimate connections are made.
  - pbear2k21 4y ago
    50k sockets looping requests make the p2p port entirely inaccessible at times. with more attacking machines it is reasonable to suspect that the target node(s) could be held down in perpetuity. edit: re: child comment / syn flood; sure. bitcoind needs ip associated throttling baked in. there is no rationale behind a single machine attempting 1k handshakes a second. the attack shouldn't work at all.
    - r1ch 4y ago
      You may as well just SYN flood at that point. None of this is really new, you can take down a lot of TCP based servers with the right combination of packets and volume.
    - linuxdude314 4y ago
      It’s also reasonable to prevent this sort of abuse using a firewall or rate limiting load balancer..
    - pstrateman 4y ago
      Inaccessible from the machine doing the attack. But is it preventing the node from communicating with the rest of the network? That's a big doubt from me.
      - pbear2k21 4y ago
        inaccessible to external machines that are not participating in the attack. it's yet to be seen what happens to a node that's sync'd with active peers and whether a node under attack is kicked out of the network for timeouts or how bitcoind behaves in general while tcp/8333 is under fire.
        nullc 4y ago
        > it's yet to be seen It's yet to be seen by you. But you are not the first person to have thought of characterizing this behavior in the last decade. Some other people have actually done so, including the person you're responding to! (who successfully discovered and fixed a number of vulnerabilities years ago) I tested and existing connections continue to work fine w/ a connection exhausted peer, as expected. It sounds like you're saying that you haven't tested this. If you do and get a different result, I'm sure the bitcoin devs would like to hear about it.
        pbear2k21 4y ago
        i've popped 25 - 30+ blockchains. from anecdotal experience i suspect that there could be something here and need to see it through with a sync'd node and more firepower. you seem overconfident.
durpkingOP 4y ago
Prove it. Setup a node and test this method on it. Otherwise this comment should be redacted.

yonixw 4y ago

I guess the punchline here is that there are no rate limits/cool downs per IP? But surely a hardened Linux VM will have those...

pbear2k21 4y ago
it is

nibbleshifter 4y ago

Sending lots of junk connections to a service will degrade performance. News at eleven.

pbear2k21 4y ago
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.
- BenoitP 4y ago
  sudo iptables --append INPUT --source 123.123.123.123 --jump DROP
  - pbear2k21 4y ago
    node operators can implement their own throttling - sure - but how many bitcoin node operators are doing that to deflect a p2p ddos attack? even if some are, most aren't - and finality in the network could potentially suffer as a result of a massively scaled botnet attack. edit: interesting child comment here. not pushing a patch just leaves the bulk of the network vulnerable to being ddos'd by a botnet - potentially resulting in severely lagged finality at best. ip throttling can/should be implemented by being baked into bitcoind.
    - BenoitP 4y ago
      A one-liner, from a one-purpose-unix standard tool, 20 seconds fix is enough; what more do you want? This is a not a bug / won't fix
      - imtringued 4y ago
        The attacker used multiple nodes. Read the GitHub issue again. You are going to need more than one line and at some point you are going to notice that you want a software solution.

8organicbits 4y ago

Slightly more details here: https://g.livejournal.com/14363.html https://g.livejournal.com/14363.html

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 ago
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.
- CommitSyn 4y ago
  There are many tools that will help you answer things like this i.e. Wireshark.