Using Alexa to scan your EC2 instance by their first name (through Tagging) with AWS Inspector
“AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and application.” —outlined in the AWS Shared Responsibility Model
Amazon Inspector is a tool that allows AWS customers to scan their EC2 instances for security issues. In this tutorial, I’ll show you how I set up an Alexa skill to launch Inspector scan by server name with the use of Tags.
Here is a quick preview:
You will need the following to get started:
- Alexa Developer Account, create one @ https://developer.amazon.com
- Some AWS Knowledge such as basic navigation around console, launching EC2 instances
- Code link right here for files.
- There may be some region limitations so for this project I worked out of ‘us-west-2’ region aka Oregon for the Lambda part.
First, I know I needed to use Inspector Agents with a Role to get accurate vulnerability information from an Inspector assessment.
As stated in the SSM documentation, AWS Systems Manager does not have default permission to perform actions on your EC2 instances so I created the IAM role first. I jumped over the IAM and clicked Create Role.
I searched for ssm and selected AmazonEC2RoleforSSM.
I named the role InspectorRole and created it.
Red & Blue Instance
Switching over the EC2, I set up two instances; one Red Hat and the other Windows 2019 Base. For the Red Hat instance, I used most of the default settings except for Tagging. I gave this instance the tag name Bob.
For the Windows instance, similar set up, except with the tag name Charlie.
I created one SecurityGroup, for both instances, and added an ingress rule to allow SSH(22) and RDP (3389) ingress from my IP address. I also used the same key for both hosts for this tutorial.
After the instances were created, I assigned the role created earlier to each.
Installing the agent (singular)
If you haven’t used Inspector before, I recommend reading the documentation to determine the best rules package.
I jumped over to Inspector. On this screen, I clicked Cancel to continue to the Dashboard to skip to the next screen.
Since I was creating two separate scans but both hosts were in the same region and account, I unchecked Including All EC2 instances…etc.
I created two assessment targets based on the tag name; one for Bob and one for Charlie.
After the targets were created, I hit Install Agents with Run Command. Within a few minutes after the Run Command was initiated, the Windows agent was listed as Healthy after a previous state of Unknown.
The Red Hat instance, however, needed a few extra steps since it was still Unknown. I jumped over to System Manager to see a history of the run commands.
After a quick review and the seeing no errors, I decided to manually install the agent for the Red Hat instance. I SSH’d into the instance and ran the following commands:
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent
sudo systemctl status amazon-ssm-agent
I then ran the Run Command one more time, waited a few minutes, and the agent came back Healthy when previewing target.
The last step for this phase is to create Assessments Templates. When we invoke the Alexa skill, it’ll be looking for the assessment with the same tag as mentioned during invocation (the user saying ‘Scan bob’).
Here is the configuration for both templates except with different name, target, and tag. Check out the tag.
Inspector configuration complete — now time for the back end logic.
Back end Logic
I switched over to Lambda and started from scratch with a new function.
Since I was using custom code and python libraries (other than boto3), creating custom lambda package was required. To create lambda package for upload, I did the following steps:
virtualenv --python=/usr/local/bin/python3.7 .
pip install boto3
pip install ask-sdk
pip install datetime
# copy + paste + save code from github repo found here:
zip -r9 lambda_package.zip .
Once created, I uploaded the zip file.
If you don’t have the existing role lambda_basic_execution, you can create it by clicking Custom Role.
To give the function more time to process the request, I increased the timeout from 3 seconds to 10. Adjust as necessary.
Next, I added an Alexa Skills kit.
You’ll need to head over to the Alexa Developer Portal and create a new skill. You will save that Skill ID in the field as seen below.
NOTE: Keep in mind the ARN (Amazon Resource Name) of the Lambda function since it will be needed shortly.
After logging into the Alexa Portal, I created a new skill with the invocation (the name to call the skill) of scanner.
Under JSON editor, copy and paste the contents of the .json file in this project’s GitHub.
The Endpoint’s Default region will be the ARN of the lambda function created earlier.
Save and build model.
The last setting is to give lambda additional permissions then onward to testing.
I switched over to IAM to create a small policy using the JSON here. Then, I took that policy and applied it to the role lambda_basic_execution from earlier.
I was traveling during the making of this, I used the Testing section on the skill I created. This allows you to interact as if you were talking to an Amazon echo device.
I opened the skill and scanned both Bob and Charlie by name.
If you switch back to Inspector, two scans should be running. Success! Happy Scanning.
Thanks for taking the time to read this. Please let me know if you run into any issues or if you have any feedback.