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 “email@example.com” -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
TIP : Audit your AWS Accounts.
AWS has an excellent auditing checklist which you can use to perform an Audit. The Audit check list can be accessed
You should consider performing an audit periodically using some sort of tool…