NET309_Best Practices for Securing an Amazon Virtual Private Cloud

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Best Practices for Securing an
Amazon Virtual Private Cloud
W O R K S H O P
N o v e m b e r 2 8 , 2 0 1 7

Welcome to the workshop
• We have a number of AWS staff in the room:
• Martin Bishop, SA Manager, UK public sector
• Rob Cambra, Sr Solutions Architect, Startups
• Anya Episheva, Sr. Consultant, UK public sector
• Michael Hall, Sr. Solutions Architect, US public sector
• Matt Johnson, Sr. Solutions Architect, UK public sector
• Miguel Rossi, SA Lead, EMEA public sector
• Your fellow conference attendees at your table
• Say hello, share your objective for the workshop
• Get together in small teams (3-5 people)
• Decide who will be following along with their laptop

If you want to go hands-on
• Make sure your account meets the following limits:
• Full IAM Administrator access
• We will be working in either us-west-2 or eu-west-1
• Check limits in those regions; you need the ability to create 3 VPCs and 3
Elastic IPs
• Existing SSH key pair (note you don’t need to SSH into boxes)
• For your laptop
• Ability to receive emails (to see the alert notifications)
Note: We will provide a $25 credit voucher at the end of the workshop to
cover the cost of deploying the workshop resources

To get started…
• Workshop details can be found here:
• bit.ly/net309
• Please deploy the following CloudFormation template in the link
• Should take about 15-20 minutes
• Forms the basis of the rest of the workshop
• Ask if you have any problems deploying the stack!

Workshop: Assumptions
This workshop assumes an introductory (200 level) familiarity with:
• AWS Global Infrastructure
• Regions, Availability Zones, Edge locations
• Amazon VPC concepts
• Subnets, Route Tables, Gateways
• Amazon EC2 concepts
• AWS Load balancing, Auto-scaling groups
• AWS IAM concepts
• Users, groups, policies, roles
• AWS CloudFormation

Workshop: Approach
• Going to be looking at the architecture of a hypothetical organization,
Octank, delivering web-based applications to a range of customers
• Assess their initial VPC architecture
• Identify additional security capabilities
• Review 3 types of security controls
• Preventative
• Detective
• Automated
• Identify the AWS services that help implement these controls

Workshop: Approach
• Try some hands-on implementation of these controls
• Preventative controls
1. VPC security best practices
2. Securely integrating ELB, Amazon CloudFront and AWS WAF
• Detective controls
1. Filtering and alerting on VPC Flow Logs
• Automated controls
1. Automated VPC remediation via CloudWatch Events
2. Updating SSH keys using EC2 Systems Manager (if time permits!)

Scenario: Octank

Scenario: Overview
• Octank has adopted AWS and is currently running production web
application workloads in the cloud
• It has followed best practices for architecting its workloads for high
availability and scalability
• It wants to ensure its security posture follows AWS best practices
• Where possible, it wants to use AWS native services
Note: This scenario is slightly artificial; this has been done to try and cover a
range of topics given the available time within the workshop

Architecture public-elb-a
nat-gw-a nat-gw-b
AL
B
public-elb-b
pri-web-a
web
AS
G
priv-web-b
App-VPC
db
pri-db-bpri-db-a
VP
CPe
er
Data-
VPC
pri-mgmt-a
bastion
priv-mgmt-b
VP
CPe
er
VP
CPe
er
Mgmt-VPC
Flo
w
log
Flo
w
log
Flo
w
log
Amazon
CloudFro
nt
AWS
IAM
AWS
CloudTr
ail
AWS
Config
Amazon
EC2 SSM

Preventative controls

Preventative controls
• Controls that stop malicious, unintended, or otherwise undesired
activities from taking place
• Typically work against a baseline security requirement (e.g., no port 22
access from the Internet), often following proscriptive guidelines
• Represents a “desired” state for the infrastructure

Preventative controls in AWS
• VPCs, security groups and network ACLs
• Routing & Peering
• Data-in-transit Encryption
• AWS WAF and Shield
• VPC Endpoints
• IAM Policies

VPCs, subnets, gateways, peering

VPC subnets & gateways
• Public subnets
• Internet-routable directly via an Internet gateway
• Private subnets
• Internet-routable (outbound) only via a NAT gateway or instance, or
• Not internet-routable at all (VGW/VPC peering connectivity only)
• Gateway types
• Internet Gateway (IGW)—allow Internet access to public subnets
• NAT Gateway (NGW)—allow outbound Internet access to private subnets
• Virtual Private Gateway (VGW)—allow private access to subnets

NAT Instance vs. NAT Gateway
Attribute Nat Gateway Nat Instance
Availability Highly-available per AZ Scripted failover within an AZ
Performance Burstable to 10 Gbps Dependent on NAT instance size to 5 Gbps
Maintenance Managed by AWS Managed by customer
Cost Depends on duration and data volume Depends on duration and instance size
Security Supports NACLs only Supports security groups and NACLs
Monitoring Flow Logs and CloudWatch support Flow Logs and CloudWatch support
Fragmentation UDP support only UDP, TCP, and ICMP support

Subnet
Addressing
Web Subnets
Super-block (all AZs) 192.168.10.128/25
AZ-A 192.168.10.128/26
AZ-B 192.168.10.192/26
ELB Subnets
Super-block (all AZs) 192.168.10.0/25
AZ-A 192.168.10.0/26
AZ-B 192.168.10.64/26
• Assign address by tier, then by AZ
• Simplifies cross-referencing tiers in Network ACLs
• Refer to tiers by their “super-block”

Specific
routing
Route Table for App VPC public subnets
Destination Target
192.168.100.0/24 Local
0.0.0.0/0 igw-1234567
Route Table for App VPC private subnets
Destination Target
192.168.100.0/24 Local
0.0.0.0/0 ngw-1234567
192.168.200.0/24 pcx-peerappdata
Route Table for App VPC private subnets
Destination Target
192.168.200.0/24 Local
0.0.0.0/0 ngw-1234567
192.168.100.128/25 pcx-peerappdata
Private subnets
superblock only

VPC peering
• Networking connection between two VPCs
• Peering connection can be made between
• Your own VPCs, and/or…
• …VPCs in another AWS account…
• …but only within the same region
• Uses the underlying Amazon VPC infrastructure
• Doesn’t create a bottleneck
• No single point of failure
• Consider it an extension of your existing VPC, use security groups and
NACLs appropriately

Challenges of VPC separation
• Management overhead due to increased complexity
• Peering mesh management
• IP address space management
• VPC peering data transfer costs
• Remember AWS service limitations
• RDS authentication via AWS Microsoft AD is for a single VPC only
• Network Load Balancer endpoints cannot be accessed via VPC peering
• No transitive routing between multiple VPCs

Security groups & network ACLs

Security groups vs. networks ACLs
Security group Network ACL
Operates at instance level Operates at subnet level
Supports allow rules only Supports allow and deny rules
Is stateful: return traffic is automatically allowed
regardless of any rules
Is stateless: return traffic must be explicitly
allowed by rules
All rules evaluated before deciding whether to
allow traffic
Rules evaluated in order when deciding whether
to allow traffic
Applies only to instances explicitly associated
with the security group
Automatically applies to all instances launched
into associated subnets
Doesn’t filter traffic to or from link-local addresses (169.254.0.0/16) or AWS-reserved IPv4 addresses;
these are the first four IPv4 addresses of the subnet (including the Amazon VPC DNS server)

Reasons for using network ACLs
• Allows for separation of duties
• Different IAM actions mean that management of Network ACLs can be
handled separately from security group configuration
• Gives the ability to specify explicit deny rules
• Allows you to blacklist specific IP addresses/ports
• Provides a mechanism to sever connection-tracked network flows
• Immediately drop established connections when security group rules are
changed 1
1 docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-
security.html#security-group-connection-tracking

Gotchas
• Security groups don’t implicitly allow East-West traffic
• Instances within a security group can only talk to each other if explicitly
allowed by relevant rule(s)
• Note: the default security group has this exception!
• Rules that use security group references and/or private address ranges
will only work for connections that target private IP addresses
• Connections from within the VPC to public IP addresses will be rejected,
because the source will appear to be from a public IP address
• Be careful with Network ACLs and Amazon Elastic Load Balancers (ELBs)
• Allow health check traffic from the ELB subnets to the backend subnets
• ELB traffic goes via the VPC router, even in the same subnet

Hands-on (1): Initial VPC review

Hands-on (1)
• Check that the CloudFormation template has completed successfully
• Check the web page returned from the ALB endpoint
• Check the web page returned from the CloudFront endpoint
• Have a look around the resources that have been deployed
• What security “issues” can you find?
• What improvements do you think you could make?

Hands-on (1): Areas for improvement
• Preventative controls
• Specific routing for private-only subnets
• Outbound security group rules
• No current use of Network ACLs
• Web server EC2 instance roles have administrator privileges
• ALB isn’t restricted to Amazon CloudFront traffic only
• Detective controls
• Missing VPC flow logs on the Data VPC
• Anything else?

Lab Checkpoint
• Make sure you have updated the Hands-on Lab 1 parameter
• Should be set to “Deployed via CloudFormation”

VPC endpoints
I n f r a s t r u c t u r e P r o t e c t i o n — S e r v i c e - l e v e l p r o t e c t i o n

Amazon VPC endpoints
• Customer requirements for access to AWS services from private VPCs
• Scenarios where only Direct Connect/VPN connectivity to VPCs
• No egress in the VPC to public networks (and hence AWS endpoints)
• Amazon VPC endpoints
• Gateway Endpoints
• Interface Endpoints (AWS PrivateLink)

Amazon VPC endpoint types
• Amazon VPC Gateway endpoints
• No IGW, NGW or public IP addresses required
• Private IP access to Amazon S3 and DynamoDB
• Content-specific access controls
• Robust access control
• Amazon VPC Interface Endpoints (AWS PrivateLink)
• No IGW, NGW or public IP addresses required
• Private IP access to specific AWS service endpoints
• Security group access controls

Availability Zone A
Private subnet Private subnet
AWS
Region
Virtual
Private
Gateway
Intranet
app
Intranet
app
Availability Zone B
Amazon
S3
VPC
VPN
connection
Customer
network
VPC Gateway endpoints

Creating S3 VPC Gateway endpoint
aws ec2 create-vpc-endpoint
--vpc-id vpc-xxxxxxxx
--service-name com.amazonaws.us-west-2.s3
--route-table-ids rtb-yyyyyyyy
Private subnet
VPC
Route Table
Destination Target
10.1.0.0/16 Local
Prefix List for S3 us-west-2 VPCE

VPC Gateway endpoint prefix lists
• Logical route destination target
• Dynamically translates to service IPs
• S3 prefix lists abstract changes to S3 IP ranges
• Can be used in security group rules
aws ec2 describe-prefix-lists
PREFIXLISTS pl-68a54001 com.amazonaws.us-west-2.s3
CIDRS 54.231.160.0/19
CIDRS 52.218.128.0/18

Private subnet
AWS IAM policy for the VPC endpoint
VPC
{
"Statement": [
{
"Sid": "vpce-restrict-to-backup-bucket",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject”
],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::backups-reinvent",
"arn:aws:s3:::backups-reinvent/*"]
}
]
}
Bucket
Controlling VPC access to Amazon S3

Private subnet
S3 bucket policy
VPC
Bucket
Controlling VPC access to Amazon S3
{
"Statement": [
{
"Sid": "bucket-restrict-to-specific-vpce",
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": ["arn:aws:s3:::backups-reinvent",
"arn:aws:s3:::backups-reinvent/*"],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-bc42a4e5”
}
}
}
]
}

VPC Interface Endpoints (AWS PrivateLink)
• Interface endpoints are created
directly inside of your VPC
• using Elastic Network
Interfaces (ENIs) – one per AZ
• IP addresses in your VPC’s
subnets
• Accessible via Direct Connect

VPC Interface Endpoints (AWS PrivateLink)
• Support for Private DNS names
• Over-ride DNS for the AWS service DNS name
• Allows for transparent implementation
• Currently supported services:
• Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager (SSM),
and Elastic Load Balancing

Traffic within a VPC
• Data within a VPC is isolated from other customers
• Robust isolation of traffic flows between customer accounts
• Demonstrated by various AWS controls and certifications (PCI-DSS, etc.)
• Flows internally within an Amazon-operated network
• Customer is responsible for in-transit data encryption
• Application level (TLS) encryption

Encryption using AWS-managed services
• Use AWS-managed services to offload encrypted traffic
• Allow AWS to manage the SSL certificates/termination endpoints
• Decrypt (and optionally inspect) traffic at the network edge
• Connect (and optionally re-encrypt) traffic to customer instances
• AWS services that support encrypted traffic offload
• AWS Certificate Manager
• Application Load Balancer
• Amazon Classic Load Balancer (Layer 7 mode)
• Amazon CloudFront
• Amazon API Gateway

Encryption using customer resources
• Allow encrypted traffic to pass through to customer instances
• Don’t allow AWS to access the decrypted traffic
• Traffic arrives with original encryption at the customer instances
• No AWS-managed inspection of content possible
• AWS services that support customer-managed encryption
• Amazon Network Load Balancer
• Amazon Classic Load Balancer (Layer 4 mode)

AWS Shield Standard & AWS WAF

DDoS protection built into AWS
• Integrated into our global infrastructure
• Redundant Internet connectivity in AWS datacentres
• Fast mitigation without external routing
• Offers always-on protection against common infrastructure attacks
• SYN/ACK floods
• UDP floods
• Reflection attacks
• Provides self-service protection against Layer 7 attacks
• AWS WAF
• Pay-as-you-go model

What does WAF protect against?
DDOS
Targeted
attacks
WAF
Reflection and
amplification
Layer 4 and 7
floods
Slowloris
SSL abuse
HTTP floods
SQL injection
Bots and probes
Application
exploits
Social
engineering
Reverse
engineering

Unique aspects of AWS WAF
• Rich capability around customizable rules
• Offers a Full-feature API
• Designed as a DevOps WAF
• Can be deployed inline with new websites and applications
• Integrated with a range of other AWS services:
• CloudFront, Application Load Balancers, CloudWatch
• Integrated with AWS partners:
• Alert Logic, Trend Micro, Imperva
• AWS offers pay-as-you-go pricing

Attack vectors addressed by AWS WAF
• SQL injection: Attackers insert malicious SQL code into web requests in
an effort to extract data from your database
• Cross-site scripting (XSS): Malicious scripts are injected into otherwise
benign and trusted websites
• Scanners and probes: Malicious sources scan and probe Internet-facing
web applications for vulnerabilities
• Known attacker origins: A number of organizations maintain
reputation lists of IP addresses of known attackers
• Bots and scrapers: Some automated clients misrepresent themselves to
bypass restrictions
• Application-level exploits

AWS WAF components
1. Conditions:
• IP match
• String match
• SQL injection match
• Cross-site scripting match
• Size constraints
2. Rules: Precedence/rule/action
3. Web access control lists (web ACL)
4. AWS resource: CloudFront distribution, Application Load Balancer
5. Reporting: Real-time metrics, sampled web requests

Hands-on (2): Securing the ALB

Hands-on (2): Scenario
• Octank wants to ensure that all traffic arriving at its Application Load
Balancer has come via Amazon CloudFront
• Ensures that any CloudFront Web ACLs are applied
• Reduces load on the backend infrastructure

Hands-on (2): Task
• Configure an AWS WAF Web ACL on the ALB to only accept traffic from
Amazon CloudFront
• Hint: the distribution has been configured to pass a custom header called
“OriginSig” with the value of “reinvent2017” to the origin servers

Lab Checkpoint

AWS Shield Advanced
I n f r a s t r u c t u r e P r o t e c t i o n - N e t w o r k & H o s t - l e v e l b o u n d a r i e s

AWS Shield Advanced
• Advanced DDoS protection support for
• Application and Classic Load Balancers
• Amazon CloudFront, Amazon Route 53
• EC2 instances and Network Load Balancers (new!)
• Additional features include
• Attack notification and reporting
• AWS bill protection
• 24/7 access to the DDoS Emergency Response Team (DRT)
• Engage with DRT reactively for assistance with WAF rules
• Proactive DRT engagement for managed Layer 7 attack mitigation

AWS Shield Standard vs. Advanced
Feature AWS Shield Standard AWS Shield Advanced
Network Flow Monitoring ✔ ✔
Automated Layer 7 Monitoring ✔
Common DDoS Attack protection ✔ ✔
Additional DDoS mitigation capacity ✔
Layer 3/4 attack notifications and reports ✔
Layer 3/4/7 historical reports ✔
DDoS Response team support ✔
Cost protection ✔

AWS IAM policies

AWS IAM policies
• Various supported permission types
• Action-level permissions: controls what actions (API calls) can be
performed for a specific service
• Resource-level permissions: controls which deployed AWS resources are
covered by the policy
• Resourced-based permissions: policy that is attached directly to the
resource, rather than the user or role making the request
• Tag-based permissions: allows policies to reference conditions based on
tags that have been applied to resources
• Service-linked roles: roles created by AWS to support cross-service
automation (e.g. auto-scaling launching EC2 instances)

Networking services AWS IAM support
Service and
Related IAM Info
Supports the following permissions
Action Level Resource Level Resource Based Tag Based Temporary
Credentials
Service-linked
Role
Amazon Virtual
Private Cloud
Yes Yes¹ Yes² Yes Yes No
Amazon
CloudFront
Yes³ No No No Yes No
AWS Direct
Connect
Yes No No No Yes No
Amazon Route 53
Yes Yes No No Yes No

Control access using AWS resource tags
• Use tag-based access control when you need to:
• Treat resources as a unit, such as a project
• Automatically enforce permissions when new resources are created
NOTE: The following services currently support tag-based access control:
Amazon EC2, Amazon VPC, Amazon EBS, Amazon Glacier, Amazon RDS, Amazon Simple Workflow Service,
and AWS Data Pipeline
docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Project" : "Blue"
}
}
}
]
}
Permissions assigned to Rob, granting him permission to
perform any EC2 action on resources tagged with Project=Blue
IAM user: Rob
i-a1234b12
Project=Blue
i-a4321b12
Project=Blue
i-a4321b12
Project=Green
How does tag-based access control work?

Tag-based access control
• Use AWS-managed tags to make immutability easier
• Users cannot directly modify AWS-managed tags, such as
• aws:cloudformation:stack-name
• Aws:autoscaling:groupName
• Policy conditions can reference these tags, to
• only allow specific users, groups and/or roles the ability to modify AWS-
tagged resources

Hands-on Lab (3): Least-privilege IAM

Demo (3): Scenario
• Octank wants to implement separation of responsibilities, such that
• The database team members have the ability to modify the security group
rules within their VPC as required, but not to make changes in other VPCs
• The network team members require that only they have the ability to
modify Network ACLs across the infrastructure
• The CloudFormation template has already created:
• Two roles (DBAdmins & NetworkAdmins)
• Two Managed Policies (DBAdminPolicy & NetworkAdminPolicy) that grant
read-only access to AWS
• Assigned the relevant policies to the roles

Hands-on (3): Task
• Refer to Hands-on Guide 3
• Test that the managed policies perform as expected
• Links to the Switch Role page can be found in the Outputs section of the
CloudFormation stack

Preventative controls recap
• Control the network routing of inbound and outbound traffic
• VPC peering, routing, endpoints
• Security groups, Network ACLs
• Control the encryption and inspection of network traffic
• AWS Certificate Manager, AWS Shield, Load Balancing
• Control administrative access to these AWS services
• AWS IAM, resource tagging

Detective controls

Detective controls
• Monitor what is actually happening within the environment
• Record variations or deviations from the desired state, and/or potential
threats to that desired state
• Provide an audit record for security, performance, availability, or other
reporting requirements

Detective controls in AWS
• AWS CloudTrail
• AWS Config and Config rules
• Amazon CloudWatch Logs and subscriptions
• Amazon CloudWatch metric filters and alarms
• VPC flow logs
• Amazon Inspector

AWS CloudTrail and AWS Config

AWS CloudTrail
• A service that enables governance, compliance, and operational and risk
auditing of your AWS account
• Capture and log events related to API calls and account activity events
across your AWS resources
• Simplify your compliance audit
• Increase visibility into your user and resource activity
• Discover and troubleshoot security and operational issues
Account activity
occurs
CloudTrail captures
and records the
activity as a
CloudTrail event
View and download
your activity in the
CloudTrail Event
History
Define an Amazon
S3 bucket for
storage
Delivery of
CloudTrail Logs

AWS Config
• AWS Config is a continuous recording and assessment service
• Tracks configuration changes to AWS resources
• Verify that resources are configured per security best practices
• Alerts if the configuration is non-compliant with your baseline policies
• Support impact assessment for change requests
Changing
resources
AWS
Config
Config
rules History, snapshot
Notifications
API access
Normalized

AWS Config Rules
• Check configuration changes
• Continuous assessment
• Scheduled reviews
• Pre-built rules provided by AWS
• Custom rules using AWS Lambda
• Custom rules can be used to trigger auto-remediation
• GitHub repo: Community sourced custom rules
• Visualise compliance via a Dashboard
• Compliance results
• Identify offending changes

Example: AWS Config & Config Rules

Amazon CloudWatch Logs

Amazon CloudWatch Logs
• Provides storage, query, and retrieval of text-based (CSV, JSON) log
data across a variety of services
• AWS services, such as AWS Lambda, Amazon API Gateway, VPC Flow
Logs, etc.
• Customer services, such as Syslog, security logs, web logs, etc.
• Data ingest
• Amazon CloudWatch Logs Agent, which can push a range of instance-
based log data from Linux / Windows into Amazon CloudWatch Logs
• API interface, CLI tools, 3rd party integration
• Data retrieval
• Integration with other AWS services such as CloudWatch
• API interface, CLI tools, 3rd party integration

Key concepts
• Log event: an activity recorded by the application or resource being
monitored. It contains a timestamp and raw message data in UTF-8 form
• Log stream: a sequence of log events from the same source
• Log group: a group of log streams that share the same properties,
policies, and access controls
• Metric filter: automatically matches incoming log files to a supplied
pattern and updates a custom metric in Amazon CloudWatch
• Retention period: How long log data is retained before it is purged
• Subscription: allows you to send log data to other services (such as AWS
Lambda, Amazon ElasticSearch) for further processing or analysis

Creating metric filters
• Define a filter pattern
• [field1, field2, field3 = “stringtomatch”, field4 != “valuetoexclude”]
• Provide a name for the filter pattern
• Specify the metric details
• Metric Namespace: collection of metrics, such as “ReInventWorkshop”
• Metric Name: Unique identifier of the metric within the namespace
• Metric Value: value to use as the metric (can be taken from a field)
• Filters only apply to data received after they are created
• Cost considerations
• Custom metrics created by a metric filter costs $0.30 per metric per month
• Alarms that trigger from metrics cost $0.10 per alarm per month

Best practices
• CloudWatch Logs provides a range of benefits
• a useful aggregation point for log data
• The ability to push data into other services
• Integration with 3rd party services
• Some limitations to be aware of
• Metric filters, particularly for plain text log data, don’t support complex
queries
• You can only create one subscription per CloudWatch Logs group

VPC flow logs

What are VPC flow logs?
• Enable you to capture information about the IP traffic going to and
from network interfaces in your VPC
• Can be created for a VPC, subnet, or network interface
• Can create flow logs for other AWS services, such as ELB, RDS, etc.
• Flow log data is stored in Amazon CloudWatch Logs
• Flow log data is published to a log group in CloudWatch Logs
• Each ENI has a unique log stream
• Each record captures the network flow for a specific 5-tuple
• This 5-tuple covers source, destination, and protocol for an IP flow

• version: VPC flow log version
• account-id: AWS account ID
• interface-id: the ID of the ENI for
which the log stream applies
• srcaddr: the source address (private
address for IPv4)
• dstaddr: the dest address (private
address for IPv4)
• srcport: the source port
• dstport: the dest port
• protocol: the IANA protocol number
of the traffic
• packets: number of packets
captured during the capture
window
• bytes: number of bytes transferred
during the capture window
• start: capture window start time (in
Unix time)
• end: capture window end time (in
Unix time)
• action: action associated with the
traffic (ACCEPT or REJECT)
• log-status: logging status of the
flow log (OK, NODATA, SKIPDATA)
VPC flow log format

VPC flow logs limitations
• If traffic is sent to a secondary IP address on an ENI, the flow log
displays the primary IPv4 address in the destination IP address field
• Flow log API actions don’t support resource-level permissions
• Not all traffic is captured:
• Traffic sent to the Amazon DNS Server
• Traffic sent to the Windows Licence Activation server
• Traffic sent to the 169.254.169.254 metadata server
• DHCP request and response traffic
• Traffic to the reserved IP address for the default VPC router

Some uses of VPC flow logs
• Troubleshooting and fault diagnosis
• Diagnose overly restrictive security groups and network ACLs
• Security tool for monitoring the traffic reaching your instances
• Create metrics to identify trends and patterns
• Create alarms in response to specific types of traffic

Hands-on (4): Identifying VPC activity

• Octank wants to identify suspicious traffic that originates from within
its VPCs, and send an alert to the security team
• Suspicious traffic in this context is defined as traffic that is REJECTed due
to security groups or NACLs
• Alerts should be sent for any occurrence of this traffic pattern in a 5-
minute period
• Ideally, Octank would also like to have a visual representation of this
traffic

Hands-on (4): Task
• Identify the data source that can monitor web server network activity
• Create a CloudWatch metrics filter which…
• …counts REJECTed inbound traffic…
• …but only for traffic that originates from one of Acme, Inc.’s VPCs
• Create a CloudWatch alarm
• That triggers when the sum of REJECTed traffic > 0
• Samples in a 5-minute period
• Sends an email notification to the SNS topic created at the start

Serverless analysis of VPC flow logs
VPC Subnet
VPC flow logs VPC flow logsSubscription
AWS
Lambda
Amazon
CloudWatch
Logs
Amazon
Kinesis
Firehose
Amazon
S3
bucket
Amazon
Athena
Amazon
QuickSight
https://aws.amazon.com/blogs/big-data/analyzing-vpc-
flow-logs-with-amazon-kinesis-firehose-amazon-athena-
and-amazon-quicksight/

Lab Checkpoint

Amazon Inspector

Amazon Inspector
• A service that enables governance, compliance, and operational and risk
auditing of your AWS account
• Built from the ground up to support DevSecOps
• Automatable via APIs
• Integrates with CI/CD tools
• Generates findings for a range of rules packages
• Common vulnerabilities and exposures
• CIS operating system security configuration benchmarks
• Security best practices
• Runtime behavior analysis

Detective controls recap
• Monitoring and logging network and application traffic within your VPC
• VPC flow logs, ELB logs
• Amazon CloudWatch Logs
• Amazon Inspector
• Monitoring and logging AWS API calls being made within your account
• AWS CloudTrail
• AWS Config
• Alerting for suspicious/non-standard activity
• Amazon CloudWatch alarms
• AWS Config rules

Automated controls

Automated controls
• Controls that can help restore the environment to the “desired” state
based on information from detective controls
• Designed to respond with no (or limited) human interaction
• Typically provides a “failsafe” capability when preventative controls fail
or are compromised

Automated controls in AWS
• CloudWatch Events
• Custom Config rules
• EC2 Systems Manager

Amazon CloudWatch Events

Amazon CloudWatch Events
• Delivers a near real-time stream of system events that describe changes
in Amazon Web Services (AWS) resources
• Use simple rules to match events and route them to target function(s)
• Schedule automated actions that self-trigger at certain times using cron
or rate expressions
• Common use cases for CloudWatch Events
• Respond to operational changes
• Sending notifications
• Automate corrective actions

Key concepts
• Event: indicates a change in your AWS environment
• Generated from other AWS services
• Generated on a schedule
• Generated from custom application-level events
• Target: processes events
• Example targets include AWS Lambda, Kinesis Streams, Step Functions
• Rule: matches incoming events and routes them to targets for
processing
• Single rule can match to multiple targets
• Rules are processed in parallel

Service events vs. CloudTrail API events
• Many AWS services emit events that can be detected by CloudWatch
Events; examples include
• Auto Scaling (lifecycle action, successful launch)
• Management Console sign-in
• Amazon EBS (snapshot notification, volume notification)
• CloudTrail events are triggered by CloudTrail capturing API calls into AWS
• Can be used for AWS services that don’t natively emit events
• CloudTrail events are not emitted for Get, List, or Describe API calls

Amazon CloudWatch event bus
• Allows the sending of CloudWatch Events to other AWS account(s)
• Allows for centralized CloudWatch Events within/between organizations
• Receiving accounts can receive events from
• Whitelisted AWS accounts, or
• Any AWS account
• Some additional points to consider
• Chained events aren’t supported (e.g. Account A  Account B  Account C)
• The sending account is charged for the event; the receiving account is not
• Rules can be scoped to specific AWS account(s)

Hands-on (5): Automated remediation

• Octank wants to make sure that there is no Internet access available
within the Data VPC
• IAM policies should provide the first defense
• The security team would like to be notified in the event that an Internet
Gateway does get attached
• Bonus: automatically remove the Internet Gateway attachment at the
same time as sending the notification

Hands-on (5): Task
• Create an Amazon CloudWatch event rule:
• Trigger the event when an ec2:AttachInternetGateway API call is made
• Target an SNS topic to notify the security team when this happens
• Test the CloudWatch Events rule
• Navigate to the VPC console, Internet Gateways section
• Attach the unattached IGW to the Data VPC
• You should receive an email notification within 5 minutes
• Bonus: hook up the Workshop custom Lambda function as a second
trigger to CloudWatch Events, to detach the IGW automatically

Lab Checkpoint

Amazon EC2 Systems Manager
I n f r a s t r u c t u r e P r o t e c t i o n - S y s t e m s e c u r i t y c o n f i g u r a t i o n

• Easily configure and manage Amazon EC2 and on-premises systems
• Easy-to-use automation
• Improve visibility and control
• Maintain software compliance
• Reduce costs
• Secure role-based management
• Supports a range of operating systems
• Microsoft Windows: Server 2003+
• Linux: Amazon Linux, RHEL, SUSE, Ubuntu

• Seven key components
• Run Command
• State Manager
• Inventory
• Maintenance Window
• Patch Manager
• Automation
• Parameter Store

Common use cases
• Maintain a consistent configuration across your fleets
• You can use State Manager to specify and automatically maintain the
desired configuration of your instances and software
• Perform deep security and incident analysis
• Inventory integrates with AWS Config to provide a historical record of
inventory changes over time.
• Easily manage OS and application configuration
• Run Command allows you to perform operating system changes and
provides support for all PowerShell and Linux commands
• Control access to sensitive information
• Control access to specific parameters such as passwords, as well as who
can perform what set of operations on those parameters
• s

EC2 Systems Manager in action
• The CloudFormation script also deployed some EC2 Systems Manager
components and dependencies
• EC2 Instance Role: to give permissions for the instances to access the EC2
Systems Manager service
• State Manager Association: to collect inventory data every 24 hours from
the fleet of EC2 instances
• State Manager Association: to install Amazon Inspector onto all instances
• Parameter Store String: will be used to store an SSH public key
• Custom Command Document: to push an SSH key pair stored in
Parameter store onto the EC2 managed instances

Hands-on (6): Updating SSH key pairs

• Octank wants to perform routine security maintenance across its fleet of
web servers
• Update the “ec2-user” SSH public key
• Don’t want to have to log into each instance individually
• Bonus: Octank would like to automate the entire process so that the
fleet is updated whenever the SSH key is changed in Parameter Store

Hands-on (6): Demo
• Configure Parameter Store:
• Update the parameter/workshop/sshpublickey with a new SSH public key
• Push the key to all web servers using Run Command
• Use the Workshop command document to push the key to the web servers
• Specify the key by referencing it from the Parameter Store
{{ssm:/workshop/sshpublickey}}
• Test that the key has been updated on an instance
• Use Run Command to cat the /home/ec2-user/.ssh/authorized_keys
• Make sure it matches your SSH public key used above
• Trigger the Run Command from a CloudWatch event emitted from a
Parameter Store update event.

Lab Checkpoint

Automated controls recap
• Respond automatically to changes in your environment
• AWS Custom Config rules
• Amazon CloudWatch Events
• Fleet management automation at scale
• Amazon EC2 Systems Manager

Summary

What we’ve covered today
• Whistle-stop tour of Amazon VPC best practices
• Looked at a range of preventative controls
• Deployed AWS WAF at a regional/global level
• Created a least-privilege IAM managed policy
• Considered how to make use of detective controls
• VPC flow logs monitoring and notifications
• Config Rule to look for blacklisted software packages
• Explored the benefits of automated controls
• Amazon CloudWatch Events triggering AWS Lambda functions
• Amazon EC2 Systems Manager for managing fleets at scale

General best practices
• Design
• Remember to make use of less-obvious controls, such as outbound
security groups, specific routing, AWS managed services
• Automate
• Using tools such as CloudFormation can help reduce human errors
• Monitor
• Establish known-good baselines and look for deviations
• Use tools such as AWS Config and CloudWatch Events to make this easier

Finally…
• Don’t forget to delete the CloudFormation stack and any resources you
have created today
• Complete the evaluation form (NET309) so we can improve this
workshop next year
• Enjoy what’s left of the event!

N E T 3 0 9 — B e s t P r a c t i c e s f o r S e c u r i n g A m a z o n V P C
Thank you!

NET309_Best Practices for Securing an Amazon Virtual Private Cloud

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie NET309_Best Practices for Securing an Amazon Virtual Private Cloud

Ähnlich wie NET309_Best Practices for Securing an Amazon Virtual Private Cloud (20)

Mehr von Amazon Web Services

Mehr von Amazon Web Services (20)

NET309_Best Practices for Securing an Amazon Virtual Private Cloud