What settings should I use for Amazon S3, and how should I configure my Amazon S3 account?

This answer assumes that you have already created your Amazon S3 account, and have made a note of your S3 access key and secret key. If not, then go here: http://aws.amazon.com/s3/.

When you enter your Amazon S3 details in the WHMCS Firewall module S3 backup settings, complete all fields and in the use the “bucket name” in the “S3 location:” field.

What permissions do I need to set on the Amazon S3 bucket (in the Amazon S3 console)?

Do NOT use your master S3 access and secret keys.
You have to setup a different user with its own access and secret keys (which can be done using the Amazon AWS console’s “IAM” service), then you will need to make sure that the user has enough permissions.

Exactly what user policy is right for your use-case depends upon what that use-case is. However, if you have a user “whmcsfirewalluser” and a bucket called “whmcsfirewallbucket”, then the following policy is sufficient to give that user all the permissions that WHMCS Firewall requires to access that bucket, and only that bucket:


{
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:ListBucket”,
“s3:GetBucketLocation”,
“s3:ListBucketMultipartUploads”
],
“Resource”: “arn:aws:s3:::whmcsfirewallbucket”,
“Condition”: {}
},
{
“Effect”: “Allow”,
“Action”: [
“s3:AbortMultipartUpload”,
“s3:DeleteObject”,
“s3:DeleteObjectVersion”,
“s3:GetObject”,
“s3:GetObjectAcl”,
“s3:GetObjectVersion”,
“s3:GetObjectVersionAcl”,
“s3:PutObject”,
“s3:PutObjectAcl”,
“s3:PutObjectAclVersion”
],
“Resource”: “arn:aws:s3:::whmcsfirewallbucket/*”,
“Condition”: {}
},
{
“Effect”: “Allow”,
“Action”: “s3:ListAllMyBuckets”,
“Resource”: “*”,
“Condition”: {}
}
]
}

What is the most secure possible setup?

Since the WHMCS Firewall module needs to store an S3 API key and secret to upload your backups to S3, there is a potential point of weakness. If a hacker breaks into your site, then he can steal that API key + secret, and use it to access your backups. Ideally, the hacker should not be able to delete or change your backups – you want to know that backups taken before hackers break-in are “clean” and can be deployed without fear.

To accomplish this with an Amazon S3 setup, implement these recommendations. They involve more complexity, but given the securest possible setup:

1. Do not use your “master” API key + secret (which can access all your S3 data). Instead, setup a separate IAM user (which will thus have its own API key and secret). (Note – this is an IAM policy, not a bucket policy. You will need to switch back and forth in the Amazon AWS console between S3 to IAM a few times during these steps.)

2. Set up a bucket from the Amazon S3 console (https://console.aws.amazon.com/s3/) for your WHMCS Firewall backups, and only for these.

3. In the AWS console, bring up the bucket’s properties (either right-click on the bucket and choose “Properties” from the menu, or left-click and use the “Properties” button). Enable versioning. What is versioning? It means that if an attacker gains access to your bucket, and over-writes your backups (e.g. with a new, hacked version), then the previous versions still remain accessible. They are not deleted.

4. Set up a policy for that IAM user, as above, but without the two delete permissions.


Without these two lines:
“s3:DeleteObject”,
“s3:DeleteObjectVersion”,

5. Finally, since WHMCS Firewall cannot now delete historic backups, you will need to manage this another way (the “retain this many” setting in WHMCS Firewall will take no effect). The easiest way to do this is to use S3′s built-in “life-cycle” feature, in the bucket properties (See step 3 above).

That’s it. What is the total effect of those changes? It means that WHMCS Firewall is configured with Amazon S3 access credentials that can only write to the defined bucket, and no others. It cannot delete any existing backups. Its ability to write, however, still means that it can overwrite existing backups, which is an effective a way of deleting them, as well as tampering with them. Therefore, we add versioning in order to make sure that over-writing does not destroy existing backups.

The final part of this is that:

1) if restoring, you should retrieve your backup sets directly from the Amazon S3 console rather than from the WHMCS Firewall dashboard’s built-in method

2) if you press the “Test S3 Settings” button, then it will create a test file, and report that it failed to be able to delete it. This is now expected, so do not worry about it.

Don’t know what any of this means? Would it take you a month or never to get it all going?? Contact us by opening a support ticket so we can help! :-)