How are solo chain validators protected against DoS?

Question

It's clear that we must include the IP addresses to our validators on our chainspec if we are starting a solo-chain (Correct me if I am wrong here, does it need to be a validator IP or can it be any IP as in the case of a sync node?) and on the other hand, a block producer like BABE which randomizes the next block producer sells itself by shielding validators from DoS attacks by randomizing the next block producer.

My question stems from these two points, if our validators are known (their IPs are on the chainspec OR maybe it is possible to find out the peer ID ip addresses?) and the network is relatively small (which is true at the beginning of every network), how or if is it even possible to prevent a DoS attack?

Moreover, since Babe has a hard requirement of seeing at least one block per epoch, otherwise the chain stalls, it could very well be possible that the network sees an epoch seconds long DoS attack from adversaries and effectively stall the chain.

Am I correct to understand this situation here?

Answer 1

In general, DoS attacks are non-trivial to prevent entirely. They're mitigated by the fact that they're technically non-trivial to execute (it requires substantial knowledge of the codebase and sysadmin/devops skill) and they're costly to maintain. Substrate networking code is written with quite an advanced peer reputation and evaluation system, which should take care of ejecting bad/malfunctioning/DoSing peers early on.

BABE does indeed have a requirement that blocks be produced every session and if this requirement is not met it will stall. Sessions are typically between 1 hour and 4 hours, with 6 sessions per era. At present there is no reason to believe that even a moderately well-funded attacker could DoS several reasonably performant nodes to the point that they would be unable to produce a single block over the course of multiple hours. Nevertheless, the more validator/collator nodes which are involved in your network the better, as this makes an effective attack harder to execute and provides some redundancy.

Any networks which are at risk from well-funded and capable attackers should take precautions, including:

• a large number of validators (perhaps up to 1,000);
• have a large number of reserved peer slots between validators;
• minimise the number of untrusted peer slots available for attackers;
• avoid exposing RPC services on validators; and
• maximise the session length (at least 1 hour).

If you're really worried, then you could also allow validators to connect only to each other and a set of additional full-nodes which you run, and only allow untrusted nodes to connect to those full-nodes. But this is probably overkill.