search

storj-archived / core

Deprecated. Implementation of the Storj v2 protocol for Node.js.
https://storj.io
Other
395 stars 88 forks source link

Tunnel connection abuse #52

Closed littleskunk closed 7 years ago

littleskunk commented 8 years ago

Slack user blackduck and I had some bad ideas

As cheater we would like to get as many contracts as possible. Our plan to abuse tunnel traffic:

The easy way: Setup a second VM and install farmer-cli. Allow 1000 tunnel connection but don't share any drive space. The only reason for this setup is to slow down everyone else to allow my first vm to get more contracts. It is very easy to limit only the bandwidth of the second VM. My own farm VM would still run with full speed.

The radical way: Allow 1000 nodes to run fullspeed but manipulate the content. Lets drop some packages or modify them. Ofc not the first connection test message because that would invalidate the tunnel. Every other manipulation would result in a invalid signature but the tunnel would still be open right? 1000 farmer would get error messages and not any contract but they will keep the tunnel connection open to me.

super3 commented 8 years ago

Basically sounds like a generic Sybil attack to me. Comes to what percentage of nodes on the network are honest. If you use more than one tunnel, then the possibility of using one of these malicious tunnels reduces to a random distribution.

Ideas: 1) Make attacks expensive. Allow users to sort nodes by SJCX or BTC, and/or coin-age. Starting out I'll probably choose an node with more money, and ignore all the 1000 AWS 0 balance nodes. 2) I believe in the currently implementation(not 100%) you would use the nearest neighbor tunnel. So the tunnel with the pubkey closest to yours. Rather than having hundreds or thousands of users trying to connect to these bad tunnels, you would only have a small chance of connecting if the bad tunnel was "near" to your node. 3) Just like we do audits to make sure files are there, we can do something similar to tunnels. We can periodically ask other users to test our tunnels. We should quickly find out that these tunnels suck and we should go elsewhere.

littleskunk commented 8 years ago

1.) My tunnel abuse node would use the same payout address like my main node. Hopefully you will find a hugh amount of SJCX there. (Otherwise the tunnel abuse would be useless)

2.) Not every node will allow tunnel connections and the few that does will allow only 3 connection (can be changed by the farmer). Let me add 3000 nodes sharing 0 MB to block 3000 neighbor tunnel. That needs some time to implement because I don't want to waste CPU time. I only need to copy the tunnel code and remove everything else. That way my tunnel will be able to abuse 1000 other nodes. 1000 neighbor are blocked and can't offer any tunnel.

3.) Sounds good to me. Don't forget a timeout to catch the easy way (very slow tunnel connection)

super3 commented 8 years ago

@gordonwritescode Any additional thoughts on this? Seems like the best way to handle it is just to test the tunnels.

lilyannehall commented 8 years ago

I don't know about having nodes who do not need tunnels to test tunnels, it seems like it would add an unnecessary amount of communication on the network. I tend to think that once payments are integrated with the tunneling, this might be as simple as having a pseudo-contract between tunneler and private node that defines payment in exchange for expected bandwidth and relayed contracts.

This would provide incentive to the tunneler to give relay preference to her tenants for storage contracts in exchange for a "finder's fee". At any point the tunneler receives either too many contracts to handle herself or contracts she is not interested in, she would offer them up to her tunnels before anyone else.

This might be a sufficient strategy to provide disincentive for blocking tunneled nodes from getting contracts. Bandwidth could be tested separately, but can be difficult to determine whether or not the tunnel is slow or the remote host.

I think that the primary concern is not necessarily the speed/bandwidth of the tunnel but rather ensuring that the tunneler is playing nice with contracts it receives. Having a sort of finder's fee seems like a decent way to solve that. Tunneled nodes might get the "leftovers" or less valuable contracts, but I think that's a pretty natural side effect of "beggers can't be choosers". If you want to place yourself at an advantage for receiving the best storage contracts, then take the necessary steps to make your node public.

super3 commented 8 years ago

I agree that incentives are the best way to go. My concern is more on detecting issues with tunnels

For example via the diagram: https://storj.github.io/core/tutorial-tunnel-connections.html

If tunnel E is having issue, does D have any other way to contact B to let him know that he can't reach him? Only B can detect issues, and change the tunnel. Can B just do periodic messages to D like nodes to make sure things are working ok?

lilyannehall commented 8 years ago

Nodes will send periodic messages anyway just as a result of participating in the network. I don't think we need to have a specific RPC sent on interval to test this. If B isn't able to talk to other nodes, eventually his routing table should become empty, signalling a leave event, in which case we can close the tunnel and try to establish a new one.

super3 commented 8 years ago

@bookchin @littleskunk Is this an issue we want to keep open?

lilyannehall commented 8 years ago

I would like to leave it open until it goes from discussion to feature and closed with a pull request and subsequent release. :)

I will read back through it and we can pick up the discussion again.

super3 commented 8 years ago

Cool. Just making sure its still an active issue.

CJClaude commented 8 years ago

Are we going to make this the general "abuse" scenario discussion or limit it Tunnel Abuse only?

Somehow feels like I'm abusing the system by having 64+ nodes running behind my firewall. Its like I'm buying 64 chances (and benefiting from it!) vs. a typical GUI user running a single drive area having 1 chance. Next box to come online will likely expand that to something like 256 nodes (if my purse.io orders ever get bought).

littleskunk commented 8 years ago

We have an example even if this looks more like an bug and not an abuse: https://github.com/Storj/core/issues/539

The tunnel client will not send OFFER anymore but keep the tunnel connection to the "bad tunnel server" open.

@CJClaude tunnel abuse only please. Running 64 nodes would be better here: https://github.com/Storj/core/issues/323

lilyannehall commented 7 years ago

The last referenced issue here has been closed (#539), so closing this.