Author Topic: The potential for DDoS in DPOS  (Read 4888 times)

0 Members and 1 Guest are viewing this topic.

Offline wackou

if somebody DDoS attacked all seed-nodes simultaneously (the IP address of them are public)
in a situation like yesterday with the fork problems (it could be an attack-scenario from a group of bad/evil delegates also in future...)
what would happen then? How would delegates manage to resync the chain after the update?
Someone that is still connected to the network would just have to post their IP:port and then people could add this node manually (using network_add_node). A bit more cumbersome, but not really worrying. Also, the more seed nodes become available, the harder it is to DDoS all of them at once, given that they are usually contributed by various people all over the world

And what would happen if yesterday somebody DDoS attacked our bitsharestalk forum?
How would we get to consensus about the minority chain fork, without delaying to much cause luck of communication?

That would be much more annoying... I think the key word here, both in the case of seed nodes and communication channels is: redundancy. That's where this thread comes into play: https://bitsharestalk.org/index.php?topic=11749.0

Try DDoS-ing Skype (Microsoft) or Gmail (Google)  :P
Please vote for witness wackou! More info at http://digitalgaia.io

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Maybe a stupid question...

if somebody DDoS attacked all seed-nodes simultaneously (the IP address of them are public)
in a situation like yesterday with the fork problems (it could be an attack-scenario from a group of bad/evil delegates also in future...)
what would happen then? How would delegates manage to resync the chain after the update?
And what would happen if yesterday somebody DDoS attacked our bitsharestalk forum?
How would we get to consensus about the minority chain fork, without delaying to much cause luck of communication?
What communication channel should we follow in future in case of such scenarios? Something like a plan B on Crisis situation's like yesterday....

Offline VoR0220

Will keep that in mind. Thank you.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I'd rather go for the backbone approach described in http://digitalgaia.io/backbone.html
cheaper .. less complicated .. still relatively secure ..

Offline VoR0220

When you say "backup delegate" do you mean the next one in round? Or do you mean that same delegate performs a process whereby they can continue to solve blocks? I see that this is probably not a big problem, but I have a feeling that this will turn up down the road, especially if there is frequent contact with the delegate in a DAC.
a delegate can install the private key for that delegate on multiple machines in parallel .. the maintainer just has to make sure that only one machine produces a block at any time ... theres a extra flag to enable block production ... so if your delegates is DDOS and a signed block cannot possibly reach the network .. you can shut that machine down and switch over to a different machine .. on a different IP .. on different hardware .. possibly in a different country .. connected to the internet via different providers ... and continue signing blocks from there ..

no need to "talk" to other delegates ...

by the way .. for the network it is much worse if delegates produce multiple blocks (on different machines) .. which results in a 'soft fork' for 10 secs ... than if a delegate just misses a block .. that's not a big deal

Interesting. When it comes to my project, my concern comes with potential scheming partners of delegates that may try to knock other delegates out of the network. A thought just occurred to me. Would it be worth integrating a form of relay setup that relied on the other delegates? Picture this. A function sets up an interconnected relay of all the delegates, trading IP addresses with each other according to a randomization list of who will take whose address and sets that in for the round. My concern in crafting this is not be that an attacker take down the network (I would think that would be really hard to do) but whether it would stop an attacker from singling out a specific delegate in an attack. Is this doable/feasible?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
When you say "backup delegate" do you mean the next one in round? Or do you mean that same delegate performs a process whereby they can continue to solve blocks? I see that this is probably not a big problem, but I have a feeling that this will turn up down the road, especially if there is frequent contact with the delegate in a DAC.
a delegate can install the private key for that delegate on multiple machines in parallel .. the maintainer just has to make sure that only one machine produces a block at any time ... theres a extra flag to enable block production ... so if your delegates is DDOS and a signed block cannot possibly reach the network .. you can shut that machine down and switch over to a different machine .. on a different IP .. on different hardware .. possibly in a different country .. connected to the internet via different providers ... and continue signing blocks from there ..

no need to "talk" to other delegates ...

by the way .. for the network it is much worse if delegates produce multiple blocks (on different machines) .. which results in a 'soft fork' for 10 secs ... than if a delegate just misses a block .. that's not a big deal

Offline VoR0220

in order to figure out a delegates IP you need to have plenty of nodes on the network and do timing correlations of newly signed blocks for each delegate ..
and connect to the nodes that transmit the block to your first ...
some nodes do not allow to be connected to but only allow self-initiated connections ...

furthermore, switching to a backup delegate takes less than 10 secs and the result would be that the attacker needs to start all over ...

When you say "backup delegate" do you mean the next one in round? Or do you mean that same delegate performs a process whereby they can continue to solve blocks? I see that this is probably not a big problem, but I have a feeling that this will turn up down the road, especially if there is frequent contact with the delegate in a DAC.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
in order to figure out a delegates IP you need to have plenty of nodes on the network and do timing correlations of newly signed blocks for each delegate ..
and connect to the nodes that transmit the block to your first ...
some nodes do not allow to be connected to but only allow self-initiated connections ...

furthermore, switching to a backup delegate takes less than 10 secs and the result would be that the attacker needs to start all over ...

Offline VoR0220

The problem here is that I'm coming up with a project that runs generally on the BitShares DPOS consensus mechanism (have yet to post it, but it should be available soon). I'm curious if there is a way to implement something for the Delegates that would allow them to automatically block off a DDoS attack or help mitigate it in some manner so that delegates can continue to process transactions and not have to worry about being booted off. Something that would not require any additional hardware implementations or outsourcing of services. Is this possible?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
you can secure your delegate by something like this:
http://digitalgaia.io/backbone.html

i don't see it as a big thread .. because it's quit easy to "activate" a backup delegate machine if you main one is DDOSed .. and yu can hide it behind proxy nodes


Offline Riverhead

Any IT delegate worth their salt will have failover solutions, even if it's just their home or work PC. I have two failovers on different hosting companies so in total there are three hosts from three vendors. It's not that I'm spending a lot of money on VPS services either. Since block signing is a lightweight process it's easy to have failovers running on other servers you're already using for other things.

Detecting a DDOS attack before you start missing blocks is useful as well. A simple ping monitor of the delegate and a trigger a notification if ping times start to sky rocket. If all goes well you can get in in time to lock the wallet before unlocking your failover. Otherwise, in the case of most VPS hosts, you can shutdown the host under attack via their dashboard web console.

So while DDoS is a real possibility it would be like stepping on a jellyfish. This is different from DDoS'ing a mining pool because all the clients are usually configured to connect to a few known IP's. Take them out and the pool is hosed. With DPoS who the heck knows where the delegate will pop up next :) .
« Last Edit: December 10, 2014, 11:44:32 am by Riverhead »

Offline svk

Isn't that just a good thing? It means you won't risk double-signing blocks when you start signing on your standby server. I'd want to shut down the server that's under attack anyway, and you should have a backup of your delegate wallet in a secure place so you can easily transfer the delegate to a new machine.

That relies on everyone having a standby server. Imagine if a DDOS just swept over each delegate one by one waiting for them to stop responding; if the hosting companies all took them off the network, and there were no standby servers, you'd have a period of time where all transactions stopped while the dead delegates were down voted.

Actually, if all transactions stopped, no votes could ever be cast, since they take the form of a transaction?

Yes, I'm making the assumption that each delegate has taken some precautions in order to be able to launch a standy server using the same delegates.

Yes no transactions mean no votes, so if all delegates were taken out the network would grind to a halt until at least one delegate came back online, who would then sign one block every 16.833 minutes on average.
Worker: dev.bitsharesblocks

Offline monsterer

Isn't that just a good thing? It means you won't risk double-signing blocks when you start signing on your standby server. I'd want to shut down the server that's under attack anyway, and you should have a backup of your delegate wallet in a secure place so you can easily transfer the delegate to a new machine.

That relies on everyone having a standby server. Imagine if a DDOS just swept over each delegate one by one waiting for them to stop responding; if the hosting companies all took them off the network, and there were no standby servers, you'd have a period of time where all transactions stopped while the dead delegates were down voted.

Actually, if all transactions stopped, no votes could ever be cast, since they take the form of a transaction?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline svk

Svk pretty much said it. Since delegates are just block signers and not miners it's easy to abandon a host under attack and switch to the failover. For a ddos attack to be effective they'd need to hit literally dozens of delegates at the same time. The network would then slow down for a few minutes while the delegates brought up new hosts.

It might be worse than you think. Typically hosting companies will actually remove the server under attack from their network in order to preserve their other customer's service. Then the control is out of the hands of the delegate under attack.

Isn't that just a good thing? It means you won't risk double-signing blocks when you start signing on your standby server. I'd want to shut down the server that's under attack anyway, and you should have a backup of your delegate wallet in a secure place so you can easily transfer the delegate to a new machine.
Worker: dev.bitsharesblocks