[POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com

[LuckyKey]

@forcefeddvr6
you wrote:

I'm using cgminer 3.4.3 .

I also added "no-client-reconnect" : true   to my config in hopes of preventing future hijacking.  Does anyone know if that will actually do any good?

"no-client-reconnect" was just added to cgminer-3.7.3 kalroth 20140324 and will have no effect on older versions it will be ignored.

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

[1714260342]

1714260342

[1714260342]

1714260342

[1714260342]

1714260342

[1714260342]

1714260342

[1714260342]

1714260342

[LuckyKey]

@forcefeddvr6
you wrote:

I'm using cgminer 3.4.3 .

I also added "no-client-reconnect" : true   to my config in hopes of preventing future hijacking.  Does anyone know if that will actually do any good?

"no-client-reconnect" was just added to cgminer-3.7.3 kalroth 20140324 and will have no effect on older versions it will be ignored.

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

Which oddly is the grid reference for the world data centre reference on this british map?

http://www.britishpostcodes.info/postcode/g84-0ew

[phzi]

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

You didn't get an ip for ns236914 ?

zomg!!! netstat -n !!!

[LuckyKey]

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

You didn't get an ip for ns236914 ?

zomg!!! netstat -n !!!

Yeah, I did…but the reference for the name was more interesting.  lol

You gonna be ok?

ip 192.99.35.62

Tracert displays:

Tracing route to ns236914.ip-192-99-35.net [192.99.35.62]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  phub.net.cable.rogers.com [192.168.0.1]
  2     *        *        *     Request timed out.
  3    10 ms    11 ms    10 ms  24.156.136.9
  4    15 ms    15 ms    15 ms  gi-0-1-3.gw01.grnsbr.phub.net.cable.rogers.com [24.153.7.1]
  5    13 ms    13 ms    15 ms  69.63.250.97
  6     *        *        *     Request timed out.
  7    51 ms     *       22 ms  mtl-2-6k.qc.ca [178.32.135.71]
  8    23 ms    23 ms    22 ms  bhs-g2-6k.qc.ca [198.27.73.7]
  9    22 ms    21 ms     *     bhs-4a-6k.qc.ca [198.27.73.224]
 10    23 ms    22 ms    21 ms  ns236914.ip-192-99-35.net [192.99.35.62]

Anything look odd in that route?

[romang]

@forcefeddvr6
you wrote:

I'm using cgminer 3.4.3 .

I also added "no-client-reconnect" : true   to my config in hopes of preventing future hijacking.  Does anyone know if that will actually do any good?

"no-client-reconnect" was just added to cgminer-3.7.3 kalroth 20140324 and will have no effect on older versions it will be ignored.

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

I concur but all is good right this minute.

[phzi]

192.99.35.62 would be an OVH hosted server.  The hostname of which is ns236914.ip-192-99-35.net.

[bbbbbb2014]

How can you be certain that the hash theft attack was in progress for at least 14 days or so?  (And presumably what you are implicitly suggesting is that it was only noticed over the weekend as it might have scaled up to a much higher level?)

I have a rig #19 so to speak. Running BAMT, mounted over NFS, quality Ethernet switches, ethernet wiring I have done myself. The rig has 4x R9 280x, undervolted to 1.131V, mem to 1500, clock to 1050. cgminer 3.7.2 Each card mines 730 kHash. Quality PSU (Chiftec or HP).

Internet line over single mode optics. Other rigs were mining rock solid all the time. But this rig had constant load drops - for a 30 seconds, then back up.

Then the other rig started to act the same way. At that other rig I found strange connects.

I implemented filters ASAP.

Both rigs (with all other rigs) are mining 100% null problems since then.

[comeonalready]

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

You didn't get an ip for ns236914 ?

zomg!!! netstat -n !!!

Yeah, I did…but the reference for the name was more interesting.  lol

You gonna be ok?

ip 192.99.35.62

Tracert displays:

Tracing route to ns236914.ip-192-99-35.net [192.99.35.62]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  phub.net.cable.rogers.com [192.168.0.1]
  2     *        *        *     Request timed out.
  3    10 ms    11 ms    10 ms  24.156.136.9
  4    15 ms    15 ms    15 ms  gi-0-1-3.gw01.grnsbr.phub.net.cable.rogers.com [24.153.7.1]
  5    13 ms    13 ms    15 ms  69.63.250.97
  6     *        *        *     Request timed out.
  7    51 ms     *       22 ms  mtl-2-6k.qc.ca [178.32.135.71]
  8    23 ms    23 ms    22 ms  bhs-g2-6k.qc.ca [198.27.73.7]
  9    22 ms    21 ms     *     bhs-4a-6k.qc.ca [198.27.73.224]
 10    23 ms    22 ms    21 ms  ns236914.ip-192-99-35.net [192.99.35.62]

Anything look odd in that route?

The results of this specific traceroute may or may not reveal anything regarding the nature of the redirection attack, and to make a determination as to whether it contains any useful information, you must first conclusively determine whether your miner received and processed a client.reconnect command message leading it to that server.  Here's why.  If your miner received and processed client.reconnect to another server, then you may now be connecting to that rogue server via an uncompromised route, with a transient compromised route only having been used to connect the first rogue server issuing that client.reconnect command message.  (i.e. attacker enabling and disabling redirection intermittently in order to make it more difficult to track down).  However, if your miner never received and processed a client.reconnect command message (which is within the realm of possibility because you are still mining on the original wafflepool tcp port 3333), then this traceroute result could actually be showing somewhere within it a redirection.  So, scour your logs if you have received reconnection requests, and enable verbose logs if you don't!

[utahjohn]

How can you be certain that the hash theft attack was in progress for at least 14 days or so?  (And presumably what you are implicitly suggesting is that it was only noticed over the weekend as it might have scaled up to a much higher level?)

I have a rig #19 so to speak. Running BAMT, mounted over NFS, quality Ethernet switches, ethernet wiring I have done myself. The rig has 4x R9 280x, undervolted to 1.131V, mem to 1500, clock to 1050. cgminer 3.7.2 Each card mines 730 kHash. Quality PSU (Chiftec or HP).

Internet line over single mode optics. Other rigs were mining rock solid all the time. But this rig had constant load drops - for a 30 seconds, then back up.

Then the other rig started to act the same way. At that other rig I found strange connects.

I implemented filters ASAP.

Both rigs (with all other rigs) are mining 100% null problems since then.

Suggests a user of remote shell account on compromised server(s) ... what is it 3 IP's now that have been traced ...

many pages ago there was a post regarding the hacker group "Anonymous" ...

[azebro]

@forcefeddvr6
you wrote:

I'm using cgminer 3.4.3 .

I also added "no-client-reconnect" : true   to my config in hopes of preventing future hijacking.  Does anyone know if that will actually do any good?

"no-client-reconnect" was just added to cgminer-3.7.3 kalroth 20140324 and will have no effect on older versions it will be ignored.

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

I found similar:

ns317663:3333



I concur but all is good right this minute.

[bbbbbb2014]

Suggests a user of remote shell account on compromised server(s) ... what is it 3 IP's now that have been traced ...

many pages ago there was a post regarding the hacker group "Anonymous" ...

If you suggest someone was logging on my machines - it will be a little harder than that. Machines are behind two firewalls, extra network segment, no ssh was possible from outside.

What I implemented (filterwise) is that the miner rig cannot connect to external IP at will, but only on specific IPs (pools) and specific ports - 3333.

Even if the attacker spoofed the package - so the source ip is from the pool, then the redirect is blocked by external filters - so no stealing can be done anymore.

[comeonalready]

How can you be certain that the hash theft attack was in progress for at least 14 days or so?  (And presumably what you are implicitly suggesting is that it was only noticed over the weekend as it might have scaled up to a much higher level?)

I have a rig...  Other rigs were mining rock solid all the time. But this rig had constant load drops - for a 30 seconds, then back up.

Then the other rig started to act the same way. At that other rig I found strange connects.

I implemented filters ASAP.

Both rigs (with all other rigs) are mining 100% null problems since then.

And what specifically do you mean by 'strange connects'?  -- as it could be very relevant.  Do you keep miner logs by any chance?

[azebro]

@forcefeddvr6
you wrote:

I'm using cgminer 3.4.3 .

I also added "no-client-reconnect" : true   to my config in hopes of preventing future hijacking.  Does anyone know if that will actually do any good?

"no-client-reconnect" was just added to cgminer-3.7.3 kalroth 20140324 and will have no effect on older versions it will be ignored.

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

I found similar:

ns317663:3333



I concur but all is good right this minute.

I found similar:

ns317663:3333

EDIT: but those hosted addresses don't belong by any chance to Waffle?
Maybe stupid q, but do we know if i.e.: ns317663 is rouge or just one of waffle hosted boxes?

A.

[comeonalready]

What I implemented (filterwise) is that the miner rig cannot connect to external IP at will, but only on specific IPs (pools) and specific ports - 3333.

Even if the attacker spoofed the package - so the source ip is from the pool, then the redirect is blocked by external filters - so no stealing can be done anymore.

Perhaps not, but if a network redirection attack is in play somewhere in the middle of your route to mining servers, then attackers could potentially stall your rigs as your miners would not be able to reach the real pool servers, and any legitimate ip address change by pool server operators would cause the same, but both of these circumstances can be mitigated by configuring multiple redundant pools.

Also if they are able to maintain that network redirection for any length of time, then there is nothing to stop your miners from working for them directly.

What you have implemented is a good strategy to reduce your attack surface, but not a 100% fix.  And neither would my netstat monitoring strategy (posted somewhere above) alert you that something like this was talking place.  (Though as yet we have not had anyone report this specific case.)  The only fully effective long term detection and avoidance solution to miner hijacking is stratum server authentication.

[azebro]

@forcefeddvr6
you wrote:

I'm using cgminer 3.4.3 .

I also added "no-client-reconnect" : true   to my config in hopes of preventing future hijacking.  Does anyone know if that will actually do any good?

"no-client-reconnect" was just added to cgminer-3.7.3 kalroth 20140324 and will have no effect on older versions it will be ignored.

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

I found similar:

ns317663:3333



I concur but all is good right this minute.

I found similar:

ns317663:3333

EDIT: but those hosted addresses don't belong by any chance to Waffle?
Maybe stupid q, but do we know if i.e.: ns317663 is rouge or just one of waffle hosted boxes?

A.

What is your usual wafflepool mining server?  useast, uswest, eu, etc.?

EU with first failover to USEast

A.

[comeonalready]

My hashing rate just went down by about 14% for a bit, although cgminer rate displayed was basically unchanged, so I did a netstat on my 3 rigs.  All of them had the following connection displayed:

ns236914:3333

It was only for a few minutes, going back up now.

I found similar:

ns317663:3333


I concur but all is good right this minute.

I found similar:

ns317663:3333

EDIT: but those hosted addresses don't belong by any chance to Waffle?
Maybe stupid q, but do we know if i.e.: ns317663 is rouge or just one of waffle hosted boxes?

A.

What is your usual wafflepool mining server?  useast, uswest, eu, etc.?

EU with first failover to USEast

A.

I should have investigated the ip address first before posting the complicated answer.  192.99.25.62 (otherwise known as ns236914.ip-192-99-35.net) appears to be wafflepool's useast stratum server.   (Unless a dns hijack currently in progress, which I seriously doubt.)

Before using netstat, I had suggested that you create a table of your expected server host names to ip address mappings so as to be able to properly evaluate the results.  Did you do that first?

[utahjohn]

Sometimes I wish Anonymous would just schedule DDOSing all multipools constantly forever 

Toss my salad B! LOL

Found it!

[gtraah]

Before people make assumptions I am not in no way pointing the fingers at pool owner or any pool owner in fact, as I am in no way to know.. But I am just curious after reading about this hi-jacking thing... Wouldnt it be very easy for a pool owner of a multipool to take 5% hashing power of peoples rigs Randomly , so that not all the people know its happening at once because its suspicious but a different random group off 300 people each day 5-10% from each rig, Plus  offcourse the pool fee of the total miners, thats alot of DOugh  ( it's crazy to know what people do for money, $ = drug = addiction.. etc $ has turned angels into devils, just sayin). Anyway How are we to know that it is happening, since its not happening to all the people the other 3000-4000 people will just say check your network, pings, rigs, settings, cgminer etc.... I find it very hard for an outsider who does not have any admin access to the stratum point servers to re-direct hashing power from inside > to > outside, not saying its not possible but I recon there are some very shifty pools out there that we need to be aware off. I think we all need figure out a way to find out if its happening for our own good and to look after one another, maybe there is a way and I don't know about it.... [ There should be a blanket process that we can use for all pools, not only the pools we mine, like I said i am not pointing fingers I am just trying to find out a way to look out for each other, without us the pools die]

WHats your thoughts? Any preventions to cover our own asses & pockets other than to solo mine?

[utahjohn]

I agree @poolwaffle make your pool source code open source on github or such similar open source sites so suspicions such as these can be allayed.  you scrypted the re-direct of pool to ghash.io for the 2x promotion before ...

[comeonalready]

Before people make assumptions I am not in no way pointing the fingers at pool owner or any pool owner in fact, as I am in no way to know.. But I am just curious after reading about this hi-jacking thing... Wouldnt it be very easy for a pool owner of a multipool to take 5% hashing power of peoples rigs Randomly , so that not all the people know its happening at once because its suspicious but a different random group off 300 people each day 5-10% of each Plus the pool fee. How are we to know what is happening, since its not happening to all the people the other 3000-4000 people will just say check your network, pings, rigs, settings, cgminer etc.... I find it very hard for an outsider who does not have any admin access to the stratum point servers to re-direct hashing power from inside > to > outside, not saying its not possible but I recon there are some very shifty pools out there that we need to be aware off. I think we all need figure out a way to find out if its happening for our own good and to look after one another, maybe there is a way and I don't know about it....

WHats your thought?

There are far easier ways for a pool operator to skim off the top without leaving much of a trail for you to follow, and this is especially true for multicoin pools, so if you have reason to doubt the character of a pool operator then you should immediately switch to a different pool.  As for wafflepool, I tracked down poolwaffle's true identity (no, I won't share it so don't ever bother asking for a hint), so I know exactly with whom I am dealing, and he has thus far shown to be trustworthy and conscientious.  But don't take my word for it; make your own judgments.