temporarily disabled aws binder due to bitcoin mining

[scottyhq]

@rabernat @jhamman @TomAugspurger @consideRatio FYI I temporarily disabled the aws binder this morning due to ongoing bitcoin mining (cpuminer-sse2 running on continuously on ~10 pods for the last week. basically someone has either set up a script that highjacks a binder-enabled repo to run their own code or manually starts a script once a notebooks server starts. since access is currently anonymous / tied to a repo rather than a specific github account there is nothing stopping people from doing this)

i don't think the solution is to ban specific repos because that could get tedious. just look at the list of recent PRs for mybinder.org related to security https://github.com/jupyterhub/mybinder.org-deploy/pulls?q=is%3Apr+is%3Aclosed !

if the aws binder comes back i think #151 is absolutely essential.

[rabernat]

Thanks so much for staying on top of this Scott!

Do you think the GCS binder is at risk for a similar exploit?

[manics]

Here's a related mybinder discussion: jupyterhub/mybinder.org-deploy#1778

[scottyhq]

Do you think the GCS binder is at risk for a similar exploit?

Definitely, the config is effectively the same right now.

There are two levels of auth. 1) just require the user (whoever follows a binder link) to input a github user id (+ no need to manage group membership like is done for the hubs, - now requires at a minimum someone has a github account). People could still definitely configure bot accounts or authenticated users could run these programs, but at least there is some level of accountability. 2) require group membership like we're doing on the jupyterhubs via auth0 rules (+/- much more restricted set of users)

[minrk]

Blocking repos is ~never useful for keeping out miners. Most miners on mybinder.org use the same images as try.jupyter.org. It's pretty trivial to mine from any compute environment with wide egress access (people ship mining binaries, which can be downloaded from e.g. github.com and launched with a few lines). The only thing that saves mybinder.org is that we don't offer enough compute to be worth spending much time circumventing our modest level of checks. If folks put ~any time into the cat and mouse of mining on mybinder.org, they are working for less than minimum wage.

The only robust way to prevent mining is to have an allow list of egress destinations, instead of a block list. This isn't currently feasible for mybinder.org and the miners that visit us don't put in enough effort to make it worth the switch, but it may be appropriate for pangeo. You do need a good way for legit folks to ask for egress access to be expanded, but once it's set up adding to it isn't much. @yuvipanda can speak to configuring JupyterHub with an https egress allow-list.

If you have any kind of required authentication (i.e. folks need some account), then banning is way easier and more practical, and I think the incentives for miners don't work out. mybinder.org being properly anonymous makes it harder for us.

Also happy to share with you folks the encrypted part of jupyterhub/mybinder.org-deploy#1778. It's pretty basic.

[scottyhq]

Well, even with Auth (#151 (comment)) we still have bitcoin mining going on. Just checked on things this PM and https://github.com/rx082 is running mining scripts. So it seems @minrk is on point with the suggestion, or it will be necessary to limit access to a specific Organization (github or other)...

for this particular case it was easy to login to the auth0 account, search for the userid under users and there is then an option 'Block User', but this manual intervention isn't sustainable long term.