IAM Policy : How to restrict users from Launching an RDS Instance of a particular type

How to restrict users from Launching an RDS Instance of a particular type

Attach a Policy with the following IAM Policy

 "Version": "2012-10-17",
     "Statement": [
         "Effect": "Allow",
         "Action": "rds:CreateDBInstance",
         "Resource": "*",
         "Condition": {
             "StringNotEquals": {
                "rds:DatabaseEngine": [

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 # 15 – Know your S3 buckets
    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


    Risk Mitigation

    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 ,

     "Statement": [
        "Sid": "Stmt1351207632445",
             "Action": [
             "Effect": "Allow",
             "Resource": [
           "Condition": {
              "IpAddress": {
               "aws:SourceIp": ""

    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