Tips to Improve Stake Pool Node Security

Look alive, SPOs!

Here are some tips to help lock down your nodes. Data and report produced by VRITS stake pool

Please don’t hesitate to ask questions if anyone runs into issues working to implement some of these recommended practices.

Your friend, FROG

8 Likes

Top Man :+1:t2:

I’m not running one yet (lack the skills currently) however i see and really appreciate your input for the benefit of the community ADAFrog

Thank You :pray:t2:

1 Like

I also recommend limiting the number of connections from one ip per port. As a result of DDOS testing (5000 connections on port 3001), 5 pools from 20 random pools were disabled for a certain time. I also apologize for this operation, this will not happen again from us. This was done to test and provide useful experience for pool owners. Pools were selected with a very low Live Stake.

1 Like

So @Vadimus you selected the pools for your “test” as the ones who would have been most hurt by losing their rare opportunities to make a block during that period? Incredible. Did you think about the unavailability of their relays causing their own topology peers to drop them, which would have affected them longer than your “testing” period?

I don’t think your “apology” can be accepted since it doesn’t sound like you understand either the technical or ethical implications of what you have done.

3 Likes
1 Like

It looks like I was misunderstood due to the brevity of the information I provided. I have not tested DDOS on pools without the permission of their owners.
I selected 20 small pools without delegates and contacted their owners through their communication channels. We agreed on the time and method of testing. During testing, we isolated our pools from the main network. During testing, we checked the quality of the network security of our pools and eliminated network gaps. Thanks to these pools in our joint work.
@COSDpool you have nothing to blame me for, no one was hurt by my actions. I ask you to correct the text on github and remove the accusatory tone.

2 Likes

@Vadimus of course I am relieved to hear that you had the cooperation of the pool owners: the difference is like night and day. Nobody would have guessed this from your original statement, because then there would have been nothing to “apologise” for.

The way the original statement was worded I’m honestly surprised 10 other people didn’t jump in in the meantime to demand to know what was going on. Thanks for leaving up your first statement unedited so readers can at least see how this misunderstanding came about. It’s not so much a matter of “brevity” but completeness about the conditions that would very grave otherwise, and I’m glad you submitted your qualifying statement promptly.

I’ve edited the presentation of this matter on Github and I hope you will comment there if it fails to address either the practical results or the spirit of your test. :sunglasses:

4 Likes

I accept, the force will be with you.

2 Likes

This is misleading and it does not provide any useful informations regarding the security practices of the probed servers…

2 Likes

Yes, the value I think SPOs should take from this is to understand whether they could benefit from implementing some of the suggested security recommendations. Many SPO’s lack proper education tools in this area so dialogue on best practices could be helpful

1 Like

Prior to testing, the servers did not have any network restrictions that we were aware of. Of course, in some cases, the hoster itself provides protection against DDOS. But this is not the case. The problem on the tested servers was RAM overflow and node hang. As a result, we came to the conclusion: that the number of connections from one ip must be limited, RAM less than 4 GB is bad. Unfortunately, I was not able to conduct serious testing as I received a warning from my hoster. But I think this little information is already useful.
P.S.: The experiment was carried out on version 1.18.0. Since then, 2 updates have been released that have significantly improved node performance. Perhaps load testing would give a different result now.

I was refering to the initial article post :slight_smile:

Something along these lines would be a discussion/lecture/youtube as how to operate an offline node. Signing and bringing forth all manor of transactions,

1 Like

Thanks - yes I think this would be very helpful. I’ll put some content together on this.

1 Like

There’s been some attention to this issue from developers on the IOHK Github. Nobody has come forward to say that it’s a good idea to limit the number of incoming connections to a relay port from the same IP. On the other hand, they say it might be harmful in 2 cases:

  1. when you have more than one node on a server - which we’re not supposed to do anyway.
  2. when the node is behind a Carrier-grade NAT - which generally means a home-based connection, not a data centre NAT for sure, which wouldn’t be the ideal place for your relays.

This suggests the conclusion so far regarding “limiting the number of incoming connections” from a single IP is that there’s no compelling reason to do it in the recommended stake pool setup.