[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[Graet]

It's sad you got DDOS'd but, are you keeping the coins of your pool(my coins, his coins, etc) or you will distribute them and close?

https://bitcointalk.org/index.php?topic=1976.msg584181#msg584181
would say neither

[sadpandatech]

Since tomorrow I'll try harder to find any server provider which at least don't shut down pool infrastructure on first DDoS attack, but I cannot promise that I'll succeed. There's no point in running a service which is every week for one day offline thanks to attacks.

Have a look at the hosting offered by both awknet ( http://www.awknet.com/ ) and blacklotus ( http://www.blacklotus.net/ )

There is no easy way to decipher what traffic should come through and what shouldn't in that situation.

   Which means they suck. Because they could certainly filter at the packet level if they offered that type of service.  Sadly, most that offer such custom filtering are often quite expensive.. :/

[eleuthria]

Since tomorrow I'll try harder to find any server provider which at least don't shut down pool infrastructure on first DDoS attack, but I cannot promise that I'll succeed. There's no point in running a service which is every week for one day offline thanks to attacks.

Have a look at the hosting offered by both awknet ( http://www.awknet.com/ ) and blacklotus ( http://www.blacklotus.net/ )

There is no easy way to decipher what traffic should come through and what shouldn't in that situation.

   Which means they suck. Because they could certainly filter at the packet level if they offered that type of service.  Sadly, most that offer such custom filtering are often quite expensive.. :/

The problem is that the way many miners work is very similar to a DDoS if they're targetting your mining port while the server is unresponsive.  It's amazing how many people still use old miners that will reconnect with almost no delay, making it effectively a mini DDoS client when the pool is being attacked and having stability issues.

[FoxMURDER]

The problem is that the way many miners work is very similar to a DDoS if they're targetting your mining port while the server is unresponsive.  It's amazing how many people still use old miners that will reconnect with almost no delay, making it effectively a mini DDoS client when the pool is being attacked and having stability issues.

well, solution to this part is quite easy ... upgrade or get banned ...
I'd even suggest to setup some kind of miner "RFC" saying how many connects per second is still ok. If enough pool admins agree on this and enforce it right away, ppl will force programmers to fix broken miners and users to update.

My guess about the "easiest" solution to this kind of ddos includes linking pool with the DDoS mitigation appliance.

If there was at least one share accepted in last 5 minutes, and accept/reject ratio is higher than 50%, don't screen it.
else screen it for ddos and allow at most 5 connects/minute or 50/10 minutes ... or whatever the RFC says (+10%) ... and of course somehow cache these rules and make a provision for adding manual exceptions to these rules (lot of miners behind nat - those can be solved using proxy though)...

Too bad ISPs/hosters probably won't let you do that and i guess pools aren't making enough at the moment, to buy their own ...


And btw. as the speculation about US banks ddosing pools goes, it might as well be some random joe like you playing with his botnet ... he doesen't need fat pipe, he doesen't need money, all he needs is some programming skill to build the bot ... and if there are botnets mining using infected hardware ... how hard could it be to have these bots updatable ... and once updatable, how hard can it be to update them to ddos while/instead mining
and if it is true, that there are botnets mining on btcguild, that may as well be the reason slush had a 'strong evidence' linking guild to ddoses ...

anyway just my two bitcents ...

Edit: i shouldn't have forgotten to say - Thanks slush for all the effort, even though it kind of a business for you, I believe you've done it the right way. I hope your're comming back soon in full strength. If you ever needed help with anything linux related, let me(us) know ;-)

[slush]

tl;dr Explanation for my yesterday "accusation"

summary: I don't think eleuthria is an attacker, but he may have some indices to trace attacking botnet. If you want to reply to this subject, please do it in that new thread.

[m3ta]

using infected hardware

Infected HARDware? That's just... devious.

[FoxMURDER]

using infected hardware

Infected HARDware? That's just... devious.

do infected computers sound a little less devious?

[sadpandatech]

The problem is that the way many miners work is very similar to a DDoS if they're targetting your mining port while the server is unresponsive.  It's amazing how many people still use old miners that will reconnect with almost no delay, making it effectively a mini DDoS client when the pool is being attacked and having stability issues.

well, solution to this part is quite easy ... upgrade or get banned ...
I'd even suggest to setup some kind of miner "RFC" saying how many connects per second is still ok. If enough pool admins agree on this and enforce it right away, ppl will force programmers to fix broken miners and users to update.

  I like this solution and think some adaption could be used very effectivly.  As stated though, your idea would only burden the botnet OP in having to send out an updated miner to his zombies. Not much hassle really.
  A much stronger solution could be two fold or a combo of one or the other of the following;

  1. Force accounts to email-auth and only allow so many workers per account.
  2. Force a unique ID appended to worker login per worker and only allow so many connections per ID / period of time that works best for your getwork frequency.

  The forced ID would make it impossible for a botnet OP to make one account and use the same ID for all his zombies. The server would allow the first few in and then POOF, connection limit and out he goes. The catch being, at what lvl of your network can you impliment the ID checking so it does not get DDosed? A good filter at upstream side that checked the packets for ID and would /null any packets from marked ID after so many connections per time period would probably be quite effective..  Could even be set in place at server side lvl if you have custom traffic shapping equip in place.

  All I know is something has got to give and I am sadly not in a posistion to offer out more than vague ideas. :/  I have to give mad props to you guys, Slush, Eleuth, etc who are dealing with this crap, as I know there are really only two real solutions to keep operating. Throw lots of time and energy at it or throw lots of money at it. Both of which are rare commodities with such a venture. I for one will back whatever decisions you employ to make it work for you!

  Cheers

[FoxMURDER]

sadpanda: This two-line solution was meant as a reaction to eleuth saying that fast reconnecting miners can DoS the pool.
I'm afraid that dealing with zombiemining is way harder ...

Another partial solution to DDoS screening would be pretty much what you suggest - TCP Syncookie like system - which i'm afraid, miners would have to support. This still gets me back to the idea that biggest pool operators should unite (they all seem reasonable guys) and set some kind of standard for miners which they all will enforce. Pretty much the way internet RFCs work - there is no 'legal' enforcing, but if you want to connect to common sites, you have to abide, because that's what most expect ...

[DiabloD3]

For all pool users: This attack is worse than attacks before. Actually it's probably a tenth DDoS to pool in it's almost year history (I didn't counted them carefully and you probably even don't know about small attacks which I was able to handle somehow without public attention).

This attack is worse because Linode LLC, server provider for pool infrastructure, frozen my account for periodical violation of their ToS. I can access pools servers, but I was asked to not start another balancers with public IP because those attacks are harming datacenter infrastructure.

It means that I cannot start pool at this infrastructure and I need to find another provider. Which is pretty hard once I start asking to their anti DDoS policies. Back in July I was in touch with Rackspace, company providing custom solutions for big enterprises and even they told me that they cannot handle such large scale attack for some reasonable price (we're talking about thousands of US dolars monthly just for anti-DDoS protection). Posts of some users above are really naive, there's NO way how to handle those attacks just by banning some subnets.

Fighting attacks become much worse with falling bitcoin price, because even if I have 1/3 of all network hashrate and 2% fee I simply cannot pay for any real solution which really helps to handle attacks. Last week I tried to use services of one DDoS mitigation company (the same as deepbit is using), but they had pretty high ratio of false positives, so although I paid them big money for a single day protection, almost 40% of users were still unable to mine on the pool. So this isn't the way to go.

Since tomorrow I'll try harder to find any server provider which at least don't shut down pool infrastructure on first DDoS attack, but I cannot promise that I'll succeed. There's no point in running a service which is every week for one day offline thanks to attacks.

So far it's 1:0 for attackers. However I don't want to capitulate too easily; I spent insane amount of time and energy in inventing and running my pool and I don't want to simply disappear, because I really believe in long-term Bitcoin success (small note: people, don't get scared with current panic on market, it's just an oposite of July's insane price peak). I "invented" (maybe it's better to say "realized") first really usable and widely used Bitcoin pool ever and now I feel again that I'm on the track of another innovation of Bitcoin mining, which will be DDoS resistant yet easy to use and with steady payouts like normal share based pools.

Technical note: Because the downtime of mining.bitcoin.cz will be probably more significant than anytime before, I'll wait until all mined blocks will be matured and then will send all balances of users to their wallets. Don't worry, I'm not running away with your hardly mined coins!

Just switch to RapidXen. Rapidxen's specialty is dealing with DDoS magnets, and they're a shitload better than Linode.

[sadpandatech]

sadpanda: This two-line solution was meant as a reaction to eleuth saying that fast reconnecting miners can DoS the pool.
I'm afraid that dealing with zombiemining is way harder ...

Another partial solution to DDoS screening would be pretty much what you suggest - TCP Syncookie like system - which i'm afraid, miners would have to support. This still gets me back to the idea that biggest pool operators should unite (they all seem reasonable guys) and set some kind of standard for miners which they all will enforce. Pretty much the way internet RFCs work - there is no 'legal' enforcing, but if you want to connect to common sites, you have to abide, because that's what most expect ...

  Definetly agree on the TCP syn system..  But the 2 line solution would be effective for both Zombie mining, and most asuredly zombie port slapping. At the very basics, I would assume the zombies that are straight port dossing would have much differnt packet size, structure, etc than legit getwork responses. I don't see how a forced ID on workers would not solve that. I.e. only packets that came into the port with said ID attached would be allowed. All others would be /nulled.

  Mind you, I have not had to deal with custom built filtering solutions for some years now so am not abreast to how slack that has become with modern upstreams making it harder, or hosting services more complacent with upstreams offering 'pre-built' filtering packages for sale, etc. Back in my day we had much easier access to our upstream sides to deploy custom measures for such things...... Just one more example of 'Big Business Protection' measures screwing over the lil guy with current models, imho....


  Cheers

[dishwara]

I received my bitcoins from my account with more than 60+ confirmations.
But not name coins.
I hope others too got their bitcoins.
All others namecoins also not received?

[slush]

All others namecoins also not received?

I didn't process all payments yet; I was waiting untill all blocks mature, which happen before few hours. I'll pay out also namecoins, of course.

[thehairymob]

I hope you find a way to come back from this Slush as I did like mining withat your pool. I've move over to Ars for now but it will take some to get used too. I keep tabs on this thread to see when your back up and running.

[digital]

I keep tabs on this thread to see when your back up and running.

+1

[dishwara]

I keep tabs on this thread to see when your back up and running.

+1

+100's

[Sargasm]

Slush... I have an idea...

Soooo...

Basically, you have a problem with public addresses for your pool.

If only you could ensure that no one knew how to find your pool unless they had trust... you could just use a static IP and have people mine there.

Here is one REALLY good litmus to determine whether or not a user should have trust... hashing.

If you pull from your DB of users, those who have hashed over a certain amount in the last couple weeks for instance... you could tell with a degree of certainty that these are all trusted people.

So... then you email all those users (I would be one of these people)...

Just email a private ip for the server to those users... or perhaps a domain name whatever... just something you don't post on here.

Sure, you'll lose a lot of hashing power, but it would let you continue to operate.  I liked mining with your pool, I was doing quite well.

That way maybe you can operate in the short term as a private pool using trusted participants.

The reason I do not suggest that you allow ALL miners that have been working to get the address is that quite likely, your attackers have been mining the pools somewhat to ensure they were functionally down.

[CyberPhunk]

Slush... I have an idea...

Soooo...

Basically, you have a problem with public addresses for your pool.

If only you could ensure that no one knew how to find your pool unless they had trust... you could just use a static IP and have people mine there.

Here is one REALLY good litmus to determine whether or not a user should have trust... hashing.

If you pull from your DB of users, those who have hashed over a certain amount in the last couple weeks for instance... you could tell with a degree of certainty that these are all trusted people.

So... then you email all those users (I would be one of these people)...

Just email a private ip for the server to those users... or perhaps a domain name whatever... just something you don't post on here.

Sure, you'll lose a lot of hashing power, but it would let you continue to operate.  I liked mining with your pool, I was doing quite well.

That way maybe you can operate in the short term as a private pool using trusted participants.

The reason I do not suggest that you allow ALL miners that have been working to get the address is that quite likely, your attackers have been mining the pools somewhat to ensure they were functionally down.

And, if the bot net owner has an actual miner or two of their own? What then?

[m3ta]

Slush... I have an idea...

Soooo...

Basically, you have a problem with public addresses for your pool.

If only you could ensure that no one knew how to find your pool unless they had trust... you could just use a static IP and have people mine there.

Here is one REALLY good litmus to determine whether or not a user should have trust... hashing.

If you pull from your DB of users, those who have hashed over a certain amount in the last couple weeks for instance... you could tell with a degree of certainty that these are all trusted people.

So... then you email all those users (I would be one of these people)...

Just email a private ip for the server to those users... or perhaps a domain name whatever... just something you don't post on here.

Sure, you'll lose a lot of hashing power, but it would let you continue to operate.  I liked mining with your pool, I was doing quite well.

That way maybe you can operate in the short term as a private pool using trusted participants.

The reason I do not suggest that you allow ALL miners that have been working to get the address is that quite likely, your attackers have been mining the pools somewhat to ensure they were functionally down.

And, if the bot net owner has an actual miner or two of their own? What then?

^ This.
Also, the internet's reputation for keeping secrets is "not too good". *snicker*

[Druas]

If you pull from your DB of users, those who have hashed over a certain amount in the last couple weeks for instance... you could tell with a degree of certainty that these are all trusted people.

So... then you email all those users (I would be one of these people)...

Just email a private ip for the server to those users... or perhaps a domain name whatever... just something you don't post on here.

Botnets can mine at like 80-100 GH/s if they want I think. It is just terribly inefficient. But they don't care because they aren't paying for electricity or the pipes. So you might send out an email to the botnet because they could be one of your fastest miners?