Transcript In Amazon Web Services Understanding Perimeter

Understanding
Perimeter Security
In Amazon Web Services
Aaron C. Newman
Founder, CloudCheckr
[email protected]
Changing Your Perspective
• How do I securing my business applications in AWS?
• Moving to the cloud =
• Rethinking your perimeter security
• Rethinking how you perform most security tasks:
• Network-based IPS/IDS
• Network scanning
• Penetration tests
• Vulnerability assessments
In the Data Center
• Setting Up Perimeter Security:
• Setting up your infrastructure
• Setting up access points to the internet
• Configuring firewall, IDS, IPS, etc.. at the access points
• Auditing Your Perimeter Security:
•
•
•
•
•
•
Gather set of IP Address blocks to poke at
Do a port scan (using tools such as Nmap)
Determine which ports are open on the target
Try various exploits on the open ports.
Sniff lots of packets
Dig around to make sure no back doors into the network
• Wireless access points, secondary T1 lines, DSL connections
• VPN access from some other network
AWS: What’s Different?
• Physical assets secured at the
• AWS availability zone
• But we still need to guarding the AWS API
• IAM Access is your new physical security
The idea of physical security morphs as
infrastructure becomes virtualized by AWS APIs.
In a new world of ephemeral, auto-scaling infrastructure,
you need to adapt your security architecture to meet
both compliance and security threats.
Minimizing Attack Vectors
• Principles don’t change
•
•
Reduce your surface area!
Defense-in-depth
• Some attack vectors don’t change
•
•
•
Application level (user-privilege escalation, web app vulns, XSS)
Operating system vulnerabilities
Database vulnerabilities
• Some attack vectors change
•
•
•
Homogeneous environment
Polymorphic targets/mapping
Reduced network sniffing
Perimeter Assessments In the Cloud
• How do I assess the perimeter of my cloud?
• Old world – nmap, port scans, ping sweeps, etc…
•
Give me your network block
• New world – let me see your configuration
•
•
•
•
•
•
List of publicly-accessible resources
Security groups (EC2-Classic, EC2-VPC, Redshift, RDS, etc…)
Routing tables, Network ACL
VPC, subnets
S3 buckets and permissions
IAM policies
Rules For Running Pen Tests on AWS
http://aws.amazon.com/security/penetration-testing/
• “complete and submit the AWS Vulnerability / Penetration Testing Request
Form to request authorization for penetration testing or scanning of your
resources”
•
Caveats
At this time, our policy does not permit testing m1.small or t1.micro instance types. This is to
prevent potential adverse performance impacts on the resources you may be sharing with
other customers in a multi-tenant environment.
•
Demo
https://portal.aws.amazon.com/gp/aws/html-formscontroller/contactus/AWSSecurityPenTestRequest
•
Need to know
– IP Addresses to be scanned (Destination)
– Instances IDs
– Scanning IP addresses (Source)
What are we missing?
• This assumes our only threat is EC2
• AWS is a complex system w/ many, many moving parts
• Over 30 different AWS services
• Many have unique access control systems
• Some companies have 100s of AWS accounts
• We need a complete inventory
• all publicly-accessible endpoints and resources
Hackers find the single weak link
EC2-Classic
• EC2-Classic only available in old accounts
• Prevalent for early adopters
• Pre-VPC era
• Each EC2 instance has
• A public IP address and a public DNS name
• A private IP address and a private DNS name
• Can have an Elastic IP Addresses
• Only security is EC2-Classic security groups
• Treat each as a target with its own security risk
EC2-VPC
• Default VPC is created in every region
• VPCs are wide open by default
• VPC is composed of:
•
•
•
•
•
•
Internet and VPN gateways – connect to the rest of the world
1+ subnet(s)
Routing table – how to move traffic around the VPC
Network ACLs – a firewall but stateless
Security groups – host-based firewall stateful
Resources – EC2, RDS, Redshift, ElastiCache
S3 (Simple Storage Service)
•
Up to 100 buckets in an account
•
•
Location
•
•
•
Unlimited number of objects (billions is not uncommon)
Within a region, across multi-AZs, not housed in a VPC
Can’t sit between client and storage
Security
•
•
•
Access control thru IAM policies, bucket policies, ACLs, and query string authentication
Server-side Encryption, HTTPS support
Server-access logs (does not integrate with CloudTrail)
•
Don’t grant FULL_CONTROL, WRITE_ACP, WRITE bucket permissions
to Everyone EVER!!!
•
Inventory your sensitive data
RDS (Relational Database Service)
• Location
• Within a VPC or not, multi-AZ or not
• Security Options
• DB Security Groups (if not in a VPC) or EC2-VPC Security Groups
• Select a non-default database port
• Publicly Accessible option
• Not a good idea, but if you do this
• Make sure you use security groups to restrict source IP address
• Make sure you have latest patches applied
• Secure you database snapshots
• Keys to the kingdom if someone can get a copy
• Brute-force passwords, restore to their own account
SQS (Simple Queuing Service)
• Where does SQS live?
• Within a region, not within a VPC
• Uses a URL such as
• https://sqs.us-east-1.amazonaws.com/123456789012/MySQS
• Security based on policy documents:
{
"Version": "2008-10-17",
"Id": "arn:aws:sqs:us-east-1:123456789012:MySQS/SQSDefaultPolicy",
"Statement": [
{
"Sid": "Sid1415217272568",
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": [
"SQS:ReceiveMessage", "SQS:SendMessage"
],
"Resource": "arn:aws:sqs:us-east-1:123456789012:MySQS"
},
SNS (Simple Notification Service)
• SNS does not live inside your VPC
• Permissions based on topic policies:
Using CloudTrail
• An AWS Service that records each time the AWS API is called
• Currently supports 20+ AWS services
•
http://docs.aws.amazon.com/awscloudtrail/latest/userguide/dochistory.html
• Conveniently everything in AWS goes through the API
• Even actions in the Management Console go through the API
• CloudTrail writes files into an S3 bucket
• Near real-time (every five minutes)
• Files are in JSON format
Get started at http://aws.amazon.com/cloudtrail/
Internal vs. External threats
• Understanding who the threat is
• Internal threats
• Disgruntled or malicious DevOps
• E.g. Edward Snowden
• External threats
• Hacker groups, script kiddies
• E.g. Anonymous
Each requires different controls and monitoring
Tools For Securing AWS
• Generic tools fall short
• Purpose-built, not cloud-washed
• Make sure tools don’t fall over in the cloud
• Tools have to understand dynamic, ephemeral IPs
• Need a deep understanding of AWS
• What does this means
• Context is important
• Actionable intelligence
Questions?
Questions on:
• AWS Security
• CloudCheckr
Thank You for Attending
Sign up today for free evaluation
at http://cloudcheckr.com
Aaron Newman is the Founder
of CloudCheckr (www.cloudcheckr.com)
Please contact me with additional questions at:
[email protected]