Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.
Welcome!DoiT InternationalPracticing multi-cloud & cloud cyber security since 2010.
DoIT International confidential │ Do not distribute
DoIT International confidential │ Do not distribute
DoIT International confidential │ Do not distribute
● Customer Operations Engineer
● Big Data Engineering
● Cloud Sales Rep.
Looking for Talent
Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.
AWS Cyber Security Best PracticesShay Kirshenboim - Cloud Cyber Security // DoiT International
Agenda
1
2
3
4
5
AWS Security Components
MFA Authentication
Logging, Audit and Monitoring tools
AWS Shield & WAF
Centralize logs using AWS Elastic6
AWS Monitoring and Security Controls
& Trusted Advisor
ElasticSearch Service
AWS Shared Security Model
AWS Security Groups and Network ACLs
Security Groups
Affects Instances (1st protection layer)
Only "Allow" rules & by default "Deny"
Stateful (Return traffic is allowed)Rules order is insignificant as all
rules are “allow” rulesMany to many relationship
10
Network ACL’s
Affects an entire subnet (2nd protection layer)
Support “Allow” & “Deny” rulesStateless (You must explicitly allow
return trafficEvaluates rules in number order (like
traditional firewall)
Security Groups & Network ACL’s
Security Groups
Avoid using the “default VPC security group” which enables inbound communication from all members of the SG and outbound communication to any destination
Delete “any to any” rules and configure specific name servers and other services rules as needed
Use easy to understand names (and naming convention)Create functional related SG (db servers, web server etc.)Create default SG for Infra services (Windows RDP or Linux ssh etc.)Try to balance simplicity of SG and amount of SG per instance to achieve
simple management.Enable VPC flow logs
Security Groups & NACL’s - Best Practices
Monitor changes to SG (Demo)
Identify your critical SGs (sg-8f9ee8f7)Create Lambda execution role and policyCreate Lambda function:
review Code, configure role and handler
"detail-type": [ "AWS API Call via CloudTrail" ], "detail": { "eventSource": [ "ec2.amazonaws.com" ], "eventName": [ "AuthorizeSecurityGroupIngress", "RevokeSecurityGroupIngress" ], "requestParameters": { "groupId": [ "<YourSGid>"
● Configure CloudWatch rule to catch API callsthat may cause SG changes
● Modify SG and look for CloudWatchphrases : ‘This permission must be authorized’ ‘This permission must be revoked’
Auto Update SG using SNS & Lambda
Use case: Update Web servers SG with AWS CloudFront IP ranges
Target SGs tagged with “Name:cloudfront” and “AutoUpdate:true”
IAM policy and role (as in previous example)
Create Lambda function using code
Configure Lambda function's trigger by SNS subscriptionaws sns subscribe --topic-arn arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged --protocol
lambda --notification-endpoint <Lambda ARN>
Run test Check Security Group Inbound rules⇒
Alert on IAM policy change
The process:
Logs mark “DefaultLogGroup” create metric filter:⇒ ⇒ { ( ($.eventSource = "iam.amazonaws.com") && (($.eventName = "Add*") || ($.eventName = "Attach*") || ($.eventName = "Change*") || ($.eventName = "Create*") || ($.eventName = "Deactivate*") || ($.eventName = "Delete*") || ($.eventName = "Detach*") || ($.eventName = "Enable*") || ($.eventName = "Put*") || ($.eventName = "Remove*") || ($.eventName = "Set*") || ($.eventName = "Update*") || ($.eventName = "Upload*")) ) }
Same can be done for SG, S3 bucket policy etc.Examples
Attach IAM Role to an Existing EC2
New! (Feb 2017) Attach the IAM role to an existing EC2 instance that was
originally launched without an IAM role / Replace the attached IAM roleCreate an instance profileaws iam create-instance-profile
Add a role to an instance profileaws iam add-role-to-instance-profile
List instance profilesaws iam list-instance-profiles aws iam list-instance-profiles-for-role
Remove a role from an instance profileaws iam remove-role-from-instance-profile
Delete an instance profileaws iam delete-instance-profile
Bastion Host and MFA
Securing (at least) your Bastion Host with MFA
1. Install and launch Google Authenticatorsudo yum install google-authenticator –y ⇒ google-authenticator
2. Configure the sshd PAM module to use Google Authenticator: vi /etc/pam.d/sshd
Add: auth required pam_google_authenticator.so
Comment out: auth substack password-auth
3. Configuring SSH so that Google Authenticator is called as a second factor of authentication vi /etc/ssh/sshd_config
change: “ChallengeResponseAuthentication” option to “yes”
add: to the bottom of the file: “AuthenticationMethods publickey,keyboard-interactive”
4. Restart SSH daemonsudo /etc/init.d/sshd restart
Enable MFA Protection on Your AWS API
1. Author an IAM policy to grant “Allow” access for MFA-authenticated users1. Using aws:MultiFactorAuthPresent
"Sid": "AllowActionsForEC2WhenMFAIsPresent", "Effect":"Allow", "Action":"ec2:RunInstances", "Condition":{
"Bool":{"aws:MultiFactorAuthPresent":"true"}
2. <Demo> Preventing AWS API calls from left open consoles1. Using aws:MultiFactorAuthAge and Conditions
Long-term credentials (IAM user access keys) cannot be used with MFA-protected API access because they don't expire (AWS CLI) !
Enable MFA Protection on Your AWS CLI
1. Using temporary session token $ aws sts get-session-token --serial-number arn:aws:iam::AWS-account-number:mfa/user --token-
code code-from-token (Optional: --profile user)
2. Edit the AWS CLI credentials file, which defaults to ~/.aws/credentials with returned values:[profile-name]aws_access_key_id = <Access-key-as-in-returned-output>aws_secret_access_key = <Secret-access-key-as-in-returned-output>aws_session_token = <Session-Token-as-in-returned-output>
3. <Demo> ec2 describe-instances only to MFA enabled users using “AWS CLI"
4. Check out AWS Security Blog for very useful guides (an excellent example: How to Record SSH Sessions Established Through a Bastion Host)
Inspector / Trusted Advisor (Business Support)
AWS Trusted Advisor Security Checks
● Upgrading your Support plan will enable many more security best practices checks
AWS Inspector
Prerequisites: Create Role Tag EC2 instances ⇒ ⇒Install AWS agent:
curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
sudo bash install
sudo /opt/aws/awsagent/bin/awsagent status
Auto install Agent when launching new instance
Advanced Details User Data⇒#!/bin/bash
cd /tmp
curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
chmod +x install
./install
AWS Inspector Findings (examples)Security Best Practices-1.0:Finding Instance xxxx is configured to allow users to log in with root credentials over SSH. This increases the likelihood of a successful brute-force attack.Description This rule helps determine whether the SSH daemon is configured to permit logging in to your EC2 instance as root.Recommendation It is recommended that you configure your EC2 instance to prevent root logins over SSH. Instead, log in as a non-root user and use sudo to escalate privileges when necessary. To disable SSH root logins, set PermitRootLogin to "no" in /etc/ssh/sshd_config and restart sshd
AWSLabs GitHub links: https://github.com/awslabs/amazon-inspector-agent-autodeploy Lambda job in Python to automatically deploy Inspector agent to newly-launched EC2 instances.
https://github.com/awslabs/amazon-inspector-finding-forwarder
Lambda script that receives findings from the Amazon Inspector service in AWS, via SNS, and forwards them to a destination email address.https://github.com/awslabs/aws-security-benchmarkCollection of resources related to security benchmark currently: CIS AWS Foundations Benchmark 1.1
How to Remediate Amazon Inspector Security Findings Automatically
AWS Shield & WAF
AWS Shield
Rules
AND / ORAllow, Block or
CountOrdered
conditions
AWS WAFWeb ACLs contain rules
Rule#1: Block Bad User-AgentsIP matchSuspicious IPs
&String match
Bad botsORRule#2: Block SQLiSQLi match
SQLi checks
ELSEDefault Action: Allow
Conditions
IP matchSuspicious IPs192.0.2.0/24
StringUser-Agent header matches Bad bots
SQL injectionURI contains SQL injection
Recommended Order
1. WhiteListed iPs- Allow
2. BlackListed IPs- Block
3. BlackListedSignatures- Block
4. SQLInjection- Block
5. SuspiciousActivity- Count
Default: Allow
AWS WAF Security Automationshttp://docs.aws.amazon.com/solutions/latest/aws-waf-security-automations/deployment.html
Lambda Functions:Log Parser:
parses CloudFront access logs to identify suspicious behavior, such as an abnormal amount of requests or errors. It then blocks those IP addresses for a customer-defined period of time. Default Parameters: RequestThreshold:400, ErrorThreshold:50, WAFBlockPeriod:240(min)
IP Lists Parser:checks third-party IP reputation lists hourly for new IP ranges to block. These lists include the Spamhaus Don't Route Or Peer (DROP) and Extended Drop (EDROP) lists, the Proofpoint Emerging Threats IP list, and the Tor exit node list.
BadBot Parser:intercepts and inspects trap endpoint requests to extract its IP address, and then add it to an AWS WAF block list.
AWS ElasticSearch
Forensics on logs with AWS ElasticSearch (or your own)
Create your Elasticsearch domain
Stream all relevant logs (CloudWatch)
Create Dashboards by topic
Monitor and Investigate
Section Slide Template Option 2
Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.
Questions?
Put your subtitle here. Feel free to pick from the handful of pretty Google colors available to you.Make the subtitle something clever. People will think it’s neat.
Thank You!DoiT International
Practicing multi-cloud & cloud cyber security since 2010.
Top Related