If they were targeting specific servers, they wouldn't be redirecting Bitcoin miners to a scrypt server - kinda pointless  |
|
|
|
Just a thought about these DOS attacks: I know that Ghash.io uses Cloudflare to block or mitigate DOS attacks (and I know some aren't too keen on Ghash.io). Would a service like that help here? Is it expensive? http://www.cloudflare.com/ddosIt's a rather large security risk, incompatible with stratum (though - edit: theoretically - compatible with GBT), and probably wouldn't do much better (services have been unaffected by the DDoS for the most part). |
|
|
|
Someone earlier suggested mining p2pool (I'm not jumping ship), I'm just curious if they are immune to this attack? p2pool itself is, yes. Using someone else's p2pool node, however, is not. |
|
|
|
I'l try to make a summary of what's happening, to the best of my understanding. Thank you for doing this, it covers the topic well. |
|
|
|
I like eligius a lot as a pool, but whatever is causing these DDOS attacks needs to be dealt with properly rather that just fail-safeing the stats page every other day
I agree, please help figure out which government has jurisdiction and rant at them to make an arrest  |
|
|
|
So there is no way ... because dragon miners need the difficulty to be handled be the pool . I try the dragon miner on Eligius and does not give normal speed See if the Dragon miner people will provide a sample unit and docs so I can implement BFGMiner support. Besides having support from the leading mining software, BFGMiner support avoids bugs like this. |
|
|
|
Luke and Wizkid is the same person. Err..no. I dunno. Ever seen them in the one room at the same time? Me neither. In fact Luke-Jr, Wizkid, Inaba, eleuthria could all be the same person, since I've never seen them together in one room before either. Or Satoshi. Or you, Luke-Jr- er I mean HellDiverUK. Hm, many people have seen myself and Inaba together in the same room at Bitcoin Conferences. You're right about wizkid057 and Eleuthria though, I've never seen them! Need to drag them both to a conference sometime... |
|
|
|
Hi Luke,
Any news on OneString Miner support? It is the last piece of the puzzle for me so I do not have to use cgminer anymore.
I hope you are having a great weekend and thanks again.
I believe we've identified all the compatibility issues. Assuming the fixed firmware is released in time, it should be supported in 4.0. is there a branch that can be viewed? or is it a mainline commit? Just working code in my local checkout right now. plx <3 It's not going to be especially useful until the firmware is fixed too... |
|
|
|
Hi Luke,
Any news on OneString Miner support? It is the last piece of the puzzle for me so I do not have to use cgminer anymore.
I hope you are having a great weekend and thanks again.
I believe we've identified all the compatibility issues. Assuming the fixed firmware is released in time, it should be supported in 4.0. is there a branch that can be viewed? or is it a mainline commit? Just working code in my local checkout right now. |
|
|
|
Hi Luke,
Any news on OneString Miner support? It is the last piece of the puzzle for me so I do not have to use cgminer anymore.
I hope you are having a great weekend and thanks again.
I believe we've identified all the compatibility issues. Assuming the fixed firmware is released in time, it should be supported in 4.0. |
|
|
|
Also, forgot to mention. You are clueless for not even knowing how your clone miner works, I'd guess since a lot of this code is simply copied (as is this link) and no understanding of it is involved when you do that? https://github.com/luke-jr/bfgminer/blob/bfgminer/miner.c#L8516i.e. the pool doesn't need to be using the X-Stratum header for a MITM attack to simply add it to the connect reply. You can continue to make yourself look like a fool on some other thread. Go away. |
|
|
|
I spent the better part of the day investigating this issue. - It's not a pool side hack - No pool servers are or were compromised
- It's not a pool-side close network hack - No datacenter infrastructure is compromised
- It only affects certain clients, is not pool wide, and affects affected clients repeatedly
Presumably there is some issue with some client side routing hardware that is being exploited. Anyone effected, please post how your connected to the net. PC->Router->Cable Modem, etc, with makes/models of such so we can possibly narrow this down. Also OS. If TCP sequence numbers are being predicted, it could be that the OS isn't making the initial sequence number hard enough to guess. Really there's no excuse for not using SSL, though. Already on it... |
|
|
|
This may be a silly request, but, is there a way to have bfgminer reset after a given period of time?
Because of my location, I'm have some issues with pool access and it would be handy to have bfg reset itself to ensure connectivity.
I'm scratching my head after reading through all the readme's and searching online.
Any thoughts? Something I've missed?
bfgminer-rpc restart |
|
|
|
Just ensure dev_serial gets set to the correct value before add_cgpu is called.
When I list devices with the GridSeed plugged in, I see BFGMiner report the device twice: [2014-04-26 13:01:10] lowlevel_scan: Found usb device at usb:093:002 (path=(null), vid=0483, pid=5740, manuf=STMicroelectronics, prod=STM32 Virtual COM Port , serial=8D801F885551) And then later: [2014-04-26 13:06:39] lowlevel_scan: Found vcom device at dev_t:23000012 (path=/dev/cu.usbmodem3a21, vid=0000, pid=0000, manuf=(null), prod=(null), serial=(null)) The problem I am having is that the first instance, via USB, has the serial number. The second instance does not, and the second instance (vcom) is what is being used for mining. So when the device is probed, the value for detectone_meta_info.serial is NULL. Yes, I'm not aware of any way to get the information on BSD/Mac. |
|
|
|
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... |
|
|
|
BFGMiner will accept serial numbers after @ too, but I'm not sure if the gridseed driver supports this.
How is supporting this different than supporting --set-device other fashions? Any code / docs to reference? I assumed providing set_device was enough and the miner proper was what targeted the devices. Just ensure dev_serial gets set to the correct value before add_cgpu is called. |
|
|
|
Great! Thanks for the quick answers. Thanks also for your involvement in this community. I've seen your blog, of course.
One last question though. Is the list of devices consistent? For example, if I remove or add a device and reboot, do the device "something" values get reassigned?
I ask because with cgminer you specify the device by serial number, which is always independent of USB device discovery.
To answer my own question, it looks like you have to map the Linux dev node to the GSD physical unit. I guess this approach is general in that it potentially allows any device, including GPUs, to be able to be addressable in bfgminer. But it sounds like in the case of USB devices this feature could be pretty difficult to use. Especially if moving a USB device around means that the assigned Linux "dev" nodes change. That would potentially mean that you'd have to remap the frequency to USB devices every time you change your rig configuration. Compare that to the girnyau cgminer where you can specify a device by serial number, regardless of what Linux "dev" node it's assigned. We're seeing GridSeeds pop up in an increasing number of USB products (DualMiners, 5-chip "cupcakes", blades). It strikes me that having a per USB serial number (and possibly per chip) frequency feature in bfgminer would be very useful. BFGMiner will accept serial numbers after @ too, but I'm not sure if the gridseed driver supports this. |
|
|
|
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. 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. It's the reply when you first connect ... No, it isn't. You have removed this option from Eligius? Go away, clueless troll. |
|
|
|
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. 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. It's the reply when you first connect ... No, it isn't. |
|
|
|
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. Generally when I hear "TCP MITM attack" I think of a TCP connection being intercepted, not a client being tricked into going to the wrong IP address. kano might have been thinking the same thing, maybe? Yes, the original pool connection (TCP) is being intercepted to inject a stratum mining.reconnect command; the TCP stream gets broken in the process, but the client has already moved on to the new server by then... :/ |
|
|
|
|
Show Posts
