BitShares Forum
Main => General Discussion => Topic started by: emski on June 23, 2014, 08:50:55 pm
-
Imagine the following setup:
A delegate is running behind a firewall, being able to connect ONLY to specific peers list (relays, spread throughout the world) owned by the delegate's owner.
Each relay does not share the delegate's IP with its peers. (Is this implemented? Will it be?)
The result should be private delegate IP known only to the relays (which are owned by the same person).
A consequence should be that DDOS attack against any of the relays will not stop the delegate from producing blocks. In order to stop the delegate you should either DDOS its IP (which is unknown) or take down all the relays (GL with that).
Am I correct?
If hiding peer's IP (relay not sharing the delegate's IP) is already implemented - how to enable it ?
-
Imagine the following setup:
A delegate is running behind a firewall, being able to connect ONLY to specific peers list (relays, spread throughout the world) owned by the delegate's owner.
Each relay does not share the delegate's IP with its peers. (Is this implemented? Will it be?)
The result should be private delegate IP known only to the relays (which are owned by the same person).
A consequence should be that DDOS attack against any of the relays will not stop the delegate from producing blocks. In order to stop the delegate you should either DDOS its IP (which is unknown) or take down all the relays (GL with that).
Am I correct?
If hiding peer's IP (relay not sharing the delegate's IP) is already implemented - how to enable it ?
Not currently implemented, but should be easy to add.
-
Am I correct?
You are! Maybe in a few more weeks we can run this through TOR itself .. that would be AWESOME!
-
Am I correct?
You are! Maybe in a few more weeks we can run this through TOR itself .. that would be AWESOME!
Thor might add some lag which might downgrade delegate's score. For other clients it will be neat.
-
How about a progressive challenge? Upon connection to your node - have the client solve a quick hash of certain difficulty, within some time limit, based on number of connections left in the node. Should make it prohibitively more expensive for someone to organize an attack, regardless of what IP they come from.
-
How about a progressive challenge? Upon connection to your node - have the client solve a quick hash of certain difficulty, within some time limit, based on number of connections left in the node. Should make it prohibitively more expensive for someone to organize an attack, regardless of what IP they come from.
I've seen this work for some sites.
However a normal client needs to create several connections to function properly and it might not be feasible.
You cant enable it just for delegates as you will expose them (anyone connecting will know if he is connecting to a delegate).
I think hiding delegates is better approach. That will minimize the possibility of flood attack (of course high-grade internet connection will handle that also but it is more expensive to support).
-
how can yo ddos a machine without service?In fact delegate's node can deny all connect(syn request) request from p2p network.It can connect to p2p network only as a client.
来自我的 HUAWEI P7-L00 上的 Tapatalk
-
If you have Google vps they have whitelist and blacklist. If you kept track of peers and knew when Ddos starts you could Use a white list to approve connections? Bytemastxr, would this approach work?
-
I'm not running a delegate, however for my data collection server I found that you could just disable any incoming connection, and you can run with
bitshares_client --daemon --disable-peer-advertising