[pstrateman]

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]

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]

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]

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]

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]

It’s also reasonable to prevent this sort of abuse using a firewall or rate limiting load balancer..

[pstrateman]

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]

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]

> 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.

[durpkingOP]

Prove it. Setup a node and test this method on it. Otherwise this comment should be redacted.