Incident Response as Code Bootstrap

I want to share a potential option to deploy a bastion/forensic workstation with a micro-pipeline quickly for Incident Response as Code in an AWS account and or organization.

ACCESS REQUIREMENT

Single Sign-On (SSO) needs to exist to handle authentication and authorization for this method to work.

CLOUD9 BASTION

I prefer to use Cloud9 as my forensic workstation these days. It comes pre-installed with most of the necessary developer tools to stand up new infrastructure to process an investigation.

cloud9-environment

Choose no-ingress EC2 instance for the environment (access via Systems Manager). No ingress security group rules or ssh key pairs exist on the Cloud9 host this way. The disadvantage is that not all EC2 and System Manager (SSM) traffic remains in the VPC unless Endpoints get established.

cloud9-vpc-endpoints

Free-tier is not always the best long-term solution as T2 instances do not support VPC Traffic Mirroring if packets are ever required. Select any Cloud9 instance type except T2 that meets your process, memory, and budget requirements.

https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-considerations.html

cloud9-instance

Typically I have been using Amazon Linux 2 as it has AWS CLI and SSM Agents installed by default.

cloud9-platform

For the budget-conscious, Cloud9 has an auto-hibernate feature to shut off EC2 when not in use, so you only pay for allocated Elastic Block Storage (EBS) costs when not running. Unfortunately, this volume will not have disk encryption enabled at launch.

cloud9-cost

Cloud9 requires Internet or VPC Endpoint access to the EC2 and SSM APIs to provide access. The disadvantage is a public IP is assigned even if the host gets launched in a private subnet.

cloud9-vpc

I tend to enable termination protection as a fallback safety net if I forget to commit my code.

STILL BEATS LOCAL DEVELOPMENT

The default installation only has 10 GB of storage allocated, not leaving enough room for all the necessary dependencies. I would recommend a minimum of 20 GB for your disk storage starting point.

8-modifyvolume

These commands will finish expanding the disk space available for the operating system.

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk 
└─xvda1 202:1    0  10G  0 part /
$ sudo growpart /dev/xvda 1
$ sudo reboot now

The volume usually does not have the space available to patch until after the disk modification is complete.

$ sudo yum update -y

Check to make sure you are on the most current AWS Cloud Development Kit (CDK).

$ cdk version

Newer versions of CDK on Cloud9 may allow a simple update path.

$ npm install -g aws-cdk

If the command returns any errors, the .npm and .nvm hidden directories will need deleting before a full install of CDK.

https://docs.aws.amazon.com/cloud9/latest/user-guide/sample-cdk.html

$ sudo rm -R ~/.npm ~/.nvm
$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash
$ nvm install stable
$ npm install -g typescript
$ npm install -g aws-cdk
PRE-REQUISITES

Install AWS CLIv2 to be able to authenticate against SSO from the command line.

https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ sudo ./aws/install
$ aws --version
aws-cli/2.2.9 Python/3.8.8 Linux/4.14.232-176.381.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off

Install YAWSSO to synchronize AWS CLIv2 SSO login sessions to legacy CLIv1 credentials for CDK bootstrapping.

https://github.com/victorskl/yawsso

$ pip3 install yawsso

Install AQUEDUCT to automate Cloud Development Kit (CDK) bootstrapping into an AWS Organization using Single Sign-On (SSO).

https://github.com/4n6ir/aqueduct

$ pip3 install aqueduct-utility
SSO AUTHENTICATION

Disable the AWS managed temporary credentials to use the SSO login.

cloud9-temp-creds

Configure the AWS CLIv2 to use SSO access for Cloud9 in the current account to obtain command-line permissions. If you need extra help, here is a link to some excellent documentation.

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

$ aws configure sso
AQUEDUCT CONFIGURATION

First, we need to set up the utility to use SSO for CDK bootstrapping.

$ aqueduct 
SSO Start URL [ ]: https://portal.awsapps.com/start
SSO Region [ ]: us-east-2
SSO Role [AWSAdministratorAccess]: 
CLI Region [ ]: us-east-2
CLI Output [json]:     
CDK Qualifier [ ]: 4n6ir
CDK Trust [ ]: 111111111111 
add -h or --help for usage help

Next, we need to add accounts, regions, and tags necessary to bootstrap the accounts and regions.

$ aqueduct --addacct
Account Name [ ]: Pipeline
Account Number [ ]: 111111111111

$ aqueduct --addreg
Region [ ]: us-east-2

$ aqueduct --addtag
tag i.e. key=value: 4n6ir=4n6ir

Then, we can synchronize the SSO ~/.aws/config and legacy CLI ~/.aws/credentials files.

$ aqueduct --ssosetup

$ yawsso

Now, we can bootstrap a micro-pipeline for performaing Incident Response as Code.

$ aqueduct --bootstrap
CDK_NEW_BOOTSTRAP set, using new-style bootstrapping
 ⏳  Bootstrapping environment aws://111111111111/us-east-2...
Trusted accounts:   111111111111
Execution policies: arn:aws:iam::aws:policy/AdministratorAccess
cdk-bootstrap-4n6ir-111111111111-us-east-2: creating CloudFormation changeset...
[██████████████████████████████████████████████████████████] (11/11)

 ✅  Environment aws://111111111111/us-east-2 bootstrapped.
REFERENCE

https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html