Elastic Security

Icon

Security for the Cloud

December 15, 2011 • 18:24 0

AWS South America support in CloudyScripts

Yesterday, Amazon announced that they have deployed a new region in South America (to Sao Paulo, Brazil) on its blog (the full article could be found here)

Even if Amazon documentation did not contain all the required information (such as the Amazon Kernel Image IDs), we were able to retrieve them, thus allowing to fully support this New Region in CloudyScripts.

CloudyScripts gem

A new version has been released with all the AKIs mapping table up to date for this new region.
We managed to retrieve the AKIs list using AWS EC2 API Tools as follow:

[fred@secludit-debian]# /bin/ec2-describe-images -K pkey-XXX.pem -C cert-XXX.pem --region sa-east-1 -a | grep pv-grub | awk '{print $2" "$3" "$7}'
aki-863ce39b ec2-public-images-sa-east-1/pv-grub-hd0-V1.01-i386.gz.manifest.xml i386
aki-d63ce3cb ec2-public-images-sa-east-1/pv-grub-hd0-V1.01-x86_64.gz.manifest.xml x86_64
aki-803ce39d ec2-public-images-sa-east-1/pv-grub-hd00-V1.01-i386.gz.manifest.xml i386
aki-d03ce3cd ec2-public-images-sa-east-1/pv-grub-hd00-V1.01-x86_64.gz.manifest.xml x86_64
aki-823ce39f ec2-public-images-sa-east-1/pv-grub-hd00_1.02-i386.gz.manifest.xml i386
aki-d23ce3cf ec2-public-images-sa-east-1/pv-grub-hd00_1.02-x86_64.gz.manifest.xml x86_64
aki-bc3ce3a1 ec2-public-images-sa-east-1/pv-grub-hd0_1.02-i386.gz.manifest.xml i386
aki-cc3ce3d1 ec2-public-images-sa-east-1/pv-grub-hd0_1.02-x86_64.gz.manifest.xml x86_64

CloudyScripts WebSite

Our free of use online service has been updated as well to support this new region in each of its scripts.

As requested by users of CloudyScripts, we also have added support for auditing VPC SecurityGroups.

  • VPC Critical Ports Audit: This script scrutinizes for VPC SecurityGroups of your infrastructure if the SecurityGroups configuration allows public access to ports that are considered such sensitive that accessibility may cause critical damage to your machines – such as ports for administrating machines

/fred

Filed under: AWS, Cloud Computing, , , , , ,

November 17, 2011 • 19:08 0

Amazon US West Oregon Region Support in CloudyScripts

A few days ago Amazon announced that a new AWS Region in Oregon is supported (see AWS blogpost for more information).

Amazon’s documentation for PVGRUB AKI IDs (which can be found here) was not updated at the same time, that’s why fully supporting the NEW US-West Oregon region in CloudyScripts took some additional days (especially for Copy AMI To Different Region scripts).

NB: The importance of being able to map PVGRUB AKIs between different Amazon Regions has been explained in a previous post How-To: Copy an EBS-Backed AMI from one region to another one

CloudyScripts Ruby gem

SecludIT has released a new version of the Ruby library containing the last update on RUBYForge. The gem is also available on RubgyGems.org.

CloudyScripts WebSite

SecludIT has now added support for NEW US West Region in CloudyScripts.

As a reminder, here is some information on one of our most used scripts (more than 5 thousands executions until now):

  • Copy Ami to Different Region: Creates a copy of a given AMI and make it available in another region. Therefore, instances are created in both regions that perform copying (via rsync) of all files from a volume in the original region based on a snapshot created for the original AMI to a clean volume in the target region. After successful copying, a snapshot is performed in the target region and registered as AMI.

CloudyScripts DevPay AMI

SecludIT DevPay AMI has not been yet updated, but it should be available soon. This AMI runs in your own Amazon EC2 infrastructure and is available from our CloudyScripts WebSite.

As usual, any feedback is greatly appreciated, so do not hesitate to contact us or leave a comment.

/fred

Filed under: AWS, Cloud Computing, , , , , ,

July 8, 2011 • 12:05 0

CloudyScripts: Ruby code for command line Security Audit via SSH

As requested by our users, we have just added a sample code for creating ruby script on top of cloudyscripts gems that can be found on RubyGems or on RubyForge.

The first script allows to run a Security Audit via SSH using a command line. In addition, we extended the scope of usage: the Security Audit can be run against a running instance (in addition to AMIs), thus allowing:

  • to test running instances, therefore no need to wait for a new instance to start
  • to make a Security Audit of a production server with full control of the Security Audit process

For any information on how to retrieve the source code of this openSource project that is published under Apache v2.0 Licence, please go to cloudyscripts SCM on RubyForge

We would like to thank Jonas Zaddach (Master Computer Science Student at Eurecom) who wrote the “Security Audit via SSH” part of the cloudyscripts library during his internship at SecludIT.

/fred

Filed under: AWS, Cloud Computing, Secure Cloud, , , , , , , , , ,

July 8, 2011 • 12:04 0

New CloudyScript: Security Audit via SSH

We are glad to announce a new CloudyScript Security Audit via SSH which makes a Security Audit of an Amazon EC2 AMI. It requires a privileged user that can perform sudo.

Security Auditing is very important in cloud computing infrastructures where virtual machine images (AMI in the case of Amazon) could be shared among users. In order to avoid backdoors or vulnerable machines in your own Amazon EC2 infrastructure, you MUST evaluate the public AMI you are using. Security Audit via SSH CloudyScripts automates that task.

Here is a sample output of an SSH Audit:

Moreover, we designed it as a library of security audits, that for now contains audits for SSH and Apache2 servers, but we will continue to extend it with other security audits

/fred

NB: This Security Audit does not check your IP restrictions for accessing the SSH server. In order to check that your SSH server is not publicly exposed you could use Public Port Checker CloudyScript.

Filed under: AWS, Cloud Computing, Secure Cloud, , , , , , , , ,

April 19, 2011 • 21:48 0

Amazon Security Groups: VPC vs EC2

Amazon has updated Security Groups for Amazon VPC

Earlier  in April, while adding support for Security Groups within Amazon VPC, Amazon also introduced some major changes such as:

  • outbound filtering
  • fine grained IP protocol tuning
  • ability to apply changes in a one fell swoop

But I found very interesting the fact that we can now change (add/remove) the Security Groups for a running instance. As a customer of AWS, I really love to be able to modify my Security Groups without stopping any instance. I could now start an instance without a deep analysis of what my VPC network will be, and I can adapt it at any time with a minimal impact on the availability of the services my customers are consuming. In my point of view this is a major achievement, because I can adapt my security perimeter on the fly.

I still have some open questions:

In terms of security, I ‘m wondering if the opened/established connection are dropped if I modify my Security Group rule or if I remove it?

Moreover, AWS added NACL (Network Access Control List), which allow now to create DENY firewalling rule. But this seems requiring an internet gateway (VPC specific). This sounds like Amazon was not able to add ACCEPT/DENY options to the Security Group rules even if they added Inbound/Outbound options.

Here is AWS blog-post for more information:  A New Approach to Amazon EC2 Networking

Amazon EC2: public cloud

Unfortunately, I’m not a VPC user, but a EC2 user and it’s a bit frustrating that these brand new features are not available in outside VPC. I’m wondering, if there are any reason why not adding these features to Amazon EC2.

Concerning the Outbound filtering, I can’t see any reason why not adding it for EC2. I would love to hear more about this.

Last, but not least thing that can be discussed is the “one fell swoop” feature. I think this is a step back to true elasticity. Previously, I just had to create a rule and then the rule is automatically and dynamically applied, now I have to build the rule and then apply it just like with a traditional firewall.

/fred

Filed under: AWS, Cloud Computing, , , , , , ,

March 9, 2011 • 16:49 0

CloudyScripts Supports New Amazon EC2 Region: Asia Pacific (Tokyo)

Amazon announces that a new AWS Region in Tokyo is supported (see AWS blogpost for more information).

CloudyScripts WebSite

CloudyScripts has been updated in order to support this new AWS Region.

This AWS Region is available in all the following CloudyScripts:

  • Convert Instance-store AMI To EBS-booted AMI: Takes an instance-store AMI, instantiates it, copies the boot-data to a temporary EBS volume, takes a snapshot of this EBS volume and registers the snapshot as EBS-booted AMI. As a result, the new AMI behaves exactly as the original AMI, but boots from an EBS volume.
  • Copy Ami to Different Region: Creates a copy of a given AMI and make it available in another region. Therefore, instances are created in both regions that perform copying (via rsync) of all files from a volume in the original region based on a snapshot created for the original AMI to a clean volume in the target region. After successful copying, a snapshot is performed in the target region and registered as AMI.
  • Download a Snapshot: Allows to download a snapshot as zip-file. Therefore, the script starts up an instance with a web-server, creates and attaches an EBS volume from the specified snapshot, zips the snapshot data, and makes it available as download link for 5 minutes.
  • Copy Snapshot To Different Region: Creates a copy of a given snapshot and make it available in another region. Therefore, instances are created in both regions that perform copying (via rsync) of all files from a volume in the original region based on the specified snapshot to a clean volume in the target region. After successful copying, a snapshot is performed in the target region.
  • Encrypt Storage Using dm-crypt: Allows you to encrypt an EBS storage using the dmcrypt tool. The script transforms an EBS volume (which must already be attached to an instance) into a dm-encrypted volume, creates a file-system (ext3), and mounts it to the specified path.

CloudyScripts Community AMI

The CloudyScripts Community AMI has also been updated in order to support this new AWS Region. This AMI can be found in EU East (Northern Virginia) Region with the current AMI ID ami-f291639b.

Any feedback is greatly appreciated, so do not hesitate to contact us.

/fred

Filed under: AWS, Cloud Computing, , , , ,

February 18, 2011 • 19:04 1

Amazon EC2 ‘broad character’ support and Security impact on third party tools such as Elastic Detector

The goal of this document is to enlighten security issues on third party tools that come from some features of the Amazon EC2 console. We are going to explain two security threats, a XSS (cross site scripting), and a command injection, using a second party tool as injection’s vector.

Taking our own product Elastic Detector as an example

First of all, let’s describe the context of our application. Then we will have a closer look at the security issues introduced using the Amazon EC2 console.

Elastic Detector is complementary to the Amazon EC2 console (or other management console). It retrieves security group information by the EC2 API and it helps users to have a global security overview of their infrastructure on Amazon EC2. In addition it performs analysis of potential security threats.

XSS

Amazon EC2 API supports broad characters in the Security Group name. If for example, we define the following Name: <script>alert(“Hello World!!”)</script>

A third party product that displays this Security Group Name without sanitizing the data, it will result on a nice Hello World !! alert popup when browsing this Security Group.

Command Injection

Due to the broad character support in Amazon EC2 in Security Group name, we could define the following Name: `cp /etc/passwd /tmp`

So, once this security group is stored in a database without sanitizing, a third party product using shell commands such as eval, exec, mail or printf, could potentially execute the injected command. So a new file name passwd would be added to the /tmp directory in the product as a simple example.

NB: This could also be done using Amazon EC2 Security Instance Tags, in fact every field supports broad characters in Amazon EC2.

Conclusion

These two security issues are examples that illustrate the fact that a third-party tool MUST check and sanitize user’s input (like all software), but also check and sanitize any data coming from other tools or service SaaS.

Thanks To

We would like to thank the Amazon Security Team that fully collaborated and confirmed that broad character support is a feature of Amazon Web Services (especially Don Bailey) and the Certilience Team that helped us as an external auditor of our code.

/fred

Filed under: AWS, Cloud Computing, Elastic Security, Secure Cloud, , , , , , , , , ,

February 17, 2011 • 21:15 3

Most annoying and at the same time most loved feature of Elastic Detector

During the beta test of Elastic Detector, we had a lot of queries concerning an important feature of Elastic Detector, that is :

  • Elastic Detector considers that an open port in the security groups should correspond to an available service in the instances that use the security group.

For example, if you have defined a security group web with the HTTP port open, Elastic Detector deploys an auto-check HTTP and if Elastic Detector does not get an answer, he raises a critical alert on it.

First of all, why Elastic Detector does this?

From the security point of view, it is a potential threat that can be exploited by an internal or external attacker. It means that the attacker can install a rogue application that has immediate access from everywhere. Imagine that the attacker (internal or external) deploys an e-commerce application to sell viagra on your infrastructure.

So, why sometimes this can be annoying to Elastic Detector Users?

I try to enumerate the reasons they gave us:

  • It is work in progress, so the service is going to be deployed later
  • It is a pain to manage a lot of security groups that should fit their services AND that must be changed whenever a service changes
  • I have IP restrictions to access this service

What are the solutions?

In order to cope with the first and second use case, we plan to allow for an acknowledgment of a temporary exception and for the third we have disabled auto-checks whenever Elastic Detector has no permission to access the service. Of course, once our users add Elastic Detector to the authorized IPs then an auto-check is deployed.

Finally, why is it loved by some Elastic Detector Users?

The administrators that are trying to control cloud usage love this feature. It gives an alert whenever one user changes the security groups, so administrators can at least follow the changes and drill-down if needed.

Conclusion

We strongly believe that the ports should be closed until the service is up and running for the sake of security.

Please let me know your thoughts about this feature, annoying or loved?

Filed under: AWS, Discussions, Elastic Security, IaaS, , , , , ,

February 10, 2011 • 12:29 11

How-To: Copy an EBS-Backed AMI from one region to another one

Goal:

The goal of this document is to describe the process for copying an Amazon EC2 EBS-Backed AMI from one region to another.
We have published an opensource project (CloudyScripts) to automatically perform this operation, but we get a lot of questions about it. We will continue to improve Cloudyscripts to better answer all specific issues but here goes the manual HowTo. ;)

Outline:

  1. Create an archive of the AMI file-system in the source region
  2. Copy the archive in the target region
  3. Create a volume containing the file-system
  4. Create a new EBS-backed AMI in the target region

Requirements:

  • A running instance with SSH access in both source and target region. I suggest to launch an Amazon 32bits micro instance-type from Basic 32-bit Amazon Linux AMI 2010.11.1 Beta in the source and target region.
    NB: On Linux, I’d suggest to export JAVA_HOME and EC2_HOME variables (they also could be added in the command line).
  • A temporary SSH key:
    I suggest to use a 1024 bits RSA key, that can be generated as follows (under a Linux system): 


    linux-box-source:~$ ssh-keygen -b 1024 -C "Temporary SSH Key" -t rsa -f temp_ssh_key
    linux-box-source:~$ ls temp_ssh_key*
    temp_ssh_key temp_ssh_key.pub

  • Get AWS account parameters from your AWS account page in the Security Credentials part:
  • Private Key file: AWS_EC2_PRIVATE_KEY.pem
  • Certificate Key file: AWS_EC2_CERT.pem
    NB: These files can be downloaded from the Access Credentials table, X509 Certificates tab.
  • Get all the parameters you might need from the EBS-Backed AMI:
  • AMI ID: AMI-XXXXXXXX
  • EBS Volume size: VOL_SIZE
  • Architecture: AMI_ARCH
  • Kernel ID (AKI): AKI_XXXXXXXX
  • Root Device: ROOT_DEVICE (usually /dev/sda1)
  • Find the Kernel ID (AKI) that will be used for registering your new EBS-Backed AMI in the target region
  • This is described at the end of the document.

NB: In this document, we will use to a Linux system (for command line) and Amazon Console (for Console Administration), but feel free to use your preferred tools. ;)
NB: The LABEL part is useful for some Linux distributions (such as RedHat, Fedora, Suse, OpenSuse) as they use labeled file system in their fstab file and in the root option of their GRUB configuration file.

Step 1: Create an archive of the AMI in the Source Region

  • Using Amazon console:
  • Launch an instance of the AMI (a micro instance-type should be enough)
  • Create a snapshot of the EBS volume
  • Create a volume from this newly created snapshot
  • Stop the instance
  • Launch an instance in the same availability zone of the EBS volume
  • Attached the newly created EBS volume to the running instance in that region and check the name of the device (/dev/sdx)
  • Using you favorite SSH tool, connect to the running instance in the source region and get root access:
  • Get the device label:

    [root@amazon-linux ~]# e2label /dev/sdx
  • Create a mount point:

    [root@amazon-linux ~]# mkdir /mnt/ebs_volume 

     

  • Mount the device on that mount point:

    [root@amazon-linux ~]# mount /dev/sdx /mnt/ebs_volume/
  • Create an archive of the device:

    [root@amazon-linux ~]# tar -zcpvf /mnt/system-YYYY-MM-DD.tar.gz /mnt/ebs_volume/
  • Using Amazon console:
  • Detached the newly created EBS volume to the running instance in that region

NB: If needed you can get root access as follows:

[ec2-user@amazon-linux ~]$ sudo su -
[root@amazon-linux ~]#

NB: Avoid bzip2 compression if you use a small CPU instance.

NB: Please note the file system type (ext2, ext3, …), as it will be reused in the target region while creating a new file system

NB: Please note the permissions while creating file system from archive (-p option)

Step 2: Copy the archive to the Target Region

  • Copy the temporary SSH Private Key on your running instance in the source region:
  • Using you favorite SSH tool to copy the file.
    This could be done as follows on a Linux system:

    linux-box-source:~$ scp -i ssh_key_4_amazon-linux_source.pem temp_ssh_key ec2-user@amazon-linux_source.compute.amazonaws.com:~/
  • Using the Amazon console, launch an instance in the target region (be careful with the availability zone)
  • Add the temporary SSH public key to the authorized key, and reload SSH daemon:
  • Using you favorite SSH tool, connect to the running instance in the target region and get root access
  • Edit file .ssh/authorized_keys and add you public temporary SSH key contained in file temp_ssh_key.pub
  • Reload SSH daemon

    [root@amazon-linux ~]# /etc/init.d/sshd reload
    Reloading sshd: [ OK ] 

     

  • Copy the archive from the source region to the target region as follows:

    [root@amazon-linux ~]# scp -i /home/ec2-user/temp_ssh_key /mnt/system-2011-01-20.tar.gz ec2-user@amazon-linux_target.compute.amazonaws.com:~/

Step 3: Create a volume containing the file-system in the Target Region

  • Using Amazon console:
  • Create an EBS volume in the target region in the same availability zone as your running instance and of the same size of the EBS volume of your EBS-Backed AMI in the source region
  • Attach that volume to the running instance in the target zone
  • Using you favorite SSH tool, connect to the running instance in the target region and get root access:
  • Create a file-system on the device (same file system as the one used by your EBS-Backed AMI):
    [root@amazon-linux ~]# mke2fs -t ext3 /dev/sdx
  • Set device label: LABEL

    [root@amazon-linux ~]# e2label /dev/sdx LABEL
  • Create a mount point:

    [root@amazon-linux ~]# mkdir /mnt/ebs_volume
  • Mount the device on that mount point:

    [root@amazon-linux ~]# mount /dev/sdx /mnt/ebs_volume/
  • Extract the archive to that mount point:

    [root@amazon-linux ~]# tar -zxpvf /mnt/system-YYYY-MM-DD.tar.gz -C /
  • UnMount the device:

    [root@amazon-linux ~]# umount /mnt/ebs_volume/
  • Using the Amazon console:
  • Detach the newly created EBS volume to the running instance in that region

NB: If needed you can get root access as follows:

[ec2-user@amazon-linux ~]$ sudo su -
[root@amazon-linux ~]#

NB: Be careful with the permissions while extracting the file system from archive (-p option)

Step4: Create an EBS-Backed AMI in the Target Region

  • Using the Amazon console, create a snapshot of the volume:
  • Register a new AMI from the previously created snapshot, using Amazon EC2 API tools:

    linux-box-source:~/ec2-api-tools-1.3-62308$ ./bin/ec2-register --private-key AWS_EC2_PRIVATE_KEY.pem --cert AWS_EC2_CERT.pem -v -H --region TARGET_REGION -a AMI_ARCH -s SNAP-XXXXXXXX -d 'CopyAMI Generated' -n 'AMI_DESCRIPTION' --root-device-name /dev/sda1 --kernel AKI-XXXXXXXX

NB: The kernel ID AKI-XXXXXXX is found by the procedure at the end of this post

Cleanup

  • Using the Amazon console:
  • Terminate the running instance in the source region
  • Cleanup the EBS volume created in the source region
  • Cleanup the snapshot created in the source region
  • Terminate the running instance in the target region
  • Cleanup the EBS volume created in the target region
  • Cleanup the snapshot created in the target region

Find the right Kernel ID (AKI) for registering your EBS Backed AMI

Outline:

  1. Find the description of the original AMI used to create your EBS-Backed AMI in the source region
  2. Look for the same AMI in the target region using the description of the original AMI
  3. Get the Kernel ID (AKI) of the corresponding AMI in the target region

HowTo:

  • Retrieve all the AMIs in a specific region that use a specific KernelID (AKI):

    linux-box-source:~/ec2-api-tools-1.3-62308$ ./bin/ec2-describe-images --private-key AWS_EC2_PRIVATE_KEY.pem --cert AWS_EC2_CERT.pem -v -H --region SOURCE_REGION -a -F kernel-id=AKI-XXXXXXXX
  • Retrieve a KernelID in a specific region that is used by a specific AMI:

    linux-box-source:~/ec2-api-tools-1.3-62308$ ./bin/ec2-describe-images --private-key AWS_EC2_PRIVATE_KEY.pem --cert AWS_EC2_CERT.pem -v -H --region SOURCE_REGION -a -F name="*AMI_NAME*"
  • Example: Suppose I made an AMI using a FreeBSD AMI: FreeBSD/EC2 9.0-CURRENT 2011-01-04 in US-West and I want to copy that AMI to US-East
  • I just have to retrieve the KernelID to use in the target region, as follows:

    debian-secludit:~/ec2-api-tools-1.3-62308# JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.20 EC2_HOME=/root/ec2-api-tools-1.3-62308 ./bin/ec2-describe-images -K ../amazon-ec2-keys/key-BK54TI5LZQMBWA3GVE4XXFYMCWSUCGVY.pem -C ../amazon-ec2-keys/cert-BK54TI5LZQMBWA3GVE4XXFYMCWSUCGVY.pem -H --region us-east-1 -a -F name="*FreeBSD*"
    Type ImageID Name Owner State Accessibility ProductCodes Architecture ImageType KernelId RamdiskId Platform RootDeviceType VirtualizationType Hypervisor
    IMAGE ami-c01aeca9 118940168514/FreeBSD/EC2 9.0-CURRENT 2010-12-12 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-409c852a 1
    BLOCKDEVICEMAPPING /dev/sdb snap-ce948da4 9
    IMAGE ami-a0fc0dc9 118940168514/FreeBSD/EC2 9.0-CURRENT 2010-12-29 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-7127841c 1
    BLOCKDEVICEMAPPING /dev/sdb snap-291ab944 9
    IMAGE ami-f4db2a9d 118940168514/FreeBSD/EC2 9.0-CURRENT 2011-01-01 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-dbe855b6 1
    BLOCKDEVICEMAPPING /dev/sdb snap-2fe35e42 9
    IMAGE ami-8cce3fe5 118940168514/FreeBSD/EC2 9.0-CURRENT 2011-01-04 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-1df57270 1
    BLOCKDEVICEMAPPING /dev/sdb snap-e1fe798c 9
  • I could register my new AMI using the following KernelID: aki-407d952

/fred

Filed under: AWS, Cloud Computing, Documentation, , , , , , ,

Twitter Updates

Follow

Get every new post delivered to your Inbox.