Topic: [POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com - page 121. (Read 465769 times)

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?

EU with first failover to USEast

A.

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.

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.

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

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.

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" ...

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!

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.

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

I concur but all is good right this minute.

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?

You didn't get an ip for ns236914 ?

zomg!!! netstat -n !!!

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

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

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.

@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?


In reply:
"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.


http://k-dev.net/cgminer/

Create a table of your configured mining server host names and what their ip addresses and tcp port numbers should be (there are always subject to change, but only legitimately by the server operators), and learn how to use your operating system's netstat command to view a list of currently active tcp connections.  For wafflepool search for tcp connection on appropriate ip address and port 3333.  Should that line disappear from the list and your miner is still reporting that it is actively mining (and not having shifted to one of your other backup pools), then that would be indicative of a hash theft attack.

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 would tend to agree it is possible that some miners are still being hijacked to another rogue server but simply haven't noticed it.  If whatever vulnerabilities were present to enable this attack in the first place have not been fixed, then the opportunity for an easy gain is a strong lure for them to try it again.  However, without anyone reporting active hash theft, there is little to be done to trace anything at the moment.  poolwaffle can comment here if he likes, but I would imagine from the perspective of pool servers, it just looks like clients are disconnecting during an attack, as they usually do all day every day, at random intervals based on the actions of their owners and network conditions.

I had two ideas to address this problem.  I already posted the first earlier which applies mostly to the long term for adding public/private key server authentication checks into the stratum mining protocol itself in such a manner that is does not break any combination of current client or server pairings -- which generated no interest from any of the parties involved.

If we could factually answer your question we could guarantee that the attacks are prevented.

Too soon for that unfortunately.