DDoS is back on US East.
I've got another server getting setup with Awknet TODAY (website provider) which has been able to keep us online reasonably during the attacks.
Eri: The botnet was donating 5%. Considering the volume of CPU miners eating system resources, I think banning them (even though they were the biggest donator) would have ended up making me more due to everybody else working even faster without the idles.
Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 66. (Read 379078 times)
July 06, 2011, 03:14:32 PM
July 06, 2011, 02:51:28 PM
@everyone that says kick out those under 10 mh/s
one of the reasons to have pools, if not the main reason pools exist is to allow those that can not mine on their own to come together so they can make something, for people with high end gpu's this offers a more constant payout rather then the more risky mining on your own. so if anyone is going to say 'kick out the people that need pools the most' then why not suggest to kick out everyone else while were at it and close the pool down? problem solved!
side topic:
how much bandwidth was the botnet account using while mining and how big was the bribe they were offering eleuthria and how many btc did that work out to over their accounts lifetime while it was active.
one of the reasons to have pools, if not the main reason pools exist is to allow those that can not mine on their own to come together so they can make something, for people with high end gpu's this offers a more constant payout rather then the more risky mining on your own. so if anyone is going to say 'kick out the people that need pools the most' then why not suggest to kick out everyone else while were at it and close the pool down? problem solved!
side topic:
how much bandwidth was the botnet account using while mining and how big was the bribe they were offering eleuthria and how many btc did that work out to over their accounts lifetime while it was active.
July 06, 2011, 02:37:38 PM
edit: I would love to see what my share is if we found a block with only 600G as we have right now 
you can calculate this:
your mh/s / 600 * 49 = your income per blocks found, example: 1gh/s / 600 * 49 = 0,08166667 btc/blocks
July 06, 2011, 01:58:22 PM
I am just curius, why didn't you go with a whitelist? seams more solid as workers with gpus probably have a limited or only one ip
edit: I would love to see what my share is if we found a block with only 600G as we have right now
edit: I would love to see what my share is if we found a block with only 600G as we have right now
July 06, 2011, 01:29:05 PM
The logging I put in place is for a two criteria auto-blacklist:
1) Too many IPs on a single worker.
2) Too many requests with too few shares returned.
Do you mean to many IPs at the same time, or to many IPs over a period of time?1) Too many IPs on a single worker.
2) Too many requests with too few shares returned.
Over a reasonable period of time. Dynamic IP users won't need to fear the auto ban.
July 06, 2011, 01:25:04 PM
The logging I put in place is for a two criteria auto-blacklist:
1) Too many IPs on a single worker.
2) Too many requests with too few shares returned.
Do you mean to many IPs at the same time, or to many IPs over a period of time? 1) Too many IPs on a single worker.
2) Too many requests with too few shares returned.
July 06, 2011, 12:49:23 PM
Well the secret is out. Yes, US East is currently online. The other servers are staying off while I monitor US East's activity.
The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
Exactly,
1) Delay of around round time divided by 2 is almost necessary to prevent hopping abuse.
2) Banning people for using many ip's might not be the best idea, instead using an efficiency based banning might be more fair and have the same effect (i.e. stales > 20% or whatever arbitrary value).
The logging I put in place is for a two criteria auto-blacklist:
1) Too many IPs on a single worker.
2) Too many requests with too few shares returned.
July 06, 2011, 12:45:44 PM
Well the secret is out. Yes, US East is currently online. The other servers are staying off while I monitor US East's activity.
The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
Exactly,
1) Delay of around round time divided by 2 is almost necessary to prevent hopping abuse.
2) Banning people for using many ip's might not be the best idea, instead using an efficiency based banning might be more fair and have the same effect (i.e. stales > 20% or whatever arbitrary value).
July 06, 2011, 12:42:29 PM
Well the secret is out. Yes, US East is currently online. The other servers are staying off while I monitor US East's activity.
The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
keep up the great work eleuthria The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
July 06, 2011, 12:26:55 PM
Awesome! Thanks for all your great work Eleuthria!
July 06, 2011, 12:08:41 PM
Well the secret is out. Yes, US East is currently online. The other servers are staying off while I monitor US East's activity.
The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
The shares being sent to US east are valid and being counted, but My Account is currently still in its low-priority DDoS mode where it does not try to communicate with servers (thus no real-time stats getting pulled from US East).
US East is still counting shares. It still had about 75k of share submission data from last night's uptime as well. I'll be worknig on the stat polling/caching system tonight to get Worker Stats available again on a small delay.
July 06, 2011, 11:46:03 AM
Still showing down for me, are you pointing to a specific server?
Pointed at USeast July 06, 2011, 11:44:32 AM
Still showing down for me, are you pointing to a specific server?
July 06, 2011, 11:40:22 AM
Perhaps to deal with this in the future, you can go down this dark and shady road...
Put a notice on the site that only miners pulling in at least 10MH/sec are welcome.
This will not keep out the cpumining botnet, but it will establish the terms of your pool and the botnet would be violating those terms. Then, once you identify a future botnet, invalidate 2/3 of all shares submitted by miners running less than 10MH/sec and just pretend like they didn't happen. Net result, the rest of us benefit from the work of the botnet and the impact to the botnet's profitability might be low enough that they don't even notice.
Put a notice on the site that only miners pulling in at least 10MH/sec are welcome.
This will not keep out the cpumining botnet, but it will establish the terms of your pool and the botnet would be violating those terms. Then, once you identify a future botnet, invalidate 2/3 of all shares submitted by miners running less than 10MH/sec and just pretend like they didn't happen. Net result, the rest of us benefit from the work of the botnet and the impact to the botnet's profitability might be low enough that they don't even notice.
and what about the Legit users under 10 mh a sec? oh right 'they are not important'. how could i forget..
They are not worth... probably they cause more problems (bandwidth/resources consumption) than their benefits (Mhash/sec).
So I think it's a good idea that larger pools allow only "gpu" users meanwhile "cpu" users must be confined to smaller polls where they are welcome.
My 2 cents
I would tend to agree with you, under 10 MH/sec likely clog the servers in terms of getting idles and it is doubtful that at this difficulty many people are knowingly CPU mining outside of thoes with free electricity.
On another note, cautiously optomisitc the servers are coming back up? My miners have swapped off their backup back to BTCGuild and I see the pool at nearly 100GH/Sec now.
July 06, 2011, 11:38:06 AM
I am not saying that <10MH/s is not important. What I am saying is that the pool admin will likely want to make a determination as to how to manage the pool resources.
This is a free pool and the admins have to rely upon donations made in good will. No one has unlimited bandwidth and, unfortunately, bandwidth costs money. Also, unfortunately, it is more effective for a single client to connect to the pool and hash away at 400MH/sec than it is for 800 clients to connect and bang away at 0.5MH/sec.
As of yet, I'm unaware of any zombie computers actually using GPU to mine; they all appear to be cpuminers. I'm not saying that they can't, but that they usually do not. For reference:
Perhaps 10MH/sec was too strict, but surely 1M/sec should be considered, with the option for an exception to be made for legitimate users after registration. This, however, raises the question as to how to limit an account to a single worker since the botnet controller can simply request an exception posing as a legitimate user and the use that account for all the zombies.
DDoS is a pain, unfortunately. I'm not trying to be a jerk so don't be hostile. I'm trying to offer suggestions to help get our pool back up and running and prevent future problems.
This is a free pool and the admins have to rely upon donations made in good will. No one has unlimited bandwidth and, unfortunately, bandwidth costs money. Also, unfortunately, it is more effective for a single client to connect to the pool and hash away at 400MH/sec than it is for 800 clients to connect and bang away at 0.5MH/sec.
so rather then me shoving your 2 cents .... back in your pocket... what makes you think some of these botnets run programs that cant take advantage of GPU's?
As of yet, I'm unaware of any zombie computers actually using GPU to mine; they all appear to be cpuminers. I'm not saying that they can't, but that they usually do not. For reference:
Put in some filters to stop the botnet(s) that were pointed at the servers. IMMEDIATELY saw a performance boost to the servers. Will monitor the results overnight to see if banning THOUSANDS of CPU miners cures the problems.
If you're having trouble connecting after the filters were put in place, send me a PM. Botnets need not apply.
Registrations have been re-opened due to the servers showing an incredible recovery after the bans.
The account balance of the botnet has been donated to Bitcoin Faucet.
If you're having trouble connecting after the filters were put in place, send me a PM. Botnets need not apply.
Registrations have been re-opened due to the servers showing an incredible recovery after the bans.
The account balance of the botnet has been donated to Bitcoin Faucet.
Perhaps 10MH/sec was too strict, but surely 1M/sec should be considered, with the option for an exception to be made for legitimate users after registration. This, however, raises the question as to how to limit an account to a single worker since the botnet controller can simply request an exception posing as a legitimate user and the use that account for all the zombies.
DDoS is a pain, unfortunately. I'm not trying to be a jerk so don't be hostile. I'm trying to offer suggestions to help get our pool back up and running and prevent future problems.
July 06, 2011, 11:28:07 AM
so rather then me shoving your 2 cents .... back in your pocket... what makes you think some of these botnets run programs that cant take advantage of GPU's?
July 06, 2011, 10:23:06 AM
Perhaps to deal with this in the future, you can go down this dark and shady road...
Put a notice on the site that only miners pulling in at least 10MH/sec are welcome.
This will not keep out the cpumining botnet, but it will establish the terms of your pool and the botnet would be violating those terms. Then, once you identify a future botnet, invalidate 2/3 of all shares submitted by miners running less than 10MH/sec and just pretend like they didn't happen. Net result, the rest of us benefit from the work of the botnet and the impact to the botnet's profitability might be low enough that they don't even notice.
Put a notice on the site that only miners pulling in at least 10MH/sec are welcome.
This will not keep out the cpumining botnet, but it will establish the terms of your pool and the botnet would be violating those terms. Then, once you identify a future botnet, invalidate 2/3 of all shares submitted by miners running less than 10MH/sec and just pretend like they didn't happen. Net result, the rest of us benefit from the work of the botnet and the impact to the botnet's profitability might be low enough that they don't even notice.
and what about the Legit users under 10 mh a sec? oh right 'they are not important'. how could i forget..
They are not worth... probably they cause more problems (bandwidth/resources consumption) than their benefits (Mhash/sec).
So I think it's a good idea that larger pools allow only "gpu" users meanwhile "cpu" users must be confined to smaller polls where they are welcome.
My 2 cents
July 06, 2011, 10:13:49 AM
Perhaps to deal with this in the future, you can go down this dark and shady road...
Put a notice on the site that only miners pulling in at least 10MH/sec are welcome.
This will not keep out the cpumining botnet, but it will establish the terms of your pool and the botnet would be violating those terms. Then, once you identify a future botnet, invalidate 2/3 of all shares submitted by miners running less than 10MH/sec and just pretend like they didn't happen. Net result, the rest of us benefit from the work of the botnet and the impact to the botnet's profitability might be low enough that they don't even notice.
Put a notice on the site that only miners pulling in at least 10MH/sec are welcome.
This will not keep out the cpumining botnet, but it will establish the terms of your pool and the botnet would be violating those terms. Then, once you identify a future botnet, invalidate 2/3 of all shares submitted by miners running less than 10MH/sec and just pretend like they didn't happen. Net result, the rest of us benefit from the work of the botnet and the impact to the botnet's profitability might be low enough that they don't even notice.
and what about the Legit users under 10 mh a sec? oh right 'they are not important'. how could i forget..
July 06, 2011, 09:24:01 AM
Deepbit apparently also banned the botnets
also last night deepbit went down for several minutes
those are the facts I observed, not drawing any conclusions. . .
also last night deepbit went down for several minutes
those are the facts I observed, not drawing any conclusions. . .
July 06, 2011, 08:42:44 AM
For all the people about to say or who have already said: "I havn't read this whole thread but..."
First: if you go to #btcguild on freenode, typically the topic line will answer what you're about to ask/suggest
Second: here is the current topic line: The official channel of BTC Guild (www.btcguild.com). We have been/are being DDoS'd. There is no ETA yet for the pools coming back, but they will. No, CloudFlare would not solve this. No, we're not using EC2 unless you feel like paying for it. Round Robin DNS is a sin against humanity. No, your IPtables script will not help. A VPS cannot host a pool. I need a hug =(
Third: The DDoS started within an hour of a botnet being banned from the pool, it is overwhelmingly likely that it is out of spite, rather than profit motive from [insert the person you think might profit here]. Especially seeing as how [Tycho, Slush, dbitcoin, etc] All have much more to gain by having a good reputation in the community than by DDoSing another pool.
Fourth: Why do I even still read this thread?
First: if you go to #btcguild on freenode, typically the topic line will answer what you're about to ask/suggest
Second: here is the current topic line: The official channel of BTC Guild (www.btcguild.com). We have been/are being DDoS'd. There is no ETA yet for the pools coming back, but they will. No, CloudFlare would not solve this. No, we're not using EC2 unless you feel like paying for it. Round Robin DNS is a sin against humanity. No, your IPtables script will not help. A VPS cannot host a pool. I need a hug =(
Third: The DDoS started within an hour of a botnet being banned from the pool, it is overwhelmingly likely that it is out of spite, rather than profit motive from [insert the person you think might profit here]. Especially seeing as how [Tycho, Slush, dbitcoin, etc] All have much more to gain by having a good reputation in the community than by DDoSing another pool.
Fourth: Why do I even still read this thread?
Agree +1
btw never knew we had a irc chat room
. I may have to idle there Jump to: