search

mimblewimble / grin-wallet

Grin Wallet
Apache License 2.0
183 stars 133 forks source link

Wallet DOS/Spam Protection #44

Open yeastplume opened 6 years ago

yeastplume commented 6 years ago

Right now it's trivial to spam a wallet listener with millions of fake transactions, causing it to create spam outputs and creating a lot of hassle for the wallet owner. This needs to be mitigated somehow, probably starting with simple banning misbehaving IPs but will definitely need to become more foolproof.

yeastplume commented 6 years ago

638

ignopeverell commented 5 years ago

With the current approach, I'm not sure this is still a must-have. Assumingly people who can setup a wallet listener to run all the time will also know how to deal with this?

casey commented 5 years ago

If you squint a little bit, this looks like a SYN flood. One mitigation for SYN floods are SYN cookies, where instead of remembering half-open connections, you choose the TCP sequence number such that you can reconstruct the connection state from it. Then, when you get the ACK back, you can reconstruct the connection state from it, instead of needing to store something.

I'm not sure if this could be applied here. The outputs would have to be derived somehow from the incoming request such that the wallet doesn't need to remember them, and can recognize them if they later appear in a block.

rentenmark commented 5 years ago

Research...

IP rate limiting could be introduced at this layer but the more I think about this problem, I think it would be best handled with docker and docker compose.

My proposed solution here would be to use nginx as a reverse proxy and don't expose the wallet to the web, just the loopback interface. Docker can be used here to stand up an environment that contains

This would make for a nice experience for someone to stand up a server in local dev or cloud production deployment. As @ignopeverell says

Assumingly people who can setup a wallet listener to run all the time will also know how to deal with this?

This is correct but there is a non-zero amount of thought involved. In the spirit of pushing users into the pit of success, a decent default docker compose solution would go a long way. If this were to be heroku compatible, we would have one-click full node deployment with a web wallet.

sesam commented 5 years ago

this gives flexibility re software choice, if all grin users go via docker or are power users. build env, security etc. and Docker might be the easiest path to have regular users keep up to date with security updates.

0xmichalis commented 5 years ago

Orchestration frameworks and docker images take away a lot of the friction of deploying a secure environment and it's highly likely that merchants who will need to be running wallets 24/7 are going to invest in infrastructure but I wouldn't make an orchestration framework the only option of being able to secure yourself. I would add the extra layer of ratelimiting in Grin, if it's possible to add it seamlessly because belts and suspenders and because there are going to be deployments out in the wild that are going to be totally insecure.

rentenmark commented 5 years ago

Following up on this, I have created https://github.com/rentenmark/docker-grin it is still very much a work in progress but I thought I would put something out there and see what sticks.

0xmichalis commented 5 years ago

@rentenmark if you don't mind, please cross-post your work in https://www.grin-forum.org/t/how-do-you-deploy-grin-friends/1253

0xmichalis commented 5 years ago

there are going to be deployments out in the wild that are going to be totally insecure.

https://www.ccn.com/psa-if-you-mine-ethereum-youre-a-target-for-crypto-hackers/

According to the report over 4,700 devices, mostly made up of Geth mining rigs and Parity wallets, are the most vulnerable devices exposing their interface to intruders.