Botnet resistance for pool operators

[mikegogulski]

Some disconnected but hopefully useful thoughts here for thoughtful pool operators.

- When a single account connects and hashes for more than 10 minutes with more than 50 IP addresses, disconnect and ban that account and IP for a day
- When a single account connects and hashes for more than 10 minutes from >10 IP addresses with CPU-level hashrates, as above
- When a set of accounts/workers connect meeting above criteria and with identical payout addresses, disconnect and ban for a day

Why?

1: I think anyone running a mining cluster or even a set of mining clusters is not going to exceed the first criterion. At the very least, they are going to have split things across multiple IPs (for various reasons, including risk-avoidance) and across multiple accounts (for accounting purposes)

2: I think it's reasonable to assume that large influxes of CPU-level hashrates to single accounts are indicative of botnet activity. (This includes, for example, the case of the person at the Australian Broadcasting Company recently featured as running miners on spare cycles across the enterprise).

3: Aggregate of the above.

Meta-why?

I trust Tycho. I trust Slush. I trust Luke-jr, etc. I don't trust random people who show up with X gazillion H/s across thousands of IP addresses. Neither should you.

Pool manipulation is a potentially big issue with the size of the network today, especially when coupled with the effects we have seen when DDoS attacks against pools have been more or less successful.

Peace,
Mike

[Fletch]

While I agree that it makes sense for pool maintainers to implement some kind of anti-botnet protection, what's stopping botnet operators from just setting up their own pool?

[mikegogulski]

While I agree that it makes sense for pool maintainers to implement some kind of anti-botnet protection, what's stopping botnet operators from just setting up their own pool?

Nothing, but their profitability is limited by their ability to attract hash power, which in turn might be limited by their policies.

[hugolp]

While I agree that it makes sense for pool maintainers to implement some kind of anti-botnet protection, what's stopping botnet operators from just setting up their own pool?

Nothing, but their profitability is limited by their ability to attract hash power, which in turn might be limited by their policies.

Also, woundnt that expose them? Can you create an anonymous pool?

[Sukrim]

Also, woundnt that expose them? Can you create an anonymous pool?

Of course, if you set up your own, you don't even need a frontend. Just wait till p2p-ppols come up and you have perfect self-contained pools that mine for a single Bitcoin address. A "botnet pool" would then just not pay out anything back to miners.

Also you can aggregate getworks from existing pools and relay them to miners as much as you want to. This makes it seem as if 1000 4 MH/s CPU miners are hashing with 4 GH/s from a single IP. It might not scale that well, as it requires far more getwork requests than with GPUs (and might get you banned or at least looking suspicious). You can aggregate getworks from many pools at once though as well if you need/want to.

1) can be circumvented by a single server collecting + relaying getworks
2) the same
3) might hit people who set up your pool as backup pool, letting a miner run with low priority in your pool

Also:
Pool operators get their income from a high hash rate! Why should they ban anyone who submits valid shares?

[mikegogulski]

Pool operators get their income from a high hash rate! Why should they ban anyone who submits valid shares?

I'll suggest that you are right, but not *entirely* right. The other factors which are included in a pool's profitability (and longer-term viability) include:

- payout structure
- reliability
- customer (ie worker/miner) service
- reputation

Putting up botnet resistance will be a reputation bonus for pool operators who do so, at least among a certain subset of legit miners. At the same time, banning botnets from one's own pool might decrease load and thereby improve reliability.

What are the actual numbers? No idea. I suspect they're big enough to think about, though, especially as pool operators now seem to be in a race to the bottom to attract hash power. Quality differentiation becomes quite important when quantity differentiation falls to the side.

[xtoro]

Regsiter your workers with not only a workername and passwork, but also with an IP address.  You can have 100 machines at home mining, but they will all have the same internet-facing IP address from your ISP Modem's NATing.

Block all other ports and unregistered IP addresses.

Done.

Am I missing something here?  Why would this way not work?

[MrSam]

Mike,

You have a valid point and i have been wrapping my head around this for some time. I've been playing with iptables -m limit and other ways to try and verify maxconnections per ip and range. But the problem is that there is often a major count of connections from legitimate workers.

I also have been trying to match the connection count to the submitted (valid) shares in the shares table, to see if i can find a pattern there.

The best thing would be to set up some kind of honeypot and shared blacklist amongst pool owners, but i guess these days it's more about competition.

[mikegogulski]

But the problem is that there is often a major count of connections from legitimate workers.

Connections per worker by itself can't be a useful metric. I think I have about 45 workers connected to you on two accounts spread across 2 IP addresses (one for my colo, one for my kitchen).

Trying to imagine what botnet scenarios are likely and how to fingerprint them...

1. CPU zombie miners, home computers: <= 3 CPU-level workers per IP address, many IP addresses, all on a single worker account
2. CPU zombies, corporate environment: any number of CPU-level workers from a single IP address, all on a single worker account
3. GPU zombies, home: <= 4 GPU-level workers per IP address, many IP addresses, all on a single worker account
4. GPU zombies, corporate: any number of GPU-level workers from a single IP address, all on a single worker account

All but #4 are probably reasonable rules for identifying botnet operators. #4 doesn't work, though, since a botnet infecting a single corporation with mining-capable GPUs is going to appear similar to a large-scale mining operation behind NAT.

#1 and #3 could be gamed by the botnet operator setting up a proxy so that the workers all seem to be in the same place. #1 then looks like #2 (still bannable) and #3 looks like #4 (confusion!).

Additionally, the operator who sets up many separate accounts with the pools they use could evade this kind of heuristic. Perhaps it is to combat such things that I have seen some pools requiring a CAPTCHA solve to create a new worker, even for a logged-in user.

[antares]

total bullshit - while I agree that botnets should be avoided, I do have myselft about 165 worker machines with CPU and GPUs working. These machines pull out 11MH/s on CPU and 20MH/s on GPUs each. My machines would classify for all of your rules, but they still are not a botnet.
It might seems inefficient to run that amount of machines with stats that bad, however, they run for generator high load stability testing right now, and they simply have to burn electricity.(just because I do know that the next post will state how inefficient this is and all that fuck all over again)

[Grant]

Perhaps a more capitalist approach would be: simply charge users a daily fee per IP address. That way you also get inefficient miners/botnets out of the system.

[speeder]

Perhaps a more capitalist approach would be: simply charge users a daily fee per IP address. That way you also get inefficient miners/botnets out of the system.

I like that

[mikegogulski]

total bullshit - while I agree that botnets should be avoided, I do have myselft about 165 worker machines with CPU and GPUs working. These machines pull out 11MH/s on CPU and 20MH/s on GPUs each. My machines would classify for all of your rules, but they still are not a botnet.
It might seems inefficient to run that amount of machines with stats that bad, however, they run for generator high load stability testing right now, and they simply have to burn electricity.(just because I do know that the next post will state how inefficient this is and all that fuck all over again)

Fair enough. You'd be a false positive on heuristic #2 and possibly on #4 (which is already noted as problematic).

Other than saying "total bullshit" (which is important in and of itself, anyway), any ideas?

Someone mentioned IP registration, but I think that's a non-starter since a) bad guys can register the external IP of a home NAT or corporate firewall anyway and b) huge parts of the mining public are on dynamic IPs.

I don't think Grant's proposal work either, though I haven't thought hard about the economics of it. Pool operators in general are already taking a percentage of generated blocks. The idea of "welcome to blah blah mining co, ltd. please upload your proof-of-age documents and enter your credit card information for recurring billing" is totally repellent to me. Also, getting "inefficient" miners out of the system isn't a goal I'd share. Antares, for example, can do what he likes with his hardware and power.

Maybe this is all moot anyway. The smart botherder wanting to mine for Bitcoin might as well set up their own pool server (on someone else's machine(s), of course!), and avoid whatever countermeasures altogether.

[Graet]

heh, we have had 2 botnet operators come to us at ozco.in asking for help to setup private pools.
seems like there are smart ones out there