This article will give some inspiration on how to use AWS Inspector and AWS Config to keep your resources in AWS more secure and compliant
When working on a client project, the subject of securing and protecting bastion hosts in their customers’ environments came up. The most secure bastion host is a non-existing one, but if using Session manager is not an option and you cannot cope without a bastion host, then some security measures should be in place. The most obvious thing to do is to use a hardened image to grant more security, as well as to tighten the security group to which the bastion host is attached by only allowing the really needed ports for ingress.
However, changes may occur in instances that have been running for a long time, or just newly discovered security leaks are detected. If many people are working with it, most probably restricted IPs/ports could be opened on either the security group and/or the instance itself - and sometimes people forget to undo such changes.
AWS Config
For the latter, AWS Config enables you to assess, audit and evaluate the configurations of your AWS resources. In the case described here, it is the Security Group which controls the access to the example bastion host. When AWS Config checks are done, any changes which violate the rules will be forwarded to an SNS topic. This provides the chance to react very quickly to changes done. AWS Config Pricing is based on the numbers of items recorded ($0.003) and the number of rule evaluations ($0.001).
AWS Inspector
Another angle of assessment is provided by AWS Inspector which targets EC2 instances itself. AWS Inspector performs security checks directly on EC2 instances and improves security and compliance of applications deployed.
Instances equipped with the AWS Inspector agent do provide a variety of system specific checks to be assessed on the system. But even without an agent available on the system, AWS Inspector can check the reachability of the instance from the outside, which is, for example, a sufficient check for the scenario with a bastion host when it is just about the networking part of it. Combined with an automated schedule to run assessments and a notification concept, this can become a simple, yet powerful security risk alerting.
Some AWS Inspector characteristics to be aware of:
- AWS Inspector assessments are run from separate AWS managed accounts. Keep that in mind when using terraform or CloudFormation to code your assessments for Inspector individually per region. The rules have to be addressed as listed here.
- AWS Inspector cannot trigger Cloudwatch Event rules. The only way to react to events by Inspector is to use SNS (supported by Inspector) as the target for notifications, and (for example) react on a “Run finished” event by calling a lambda function to further deal with the results and forward a report to an email recipient or save it in a S3 bucket for downloading. AWS Inspector supports 4 Types of events that can be defined in the Assessment Template: “Run started”, “Run state changed”, “Finding reported” and “Run finished”.
- All scanning results can be retrieved from the AWS management console by clicking “Download report” - which generates a PDF based on your selection of detail level and provides a download link. Such a link is temporary, so just sending the link to some alerting target via mail for example would only enable the recipient to download the report as long as it is available. A better solution is to download the file and store it in S3, or send it as email attachment. All this can be done for example using a Python lambda function using boto3. It gets all the details from the event which is sent through SNS by Inspector:
- use the Inspector run ID from the event → describe the assessment_run
- get the assessment_template_arn from the run details
- and so on and so forth in that manner
- full list of attributes
- If you are using infrastructure as code, you were most probably experiencing a lot of non-declared magic happening under the hood when using the AWS management console. Be sure to grant the correct resources access, for example your SNS topic that receives the Inspector events needs allowance for Principal type “Service” from ‘inspector. amazonaws. com’". These are probably things one misses when trying to reproduce console edited assessments as code.
Of course there is no need for using a lambda for filtering and report generation if you just want to be notified that a new report can be retrieved manually from the console. Simply provide the desired subscriptions to the SNS topic. The only event type needed is the “Run finished” event type; reporting every event will result in a lot of notifications. This is the only one interesting for both described cases, with and without a lambda for filtering and report generation.
AWS Inspector pricing depends on the number of assessment runs and details. One network reachability check suitable for the scenario of this article is $0.15, which adds up to $4.5 a month if run once a day.
Conclusion: it does not prevent changes that can affect security, but it alerts you if it happens so you can react.
Both of the described services can do the trick for the scenario provided here. The one you might choose depends a lot on surrounding factors and the final goal you would like to achieve. If you just want to cover this one aspect, the usage of scheduled Inspector assessments should give you the most flexibility and control. For more scenarios to be covered, the set of AWS services discussed here can be combined as needed. AWS Inspector is instance specific and scans actively for flaws and breaches. AWS Config records any resource you like to keep in close control and provides notification about changes and compliance violations. In many cases, a mixture of both would be a good choice.
Photo by Saj Shafique on Unsplash