How to restrict users from Launching an RDS Instance of a particular type
Attach a Policy with the following IAM Policy
SR-IOV stands for Single Root I/O Virtualization.
In layman terms,
- Removes CPU from the process of moving data to and from a VM.
- Packets from your AWS EC2 Instance goes directly to the Network by passing the hypervisor thus providing
- Lower latency
- Higher performance
- More info,
Pre-reqs for launching an instance with SR-IOV on AWS
- Create your AMI with latest version of Ubuntu 14.04 . Trusty
- Create an AMI with HVM Enabled and register with the sr-iov flag enabled
- Launch your AMI in the VPC
- One of the First use case i can think of are the NAT’s. Which handles most of your outbound traffic.
Installing security monkey using Docker using just 2 commands
- Launch EC2 instance ( Amazon Linux )
- Install Docker
- sudo yum install -y docker
- sudo service docker start
- Download securitymonkey repo from docker
- sudo docker pull nagwww/securitymonkey
- Launch Security Monkey with Docker as
- sudo docker run -e “firstname.lastname@example.org” -e “host=ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com” -i -t -p 443:443 -p 5000:5000 “nagwww/securitymonkey:v1″ /home/ubuntu/securitymonkey.sh
- Access security monkey as
- Security monkey runs in a container on the EC2 instance
- You will have to enable port forwarding to 443 and 5000. So the security groups need to be opened to 443 and 5000 ( To do this use the option “-p” with ‘docker -run’)
- There is no ssh to the security monkey container.
- Dockerfile to build the image is available @ https://github.com/nagwww/docker_securitymonkey/blob/master/Dockerfile
- Docker repo for security monkey is available at https://registry.hub.docker.com/u/nagwww/securitymonkey/tags/manage/
Thanks Mittu ( ) for the kickoff….
25 tips for securing Amazon web services.
It is all about doing the small things right.
Here are some of the blogs and twitter feeds i follow
- Twitter list
- Netflix OSS meetup
- AWS San Francisco
TIP # 24 Prepare for the worst, have a Risk assessment plan and Incident response
AWS is not going to take responsibility for information lost to a compromised account it is the responsibility of the customer and not AWS. However AWS takes other initiates to secure the cloud.
Here is a good white paper from AWS which should cover most part of it
After your perform your Risk assessment, the controls you have to mitigate that risk is Risk mitigation.
Risk : Concerned with AWS keys getting lost and the risk is business continuity
Mitigation : Monitor for the keys in github in addition add a source IP restricting condition to the IP as ,
- In the event of an issue how do you respond.
- Example say your AWS keys are exposed in github,
- Invalidate the current key
- Re-generate new AWS keys
- Check in cloudtrail logs if there are any incoming requests using this key
- Confirm if there are any new IAM users/kyes created.
- What actions were performed with this AWS key in the last 6 months or since it was exposed
TIP : AWS Forensics
If you suspect if your EC2 instances were hacked and want to do some forensics here is what i would do,
Step 1 : Create an AMI of the instance you are performing Forensics on,
- First identify the EC2 instance ID ( say the id is i-33ee33
- Create an image of the EC2 instance. You do not have to login to create an image.
- Launch an EC2 instance with the newly created AMI
- Attach a security group with no outgoing requests
Step 2 : Check your cloudtrail logs
- Check all the cloudtrail activity for this instance
Step 3 : Cloudpassage security events
- Check the cloudpassage security events history