Skip to content
This repository has been archived by the owner on Jan 22, 2023. It is now read-only.

Security concern: Access to machine allows deleting it's own backups #18

Open
markstos opened this issue Dec 2, 2015 · 3 comments
Open

Comments

@markstos
Copy link

markstos commented Dec 2, 2015

Separating out the permission to create snapshots from deleting snapshots would improve security.

Currently, if this is running in a host and the host is compromised, the attacker would have permissions to delete all the snapshot backups of the host as well as the host itself. Not good.

With the broad recommended IAM permissions, an attacker with access to a single host running this tool could delete snapshots for any host in the AWS cluster.

On the other hand, the ability to for an atttacker to create new snapshots of the machines gains them little.

It's valuable for the "create" function to run within the host, so it can also do things like freeze the filesystem or a database. However, there's no requirement that the "delete" statement be run within the host.

For additional security, all the "snapshot expiration" for your cluster could be run externally. One approach someone used was to combine "Lamda functions" and "Cloudwatch alarms" to run tasks like "cron jobs" that were not tied to a particular host:

https://forums.aws.amazon.com/thread.jspa?messageID=674123#674123

@CaseyLabs
Copy link
Owner

Hi Mark,

I agree with you 100%. In fact, this is a change I've made in my own private branch that I use in production (albeit in very beta/dev/hack quality fashion).

I should have some free time at the end of December to do a complete re-write on this project. Features I would like to include (and that have been requested):

  • Change the script so that it accepts arguments for which functions should run. For example:
ebs-snaphsot.sh snapshot all
ebs-snapshot.sh snapshot /dev/sda1
ebs-snapshot.sh clean /dev/sda1
ebs-snapshot.sh clean all
  • Update the recommended IAM policies so that:
    a) Regular hosts can only take snapshots
    b) Deleting snapshots can only be performed by an Admin server
  • Redo how logging is done.
  • Merge in the Docker compatibility that @bkrodgers submitted as a pull request.
  • Finally, I would like to add an optional filesystem freeze flag to run before taking snapshots.

Anything other suggestions that you have? @jboeshart, any feedback on features that you would like to see as well?

@markstos
Copy link
Author

markstos commented Dec 2, 2015

That all sounds good. It could be interesting to add a "SEE ALSO" section to the docs to compare to the popular option of ec2-consistent-snapshot + ec2-expire-snapshots.

The way I see it, ec2-consistent-snapshot has more options, like filesystem and database freezing, while the benefit of this script is that it has no dependencies. ec2-consistent-snapshot is written in Perl and has quite a few dependencies. They are easily handled by installing the Debian or Ubuntu package, but there's simply more machinery and things to get out of date.

@CaseyLabs
Copy link
Owner

Agreed on the "See Also" section, and with the project's simplicity. This project started because of a very specific use case (very small deployment that needed a simple Bash script to automate snapshots). But as the script's popularity has grown, the community's needs/use-cases have also expanded.

I would like to see this project expand to meet those use-cases, but also maintain its lack of dependencies (i.e. it will always use the AWS CLI and nothing else) while retaining its simplicity.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants