Author Topic: DDOS prevention  (Read 3529 times)

0 Members and 1 Guest are viewing this topic.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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


Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
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 speak for myself and only myself.

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
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


Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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).

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Am I correct?
You are! Maybe in a few more weeks we can run this through TOR itself .. that would be AWESOME!

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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 ?