Author Topic: Protection from denial-of-service attacks for delegates  (Read 7286 times)

0 Members and 1 Guest are viewing this topic.

Offline wackou

I'd recommend every delegate to have at least 1 "relay" node in standby mode (or a manually activated backup delegate) that can be activated in case of an attack.

As the cost of setting up a relay node is minimal and its configuration trivial I do not consider this an issue.

A simple and effective solution.  +5%

I fully agree, hence one of the by-products of setting up the backbone is for me to expand the functionality of the bts_tools package to easily manage multiple nodes, of possibly different types (eg: 1 delegate, 2 relays, etc...) from the same panel. This is already somehow possible, but the implementation under the hood is not really up to snuff.

I would like also to be very careful to not give a false sense of security to other delegates, by having them rely on the backbone and then decide they're safe. I believe that laziness and self-contentment is probably the worst problem one can face security-wise, and good security can only come with delegates being proactive and taking all measures possible to secure their servers. I do not claim that the backbone is the ultimate solution, just one more tool in a toolbox that each delegate should build for himself (along with firewalls, relay nodes, thoughtful arguments on the command-line, etc.)
Please vote for witness wackou! More info at http://digitalgaia.io

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
This looks like a reasonable solution.
However I'd like to point out that a delegate should NOT rely only on it.
As these nodes are public and known they are vulnerable to the same attack.
If these nodes are taken down all delegates exclusively using this solution will be affected.


Well said! And should be emphasized.

I'd recommend every delegate to have at least 1 "relay" node in standby mode (or a manually activated backup delegate) that can be activated in case of an attack.

As the cost of setting up a relay node is minimal and its configuration trivial I do not consider this an issue.

A simple and effective solution.  +5%
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
As the cost of setting up a relay node is minimal and its configuration trivial I do not consider this an issue.

Is this going to be the next script for delegates you make? :)

You dont even need a script... just a commandline argument (--disable-peer-advertising ) would suffice for the relay node.
In case of an attack you just connect your delegate to that node.
Then the attacker should start locating your node again but this cannot happen before your next produced block.

Offline BunkerChainLabs-DataSecurityNode

As the cost of setting up a relay node is minimal and its configuration trivial I do not consider this an issue.

Is this going to be the next script for delegates you make? :)
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
This looks like a reasonable solution.
However I'd like to point out that a delegate should NOT rely only on it.
As these nodes are public and known they are vulnerable to the same attack.
If these nodes are taken down all delegates exclusively using this solution will be affected.

I'd recommend every delegate to have at least 1 "relay" node in standby mode (or a manually activated backup delegate) that can be activated in case of an attack.

As the cost of setting up a relay node is minimal and its configuration trivial I do not consider this an issue.

Offline wackou

Btw, is Bitcoin susceptible to a similar attack?

bitcoin miners are not vulnerable, as they are not known in advance, so there's really no way to hit them. Mining pools on the other hand are vulnerable, and I remember last year that some pools used to go down every now and then due to DDoS attacks. This doesn't seem to occur so much anymore as pool operators now run them on top end hardware and/or DDoS protected VPS providers (not too sure how it works for them) although I can't say for sure, as I haven't been mining in a long time (thank god for DPoS! :) )
Please vote for witness wackou! More info at http://digitalgaia.io

Offline roadscape

 +5% +5%

Btw, is Bitcoin susceptible to a similar attack?
http://cryptofresh.com  |  witness: roadscape

Offline liondani

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

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
Why you still not voted in?

Great work!

 +5%

Come on, let us wackou get into 101 delegates asap!!!
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline lovejoy

  • Sr. Member
  • ****
  • Posts: 431
    • View Profile
    • Cryptofresh
  • BitShares: lovejoy
 +5%

Amazing work you have done thus far, and a great proposal!

I support you!


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
* xeroc ¯\_(ツ)_/¯ fully supports this!

Offline onceuponatime

I have voted for you.

It is extremely important that we be proactive and prepared in all we are setting out to accomplish.

The work you have done and are doing is much appreciated.

+5%  Please vote in:  btstools.digitalgaia
« Last Edit: February 24, 2015, 06:54:37 pm by onceuponatime »

Offline wackou

There is currently an attack that is possible on the BitShares network where an attacker could:
 - use timing of block propagations to discover which are the IP addresses of delegates
 - use a DDoS attack on those delegates to take them down

This has been described more in details in this thread

This can be easily thwarted by "hiding" the delegates and making sure that it is not possible to identify the source of a newly signed block. To this end, I propose the following solution:

http://digitalgaia.io/backbone.html

tl;dr: hide the delegates behind some public relay nodes. In this way, it looks like that all blocks originate from the backbone and it is not possible to know who signed them. At first I would like to have 2 nodes in the US, 2 in Europe and 2 in Asia.


How to make it happen?

Just vote for my delegate, btstools.digitalgaia (30% payrate), and as soon as it gets elected I will buy some VPS instances for the backbone nodes and start working on setting them up, as well as developing the software required to manage those nodes.

Note that I would also set up seed nodes / chain servers, which can make initial sync to the network faster, as well as allowing nodes to get on the correct chain in case of a fork (by syncing with a chain server that's on the main fork, you also get on the main fork).


Criticism

Although a good start, this is not a perfect solution (yet!):

- Whoever runs the backbone nodes can perform the same attack on the delegates (although it is now limited to the person running the backbone nodes, instead of basically anyone simply connected to the network).

- The backbone itself can be DDoS'ed. In this case:
 - if delegates are only connected to the backbone, and the entire backbone falls, then they don't have connections anymore to the network. This can be mitigated by delegates starting to connect to normal nodes when they see that the backbone starts falling.
 - the delegates can also maintain their own set of relays instead of trusting the backbone's operator. This is more work (and more money spent on VPS), but you don't need to trust anyone else than yourself. Being able to run the software developed for the backbone would be a great help here, so even though a delegate doesn't plan on using the backbone, he could still benefit from it being developed.


Why you should trust me

I already am the author of the bts_tools python package (GitHub, BitSharesTalk), which help delegates monitor their own running instance, and I'd like to expand the functionality of the tools so as to also be able to manage a group of nodes or specialized instances of nodes in the BitShares network. In particular, I'd like them to be able to manage a configuration of seed nodes + backbone nodes as described previously.


Is this going to be a cost for the blockchain forever?

For now, I request a 30% delegate, as this would cover the cost of the VPS instances and my time for developing the software and maintaining the backbone.

Assuming that the backbone is running and fully operational, the following can happen in the future:

 - I further investigate ways to make the backbone itself completely DDoS resistant, and/or try to make it autonomous and able to replace fallen nodes automatically with nodes provided by trusted members of the community. If this is achievable, and the backbone can self-sustain itself, then my delegate's position would not be required anymore.

 - Instead of being paid as a delegate, I can monetize the backbone service by asking delegates wanting to use it to pay me directly for the service, as well as other ways of securing a delegate that I might come up with. Initially, I think that making it available for everyone is beneficial for the entire network, though, hence the delegate's position.


Conclusion

I'd like to be elected as a 30% paid delegate to implement a solution for DDoS protection for delegates, and potentially investigate more avenues in order to enhance the security of the BitShares network.

I'd also be interested to hear feedback on whether people think that the backbone is an interesting and effective solution to the DDoS problem, and if not, what could be done instead.
Please vote for witness wackou! More info at http://digitalgaia.io