« Previous 1 2 3 Next »
AWS security scans with Scout2
Dig Deep
A Murder of Crows
From the size of the policy – roughly 85 actions – you can see why it's helpful first to try an example policy provided by NCC. The services tend to range from describing (e.g., ec2:DescribeSecurityGroups ) to listing (e.g., iam:ListAccessKeys ) to reading service data (e.g., s3:GetBucketLocation ).
To add this custom policy to an AWS user (the user that will need the access and secret keys later on), log in to the AWS console and visit https://console.aws.amazon.com/iam
. In the left-hand menu, click the Policies
link to open that page (Figure 1). Next on the Policies page, click Create Policy
near the top of the screen and then the JSON
tab (Figure 2). Make sure you delete the JSON already present before pasting the NCC policy from GitHub; you can save it with a name like NCC-Scout2-policy
.
You might need to indulge in a little trial and error if you didn't delete the original JSON properly (e.g., missing a closing curly bracket or making some other error before pasting NCC's example policy), but it's not too tricky to figure out, even if JSON isn't your best friend.
Thankfully, AWS has given some forethought to eye strain by generating a human-readable policy table from the new policy you entered (Figure 3). This table lets you see which keys you're giving to Scout2 and to which kingdom.
When you are back on the IAM screen, look at the left-hand menu (the menu in Figure 1) and choose Users . Next, you should select the user that will run the scan (make sure you definitely have access to that user's access and secret keys).
Finally, you need to attach the NCC-Scout2-policy to your IAM user by simply clicking your username link on the Users page and then clicking Add permissions . On the next page, choose the box that says Attach existing policies directly . Find your freshly created policy with a simple search for NCC , or whatever you called your previously saved policy, and then attach it to your user. Now, via IAM, your user can perform the actions named in the policy.
A Parliament of Owls
The next step is to get the Scout2 auditing tool up and running. Once the scan is complete, Scout2 thoughtfully attempts to open a window in a web browser to show the results of your tests, so you need to be a non-root user to install Scout2 (on my Linux Mint laptop, at least). I'm quite happy navigating as the root user to the directory with the resulting HTML report, if needed, so you should decide at this stage which local Linux user you want to run Scout2. Be aware that if you use a non-root user, your AWS credentials will be on your local machine available to a non-privileged user, which is why I use the superuser to add a little more security and privacy.
One other very minor thing to consider is that if you do use a non-root user, some of the packages might potentially need to be installed as the superuser beforehand.
A Waddle of Penguins
If you've used the Python Pip package manager, you probably already have setuptools and Pip installed. To install Pip on Debian derivatives, use the command:
$ apt install python-pip
On Red Hat Enterprise Linux derivatives, you might need to enable the extra packages repository, which is commonly referred to as EPEL. (You'll find much more about EPEL online [5].) On CentOS, for example, you run the command
$ yum install epel-release
to enable the repo. Refer to the EPEL page for help if you need it.
Once Pip is installed, you can install the setuptools package with your shiny new Pip package manager:
$ pip install setuptools
Next, pull down the Scout2 package:
$ pip install awsscout2
If you want to install Scout2 from source, so you can have a rummage in the package to check for suspicious activity that might compromise your AWS account(s), you can run the following commands, which are also found on the NCC GitHub page:
$ git clone https://github.com/nccgroup/Scout2 $ cd Scout2 $ pip install -r requirements.txt $ python setup.py install
If you've used the AWS application programming interface (API) before, you've also likely installed the relatively miniscule command-line tool called awscli
. My package manager seemed to have a less compatible (possibly older) version of awscli
, so I used the faithful Pip package manager yet again to install my preferred version:
$ pip install awscli
If you get stuck, check out the AWS docs [6].
You might need to add awscli
to your user's path [7], which Pip put in your home directory, by entering something along the line of:
$ export PATH=~/.local/bin:$PATH
The final easy hurdle to jump over is copying your user's AWS access key and secret key into the credentials file on your local machine. These should be saved in your ~/.aws/credentials
path.
Head to the main IAM screen again in your AWS account to set up a new key if you don't have one. Assuming you're using an IAM user and have disabled or aren't using the AWS root account, as advised by AWS, you can use the same menu again (Figure 1) to select Users and click on the correct username link. You're looking for the Security credentials tab shown in Figure 4.
Click the Create Access Key
button and you're off. Keep a careful note, encrypted, of the secret key, because this is the only time you will see it in AWS. To copy your credentials
file locally, use the format:
[default] aws_access_key_id = your_access_key_id aws_secret_access_key = your_secret_access_key
Replace both bits after the equals signs with the relevant info. If you get stuck or you're new to this process, then once you have installed awscli
, run the command
$ aws configure
to walk through the configuration; otherwise, you can read the credentials docs on the AWS website [8] or search online for other instructions. Generally, you should just need to copy the access and secret keys into the appropriate files, without having to export variables and other items.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)