Bitcoin Forum
December 10, 2016, 11:00:38 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Botnet resistance for pool operators  (Read 1828 times)
mikegogulski
Sr. Member
****
Offline Offline

Activity: 360



View Profile WWW
July 06, 2011, 07:48:28 AM
 #1

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

FREE ROSS ULBRICHT, allegedly one of the Dread Pirates Roberts of the Silk Road
1481367638
Hero Member
*
Offline Offline

Posts: 1481367638

View Profile Personal Message (Offline)

Ignore
1481367638
Reply with quote  #2

1481367638
Report to moderator
1481367638
Hero Member
*
Offline Offline

Posts: 1481367638

View Profile Personal Message (Offline)

Ignore
1481367638
Reply with quote  #2

1481367638
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481367638
Hero Member
*
Offline Offline

Posts: 1481367638

View Profile Personal Message (Offline)

Ignore
1481367638
Reply with quote  #2

1481367638
Report to moderator
Fletch
Full Member
***
Offline Offline

Activity: 168


I'll have a steak sandwich and a... steak sandwich


View Profile
July 06, 2011, 09:10:45 AM
 #2

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?

HashPeak - GPU mining hashrate peak detector
BTC: 1FLETCHvcUKosefrcZCLUQTtvx4WvgnYMC
mikegogulski
Sr. Member
****
Offline Offline

Activity: 360



View Profile WWW
July 06, 2011, 09:14:37 AM
 #3

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.

FREE ROSS ULBRICHT, allegedly one of the Dread Pirates Roberts of the Silk Road
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 06, 2011, 09:24:41 AM
 #4

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
Legendary
*
Offline Offline

Activity: 1848


View Profile
July 06, 2011, 10:57:01 AM
 #5

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?

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
mikegogulski
Sr. Member
****
Offline Offline

Activity: 360



View Profile WWW
July 06, 2011, 11:07:18 AM
 #6

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.

FREE ROSS ULBRICHT, allegedly one of the Dread Pirates Roberts of the Silk Road
xtoro
Jr. Member
*
Offline Offline

Activity: 56


View Profile
July 06, 2011, 01:33:59 PM
 #7

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?

Bitcoin address : 12B7HJTx2fLVEfRymamFyMABh5tzMV5LcZ
MrSam
Member
**
Offline Offline

Activity: 112



View Profile WWW
July 06, 2011, 02:15:10 PM
 #8

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
Sr. Member
****
Offline Offline

Activity: 360



View Profile WWW
July 07, 2011, 05:59:04 AM
 #9

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.

FREE ROSS ULBRICHT, allegedly one of the Dread Pirates Roberts of the Silk Road
antares
Hero Member
*****
Offline Offline

Activity: 518


View Profile
July 07, 2011, 01:28:15 PM
 #10

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
Full Member
***
Offline Offline

Activity: 168



View Profile
July 07, 2011, 01:35:13 PM
 #11

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
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 07, 2011, 01:43:04 PM
 #12

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
Sr. Member
****
Offline Offline

Activity: 360



View Profile WWW
July 07, 2011, 01:46:09 PM
 #13

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.

FREE ROSS ULBRICHT, allegedly one of the Dread Pirates Roberts of the Silk Road
Graet
VIP
Legendary
*
Offline Offline

Activity: 980



View Profile WWW
July 07, 2011, 03:16:23 PM
 #14

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 Wink

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!