Protection from denial-of-service attacks for delegates

[Method-X]

 

[wackou]

I'd like to offer a 1000 BTS bounty for a member of the chinese community to translate this post in chinese and post it to the relevant subforum.

No one?

Bump! Is the 1,000 BTS still up for grabs?

yep, still up for grabs! No google translate, though, this is for a native chinese translation, of course

[roadscape]

I'd like to offer a 1000 BTS bounty for a member of the chinese community to translate this post in chinese and post it to the relevant subforum.

No one?

Bump! Is the 1,000 BTS still up for grabs?

[wackou]

I'd like to offer a 1000 BTS bounty for a member of the chinese community to translate this post in chinese and post it to the relevant subforum.

No one?

[jsidhu]

Would we be able to access via a dns passed thru say cloudflare so the ip is not known? I want to see if delegates can run webservices from the wallet allowing things like social login and sso via mobile apps

[Samupaha]

Voted for you!

[cusknee]

The security of our system should be a top priority. 

[mf-tzo]

   from me and will definitely vote for you today! Anything relating to security is extremely important!

[merlin0113]

I'd like to offer a 1000 BTS bounty for a member of the chinese community to translate this post in chinese and post it to the relevant subforum. I believe security is an important issue and would like to see if the chinese community thinks I should be voted as a delegate to work on those issues.

c.c. to wildpig

来自我的 M040 上的 Tapatalk

[wackou]

I'd like to offer a 1000 BTS bounty for a member of the chinese community to translate this post in chinese and post it to the relevant subforum. I believe security is an important issue and would like to see if the chinese community thinks I should be voted as a delegate to work on those issues.

[onceuponatime]

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. 

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.)

I don't know why you haven't been voted in yet. Security matters!!!!

[cube]

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. 

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.)

Yes, having a backbone for redundancy would help.  But the delegates cannot be complacent.  They have to do their part too.

[karnal]

Should work fine, especially after tuning torrc to consider bitshares-related connections long-lived (it'll then choose only reliable [high uptime] relays).

I mean, you can do VoIP over tor with hidden services and get <1000ms latency, and that's with hidden services which tend to be slower.

[xeroc]

delegates are time sensitive .. they have a window of less than 10 secs to transmit the block to the next delegate .. not sure if that will work reliably over tor ..

[karnal]

How about running the delegate through a proxy, namely, Tor?

Proxy support at the moment appears to be nonexistant, transparent proxying might be possible though ..

[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. 

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.)

[cube]

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. 

[emski]

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.

[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?

[emski]

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.

[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! )

[roadscape]

 

Btw, is Bitcoin susceptible to a similar attack?

[liondani]

yep 

[cass]

Why you still not voted in?

Great work!

 

Come on, let us wackou get into 101 delegates asap!!!

[lovejoy]

 

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

I support you!

[xeroc]

* xeroc ¯\_(ツ)_/¯ fully supports this!

[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.

  Please vote in:  btstools.digitalgaia

[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.