Potential relay node DDoS attempt?

The other day I noticed my public relay node had 300+ inbound connections. When I looked at the peer details, they were all from the same IP: 185.191.77.221

This caused the node to stop processing TXs and the mempool remained at 0. I found another thread on here about someone complaining about the same issue with 200+ inbound connections from this very same IP.

It got me wondering whether this was an intentional DDoS attempt at Cardano nodes specifically. The relay node is running on port 6000 which is also the X Windows server port, so it could possibly be a bot or scanner attempting to exploit X11.

I didn’t capture the traffic from that IP at the time, but am tempted to set up a honeypot to investigate this further. It’s definitely concerning to SPOs, as this could be a sign of the start of “bad faith” pools attacking other pools for a competitive edge.

Either way, I decided to start the Cardano Node Blocklist Project that aims to have a unified, updated list of malicious IPs and hosts to block on your relay servers: https://github.com/fatstakes/cnode-blocklists

This is a community driven project so please contribute if you can.

And please share if you’ve experienced something similar.

Apart from maybe, making a colleague look bad or annoy him/her, there is no financial incentives for SPOs to attack each other.

Block allocation is determined for an entire epoch. There is no way to snatch a block from a colleague. Even competitive blocks are won deterministically via VRF output.

It is in the best interest of all SPOs that everyone make their blocks, since failure to make them negatively impacts the rewards of everyone else.

I don’t know who nor why you see this, but I doubt it is to gain a competitive edge.

1 Like

Appreciate the insight. Again, just trying to figure out what this is all about. Like I said, it could just be a bot or scanner trying to exploit X11, but really would like to get to the bottom of it to prevent a similar event in the future.

Regarding the competitive edge theory, I wasn’t thinking that the attacker was trying snatch blocks, but more so to prevent the production of blocks. If a relay node that a block producer was connected to suddenly lost connection to the p2p network, with no inbound connections for an entire epoch, would that prevent the bp from producing any blocks and prevent rewards?

Yes it would, as the BP would be unable to submit the blocks.
This is why it’s important to have more than one relay, ideally in more than one location. This way, if one of your relays is down when the time comes for you to make a block your BP can still get it out to the network.
At least that’s my understanding anyway!

A similar principle applies when doing updates or maintenance on your relay nodes. You don’t want to miss block producing opportunities because you’re rebooting your relay for a kernel update!

I recommend having another relay node set up but private (not on your metadata) :slight_smile: