SR-IOV aka Amazon’s Enhanced Networking

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

  1. Create your AMI with latest version of Ubuntu 14.04 . Trusty
  2. Create an AMI with HVM Enabled and register with the sr-iov flag enabled
  3. Launch your AMI in the VPC

Different Uses-Cases

  • One of the First use case i can think of are the NAT’s. Which  handles most of your outbound traffic.

Testing SR-IOV

  • Securitymonkey with Docker

    Installing security monkey using Docker using just 2 commands

    1. Launch EC2 instance ( Amazon Linux )
    2. Install Docker
      • sudo yum install -y docker
      • sudo service docker start
    3. Download securitymonkey repo from docker
      • sudo docker pull nagwww/securitymonkey
    4. Launch Security Monkey with Docker as
      • sudo docker run -e “mail=nagwww@gmail.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
    5. Access security monkey as
    6. https://ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com/#

     Notes :

    1. Security monkey runs in a container on the EC2 instance
    2. 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’)
    3. There is no ssh to the security monkey container.
    4. Dockerfile to build the image is available @ https://github.com/nagwww/docker_securitymonkey/blob/master/Dockerfile
    5. Docker repo for security monkey is available at https://registry.hub.docker.com/u/nagwww/securitymonkey/tags/manage/

     Thanks Mittu ( @kssmitra ) for the kickoff….

     

    AWS Security : 25 TIPS for securing AWS

    25 tips for securing Amazon web services.

    It is all about doing the small things right.

    Tip # 11 - Know your boto
    Tip # 17 - AWS VPC
    Tip # 20 - Cloud HSM

    AWS Security : Prepare for the worst, have a Risk assessment plan and Incident response ( Tip # 24 )

    TIP # 24 Prepare for the worst, have a Risk assessment plan and Incident response

    Risk Assessment

    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

    https://d36cz9buwru1tt.cloudfront.net/AWSRiskandComplianceWhitepaperJanuary2012.pdf

    Risk Mitigation

    After your perform your Risk assessment, the controls you have to mitigate that risk is Risk mitigation.

    Example,

    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 ,

    {
     "Statement": [
     {
        "Sid": "Stmt1351207632445",
             "Action": [
                "ec2:*",
               ],
             "Effect": "Allow",
             "Resource": [
                "*"
              ],
           "Condition": {
              "IpAddress": {
               "aws:SourceIp": "172.2.237.0/25"
              }
         }
     }
     ]
    }

    -

    Incident response

    • 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

     

    AWS Security : Know how to perform Forensics ( Tip # 23 )

    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.
      • ec2cim i-33ee33 -n forensics-1.0 -d "AMI of the hacked instance {Datetime}" -b "/dev/sdb=ephemeral0"
    • 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