This jumping to 46.28.205.80 happens on ghash too... And every time at same time... So it might be something automatic...
17 rigs, 3 locations
Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 194. (Read 1061449 times)
And I just noticed the share difficulty on the ant was set to 1K.
Has anyone else noticed this?
-Dave
Sounds like you're MITM'd...Has anyone else noticed this?
-Dave
I *knew* that, just trying to post more info. If it's a 1K share difficulty it's not like they are getting any work out of it. AND also that it was on ghash not just yours as Mr.Teal (slush) mentioned so it's a few more data points.
-Dave
As you see, I'm a newby. However, the IP points to Solar Communications in Zurich, Switzerland. This company is run by two Russians and maintains a really weird and crappy homepage, offering colocation and other stuff.
Remarkable is that they accept payments in Litecoin and Nxt Cryptocurrency.
The whole site looks as if it was set up quickly, translated poorly and then put into the wilderness of the WWW.
On their Twitter-account, they refer to their partner coinshost.com.
Solar Communications as well as Coinshost have their data center at the same address in Zurich, Switzerland, an address, btw, which was used in the past by some Russians who were involved in extortion via ddos.
Another one in this group is incloudibly.net. And what do they all offer? Right: ddos-protected bitcoin-hosting.
I'm cautious with suspicions, but in the past, similar companies with the same address were used by the Russians. If contacted by possible clients who asked for their services and turned them down because of the prices, the possible clients soon became victims of ddos-attacks - until they went down or hired the services of the "specialised" companies.
So if anybody ever was contacted by them and has since then experienced a ddos-attack: This would explain a lot.
Remarkable is that they accept payments in Litecoin and Nxt Cryptocurrency.
The whole site looks as if it was set up quickly, translated poorly and then put into the wilderness of the WWW.
On their Twitter-account, they refer to their partner coinshost.com.
Solar Communications as well as Coinshost have their data center at the same address in Zurich, Switzerland, an address, btw, which was used in the past by some Russians who were involved in extortion via ddos.
Another one in this group is incloudibly.net. And what do they all offer? Right: ddos-protected bitcoin-hosting.
I'm cautious with suspicions, but in the past, similar companies with the same address were used by the Russians. If contacted by possible clients who asked for their services and turned them down because of the prices, the possible clients soon became victims of ddos-attacks - until they went down or hired the services of the "specialised" companies.
So if anybody ever was contacted by them and has since then experienced a ddos-attack: This would explain a lot.
And I just noticed the share difficulty on the ant was set to 1K.
Has anyone else noticed this?
-Dave
Sounds like you're MITM'd... Has anyone else noticed this?
-Dave
And I just noticed the share difficulty on the ant was set to 1K.
Has anyone else noticed this?
-Dave
Has anyone else noticed this?
-Dave
I should probably mention again that I say something like this with a machine that was pointed to Slush. As I speak I just noticed that two rigs in physically separate locations and with different ISPs that were connected to Slush haven't submitted a share in 10 minutes.
The miners show them still connected to pool 0, but 46.28.205.80 instead of Slush.
One was running cgminer 4.0.0 on windows, the other is running cgminer 4.2.2
The miners show them still connected to pool 0, but 46.28.205.80 instead of Slush.
One was running cgminer 4.0.0 on windows, the other is running cgminer 4.2.2
My test boxes which were pointing to ghash just did this too.
What DNS server (s) are you using public or private?
What kind of firewall were they behind?
One was an ANT S1 the other was an generic avalon clone.
Both are running the openwrt / cgminer that came with it.
-Dave
I should probably mention again that I say something like this with a machine that was pointed to Slush. As I speak I just noticed that two rigs in physically separate locations and with different ISPs that were connected to Slush haven't submitted a share in 10 minutes.
The miners show them still connected to pool 0, but 46.28.205.80 instead of Slush.
One was running cgminer 4.0.0 on windows, the other is running cgminer 4.2.2
The miners show them still connected to pool 0, but 46.28.205.80 instead of Slush.
One was running cgminer 4.0.0 on windows, the other is running cgminer 4.2.2
Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution 
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.
Whether or not you want to call that a MITM attack is another matter.
Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.
Whether or not you want to call that a MITM attack is another matter.
I guess TechByPC was wrong about explaining things technically being more enlightening than calling people names...
Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.
Whether or not you want to call that a MITM attack is another matter.
Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
Anyone still mining here is at risk and there is no way to mitigate it with the current setup.
Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.
It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.
Whether or not you want to call the former a MITM attack is another matter. Really the attacker in that case isn't (necessarily) in the middle, she just pretends to be.
Not only that, but it would be important for Eligius to let us know what the data centre is that is doing or allowing one of their employees to do this MITM attack, so that we all know to not use that data centre.
By the way, neither requires being in the data centre of the server. The latter (which I'd call a true MITM attack) just requires being somewhere in the middle (hence the name).
The former (which is probably more likely) doesn't even require that. It just requires correctly guessing TCP sequence numbers and spoofing of the source address. See, e.g., http://www.thegeekstuff.com/2012/01/tcp-sequence-number-attacks/
In any case, I think we have our answer to the question as to why the DOS is/was going on (*). Be careful what you wish for...
(*) Step 2: "[The attacker] floods Host B with new requests causing a Denial of service attack to stop Host B from communicating with A."
yup my miners went offline a few hours ago and when I logged on all showed 0MH/s. switched over to Emc and they are humming along nicely. Any ideas on when any fix may be applied and how best to stop it?
My guess would actually be that the Eligius server itself has been hacked
(or it's connected to a shoddy network)
lol, you really are a boob, aren't you? <- opinion of a EC-CEH
When all else fails, call people names and throw around credentials. It's much more enlightening than anything technical.
My guess would actually be that the Eligius server itself has been hacked
(or it's connected to a shoddy network)
lol, you really are a boob, aren't you? <- opinion of a EC-CEH
Everyone, please check your miner is actually connected to Eligius.
It seems there are some MITM attacks going on to redirect Eligius miners to another pool
Do you know which pool, or at least an IP address? It'd be interesting to try and tie the pool-in-the-middle to a reused generation address.It seems there are some MITM attacks going on to redirect Eligius miners to another pool
This seems to be a scrypt "Worldcoin" mining server, and it seems likely they are just automatically MITM'ing any stratum connections they can inject into, regardless of the destination pool.
So it's not just you but a number of different pools that all have the same problem? Or is it a stratum problem that is pool agnostic?
It's definitely a localized problem. I've yet to see a single report of it on BTC Guild. It *did* happen to ScryptGuild at the same time as CleverMining a few months back, but the number of users affected was so low I believe it was local malware. If it's some kind of ARP poisoning to intercept the traffic, that's possible (ScryptGuild is run out of OVH, while BTC Guild is not run in a shitty datacenter like that).
It is not a stratum bug, that much is absolutely certain (there's no way to relay messages to an independent stratum connection). It is using a stratum method (client.reconnect) to perform the attack though, and make it so once the connection does have the message injected (how that's done I still have no damn clue), the client connects directly to "evilserver.com".
Geee thanks for letting us know how awesome BTC Guild is!
It is EXTREMELY LIKELY that a pool the person is connected to before it was redirected is the cause.
It is EXTREMELY UNLIKELY that it is a MITM attack unless there is a shoddy network somewhere in the middle.
I can agree with your probabilistic statements here, but in this case, it does indeed seem to be a TCP MITM attack.It is EXTREMELY UNLIKELY that it is a MITM attack unless there is a shoddy network somewhere in the middle.
Ah. I see.
Same problem as the one addressed by this patch, then? https://gist.github.com/gevans/9846423
Everyone, please check your miner is actually connected to Eligius.
It seems there are some MITM attacks going on to redirect Eligius miners to another pool
Do you know which pool, or at least an IP address? It'd be interesting to try and tie the pool-in-the-middle to a reused generation address.It seems there are some MITM attacks going on to redirect Eligius miners to another pool
This seems to be a scrypt "Worldcoin" mining server, and it seems likely they are just automatically MITM'ing any stratum connections they can inject into, regardless of the destination pool.
So it's not just you but a number of different pools that all have the same problem? Or is it a stratum problem that is pool agnostic?
It's definitely a localized problem. I've yet to see a single report of it on BTC Guild. It *did* happen to ScryptGuild at the same time as CleverMining a few months back, but the number of users affected was so low I believe it was local malware. If it's some kind of ARP poisoning to intercept the traffic, that's possible (ScryptGuild is run out of OVH, while BTC Guild is not run in a shitty datacenter like that).
It is not a stratum bug, that much is absolutely certain (there's no way to relay messages to an independent stratum connection). It is using a stratum method (client.reconnect) to perform the attack though, and make it so once the connection does have the message injected (how that's done I still have no damn clue), the client connects directly to "evilserver.com".
Everyone, please check your miner is actually connected to Eligius.
It seems there are some MITM attacks going on to redirect Eligius miners to another pool
Do you know which pool, or at least an IP address? It'd be interesting to try and tie the pool-in-the-middle to a reused generation address.It seems there are some MITM attacks going on to redirect Eligius miners to another pool
This seems to be a scrypt "Worldcoin" mining server, and it seems likely they are just automatically MITM'ing any stratum connections they can inject into, regardless of the destination pool.
So it's not just you but a number of different pools that all have the same problem? Or is it a stratum problem that is pool agnostic?
It is EXTREMELY LIKELY that a pool the person is connected to before it was redirected is the cause.
It is EXTREMELY UNLIKELY that it is a MITM attack unless there is a shoddy network somewhere in the middle.
I can agree with your probabilistic statements here, but in this case, it does indeed seem to be a TCP MITM attack.It is EXTREMELY UNLIKELY that it is a MITM attack unless there is a shoddy network somewhere in the middle.
Jump to: