How resistant Cardano is to DDoS attack on slot leader?
I believe if the slot leader is brought down, there will be an empty block. There is a block every 20 seconds. So by taking out a slot leader things will be delayed by 20 seconds.
It looks like a pool operator has to run multiple frontend-nodes covering and protecting his main node.
Effectively the current Byron-Mainnet has 7 nodes (pools/slot leaders) but is accessible through much more IP-Addresses. This is a list of 90 addresses I know about, but it can be more or change over time ofc:
18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11
So this is either a pure AWS loadbalancer service, or this are already frontend-nodes covering the signing pool leader.
A good staking pool operator will also incur the expense for a solid DDOS-protection. Up to now, I haven’t seen any requirements checklist. Only the incentives strategy that an operator who doesn’t care about his uptime will lose revenues.
IMO this could create a problem, because as long as no noticeable DDOS attack occurs, pool operators who don’t invest in such protections will earn more, and can offer better revenues to stakers. So the staking crowd will choose and move to them. Then when a significant part of the network became weak&cheap, a DDOS attack will have a pretty heavy impact.
I also would suggest considering a pool-to-pool communication over IPv6. (either the whole sync as IPv6-only or at least one exclusive IPv6 frontend node per pool as absolute requirement) DDOS works because of the many badly maintained, cheap and old devices like printers, IOT-trash, SoHo-Routers and WindowsXPs behind of them.
Ofc there are other techniques ISPs can use to defend from attacks against their own infrastructure but don’t expect someone wanna talk about his defence mechanisms
Best of all is, that an adversary must attack a very significant number of different pool-nodes at the same time, and already have up&running his own pools (including someone’s stake)
AWS includes their regular DDOS free of charge with a server, but their premium offering is very expensive.
Cardano will be very resistant to such attacks, especially since the computational challenge done on pools will cut out the vulnerable.
Better get your processors revved up, and don’t skimp on that memory either Cardano does not require much but that doesn’t mean your servers won’t as they are the target for such attacks.
I think it depends on the situation. If you are staking by yourself from your computer. I think you may be more flexible to avoid the attacks, because you can just change your ip (connect through your phone or another wifi). Also the broadcasting of txs from the full nodes doesn’t include ip address from the original broadcaster (the staker), so the DDoS attack should have been lucky to ”see” you.
For the pool stakers, I think there is a lot of options (but they are not at a protocol level, because pool stakers run outside the protocol. The answer from @werkof seems pretty detailed.
The open ports that allowed the DDoS, possible volumetric floods or resource exhaustion, will still be open when you connect back into the Cardano network likely triggering the DDoS again.
Also, you are on a time constraint, expected to validate and report back to the network, won’t be happening when you are changing address and waiting to reconnect to the number of nodes required for running a pool, private or public.
Changing IP address will help, don’t misunderstand, I’m doubtful that coordinated DDoS attacks on Cardano will be based around fortune though.