Running ethminer results in prompt flagging of the account by AWS, shutting down operation
blazczak opened this issue · 3 comments
Mike,
What are your stacks creating behind the scenes that is causing all sorts of alarm bells to go off on the AWS side, prompting them to completely shut down ethminer operation and prevent new stacks from being created (resource creation now errors out with AccessDenied messages). Can anything be refactored in the code/configured/communicated to AWS ahead of deployment to prevent such brute forced, to say the least, downtime?
This has resulted the most idiotic message exchange from AWS support that I've ever seen, they're telling me that the account was compromised and request securing the account, but when I change the password, tell them that the access was authorized and there was no intrusion, they keep sending the same canned email response back about checking logs and removing compromised accounts.
Not happy with how this mining operation was promptly derailed by AWS; this has delayed operation and wasted a lot of my time. It's okay to flag suspicious activity to the account owner, but not without providing an efficient way to confirm and authorize usage to get on with business as before; similarly to confirming if a suspicious sign in to an email account was initiated by a legit entity.
Many people have used this template successfully without any issues, including me obviously.
It’s possible that you’ve got GuardDuty or AWS Shield or some other enhanced security configured in AWS on top of the standard settings, that may have detected an unusual activity and triggered the alarms.
All I know is that mining doesn’t cause any issues or alarms in the typical aws accounts with standard configuration. You may want to disable the extra security services to silence the alerts.
Without knowing more details about the source of the alarms I can’t really tell.
Honestly, it's been a nightmare dealing with AWS support after the account was flagged days ago as "compromised" after launching these stack definitions. I'm still wasting my time working with them to get my account cleared and brought back to operational.
From their inquiries about the presence and the purpose for the IAM roles created as part of stacks it looks like that's what tripped the alarm(s). My account is vanilla, no custom settings enabled - so I don't quite buy that any "enhanced security" outside of the stacks is grounds for this hawkish conduct.
The worst part is that AWS support is only interested in closing tickets as quickly as possible so they can accumulate brownie points in the tracking system. The emails sent by support are incoherent and incomplete, and downright misleading - after they flagged the account they warned that "Failure to contact AWS within five (5) days may result in the suspension of your account and disruption of your AWS services"; after I contacted them they used the mere presence of my communication to them to conveniently close all of the other pending requests, "because you have that one specific ticket open...".
An awful way to be treated as a legitimate customer.
Well, what can I say. The IAM roles are pretty standard as you can see in the templates, no one else reported any issues in this regard. There is nothing else created "behind the scenes".
You can post your conversation with AWS so that we can try to decipher what's the problem that they have. Without further details I can't really provide any advice, sorry.