4 ms·

"Good purpose" is ambiguous. Even if you start with a "reasonableness standard" that is something like a "test particle" that is white, male, raised in Minnesot

"Good purpose" is ambiguous. Even if you start with a "reasonableness standard" that is something like a "test particle" that is white, male, raised in Minnesota to vaguely Christian parents born in the 80's watched Sponge Bob squarepants, it's less ambiguous. It means respecting the law, including ones you don't agree with. Including the laws that you think it would be good to break. This server sits there as a perfect vehicle from which to break the law. It's like someone leaving a fleet of getaway cars and guns, with tips on which banks are loaded right now left on the drivers side seat, and delivering it to a poor neighborhood, where it is rational to accept higher risk for a higher reward. There may be some who use it out of intellectual curiosity, and who are careful not to run afoul of any laws. LEOs will be of this type, I assume. I'm curious to know what is in that 8GB of tools that is included in every shell, for example. So for me the appeal would be a "safe" place to play with tools that I may have concern about even installing myself and what lists that adds me too. So in that sense its quite a good thing, it is freeing from risk of state involvement if your experiment/exploration goes wrong. Presumably all serious hacking attempts originate from a remote process anyway, as only a very silly/young/foolish hacker would try certain tools from their actual home IP address and personal laptop. So one argument for this service is that it reduces the demand for (coerced) botnet nodes. If you squint your eyes it's a similar argument for providing clean needles and methodone to a community, no questions asked. No, it's ugly that people use, but it's even uglier that people use and reuse/share needles to avoid detection. So while I agree it's probably a honeypot, there is also a sound argument for it to exist, legitimately, as a public service - a hacker's hamsterdam.

MichaelCollins 4y ago
> with tips on which banks are loaded right now left on the drivers side seat I don't think they're going that far (it doesn't come with a list of profitable organizations to hack.)
derefr 4y ago
That wasn't really my point. It's clear from the feature-set what people are intended to use the service for. My point was — without tracking users, how do you ensure quality of service for this system, when someone could just generate 10k distinct SSH keys (= distinct "accounts" in this system) to run their botnet with, and so consume all your resources with purely their traffic? (Where "a botnet" here is just standing in as an example of a use-case that requires as many nodes as possible, rather than being satisfied with just one. Could be a distributed web scraper; could be a crypto-mining pool; etc.) If you're not requiring some kind of user registration that does enough KYC to deduplicate registration attempts — and you're not tracking usage with fine-enough granularity to be able to surface + ban people who are "taking more than their fair share" — then this isn't going to be of benefit to the entire hacker community, but rather the whole thing is going to be gobbled up by the first person willing to write a script to do so. It's like making a large donation to a community in a war-torn developing nation, where as soon as you leave, the whole thing gets extracted out into the coffers of the largest local warlord. IMHO doing this model correctly would necessitate something closer to the "a real person's going to manually verify your sign-up" process of e.g. https://www.nearlyfreespeech.net/signup/signup https://www.nearlyfreespeech.net/signup/signup.
- javajosh 4y ago
  Oh, well by misunderstanding your point I stumbled on what is, IMHO, a more interesting point. In theory its relatively straightforward to develop a "1 human per process" heuristic for a service like this, especially if you reserve the right to observe and interact with users at any time (which this service certainly does).
  - derefr 4y ago
    Doing any interactive external observation would put a lie to the claim that "all data & traces will get wiped" — since there would then be "traces" (in the sense of "trace evidence" — https://en.wikipedia.org/wiki/Locard%27s_exchange_principle https://en.wikipedia.org/wiki/Locard%27s_exchange_principle) left on the sysadmin-observer's workstation, that would have to be wiped in turn. (And which are unlikely to be, because the sysadmin is likely also the developer, and a DevOps workstation is usually persistent.) For that claim to actually be true, the system has to be hermetically sealed against outside observation by any other than the user themselves. (Compare/contrast: the claims of a few VPN service providers, that their service is implemented effectively statelessly, in diskless + memory-constrained ASICs on network switches, such that there's no ability even in theory for the machine itself to keep metrics on which user accounts are responsible for which kinds of upstream traffic flows; such that a state actor who wanted to know that would be stuck either replacing the hardware [and so extracting the credential store out of the TPM of the original hardware] or MITMing both sides of the VPN box and doing traffic analysis to match flows.) IMHO, it's probably very unlikely that the claim is true — but it's interesting and fun to try to threat-model a service that does try to make that guarantee. Also, separately: > In theory its relatively straightforward to develop a "1 human per process" heuristic for a service like this You're forgetting that these accounts aren't strictly intended for use by humans, but rather scripting the system is an accepted (and encouraged!) use-case. Which means that you can't differentiate one user "botting" N accounts, running the same script (presumably bannable); from N users each "botting" their own single account by using the same popular open-source script (perfectly legitimate and protected!) This, by the way, is the reason that most VPS providers outright ban the deployment of certain types of software, e.g. IRC bouncer bots: it's impossible to tell whether N deployments of such a bot are N users intentionally deploying the same open-source bot, or one user (with N stolen user credentials) deploying a botnet that uses IRC for command-and-control. So they just make the assumption that such deployments are always malicious, and refuse the business of anyone who has a non-malicious use-case for such deployments.

MichaelCollins 4y ago

> with tips on which banks are loaded right now left on the drivers side seat I don't think they're going that far (it doesn't come with a list of profitable organizations to hack.)

derefr 4y ago

That wasn't really my point. It's clear from the feature-set what people are intended to use the service for. My point was — without tracking users, how do you ensure quality of service for this system, when someone could just generate 10k distinct SSH keys (= distinct "accounts" in this system) to run their botnet with, and so consume all your resources with purely their traffic? (Where "a botnet" here is just standing in as an example of a use-case that requires as many nodes as possible, rather than being satisfied with just one. Could be a distributed web scraper; could be a crypto-mining pool; etc.) If you're not requiring some kind of user registration that does enough KYC to deduplicate registration attempts — and you're not tracking usage with fine-enough granularity to be able to surface + ban people who are "taking more than their fair share" — then this isn't going to be of benefit to the entire hacker community, but rather the whole thing is going to be gobbled up by the first person willing to write a script to do so. It's like making a large donation to a community in a war-torn developing nation, where as soon as you leave, the whole thing gets extracted out into the coffers of the largest local warlord. IMHO doing this model correctly would necessitate something closer to the "a real person's going to manually verify your sign-up" process of e.g. https://www.nearlyfreespeech.net/signup/signup https://www.nearlyfreespeech.net/signup/signup.

javajosh 4y ago
Oh, well by misunderstanding your point I stumbled on what is, IMHO, a more interesting point. In theory its relatively straightforward to develop a "1 human per process" heuristic for a service like this, especially if you reserve the right to observe and interact with users at any time (which this service certainly does).
- derefr 4y ago
  Doing any interactive external observation would put a lie to the claim that "all data & traces will get wiped" — since there would then be "traces" (in the sense of "trace evidence" — https://en.wikipedia.org/wiki/Locard%27s_exchange_principle https://en.wikipedia.org/wiki/Locard%27s_exchange_principle) left on the sysadmin-observer's workstation, that would have to be wiped in turn. (And which are unlikely to be, because the sysadmin is likely also the developer, and a DevOps workstation is usually persistent.) For that claim to actually be true, the system has to be hermetically sealed against outside observation by any other than the user themselves. (Compare/contrast: the claims of a few VPN service providers, that their service is implemented effectively statelessly, in diskless + memory-constrained ASICs on network switches, such that there's no ability even in theory for the machine itself to keep metrics on which user accounts are responsible for which kinds of upstream traffic flows; such that a state actor who wanted to know that would be stuck either replacing the hardware [and so extracting the credential store out of the TPM of the original hardware] or MITMing both sides of the VPN box and doing traffic analysis to match flows.) IMHO, it's probably very unlikely that the claim is true — but it's interesting and fun to try to threat-model a service that does try to make that guarantee. Also, separately: > In theory its relatively straightforward to develop a "1 human per process" heuristic for a service like this You're forgetting that these accounts aren't strictly intended for use by humans, but rather scripting the system is an accepted (and encouraged!) use-case. Which means that you can't differentiate one user "botting" N accounts, running the same script (presumably bannable); from N users each "botting" their own single account by using the same popular open-source script (perfectly legitimate and protected!) This, by the way, is the reason that most VPS providers outright ban the deployment of certain types of software, e.g. IRC bouncer bots: it's impossible to tell whether N deployments of such a bot are N users intentionally deploying the same open-source bot, or one user (with N stolen user credentials) deploying a botnet that uses IRC for command-and-control. So they just make the assumption that such deployments are always malicious, and refuse the business of anyone who has a non-malicious use-case for such deployments.