Elastic Security

Icon

Security for the Cloud

November 22, 2011 • 18:32 0

Elastic Security: Vulnerability Assessment

Elastic Detector, our FREE Vulnerability Assessment tool for Amazon EC2, has been recently updated with NEW features. Of course, the NEW Amazon US-West (Oregon) has been added at the meantime (see the AWS blogpost for more information).

Sometimes, security is considered boring (as shown in one of our previous posts on Open Ports Check), I take this opportunity to give some explanation on the recent Security Features that have been added and to point out two features of Elastic Detector, that are essential for providing a security solution that can cope with the elasticity of cloud infrastructures.

New Security Features of Elastic Detector

  • Blacklist Checks: Check against well-known RBLs if your Elastic IP Address (EIP according to Amazon naming), or the IP address taken from Amazon pool address is blacklisted.
    This allows cloud users to detect configuration errors in a mail server that is used as an Open-Relay or to detect a malicious insider that is using your infrastructure to install a bot-net (part of CloudSecurityAlliance Top Threats).
  • Critical Ports Audit: Check against a tunnable list of sensitive ports that there are no critical ports open to the public.
    This allows cloud users to be protected from dictionary attacks on administrative services such as SSH, Webmin (for Linux instances), or RDP (for Windows instances).
  • Security Zones Auditor: Define Security Zones according to the port that are accessible (using 3 Levels of Security: public, sensitive and critical) and the source IP addresses that have access to those ports (using 3 Levels of Trust: untrusted, fairly-trusted, trusted). Based on that information, Elastic Detector verifies if there is a perfect separation between servers of different trust levels with regard to their Security Zones. For example, in a three tiered architecture (Web server, Application server, Database server), an instance running a Web server should not be able to directly access an instance running the database server as this will potentially expose your data in case of compromise of the web server.

Two Characteristics of Elastic Detector

  • AgentLess: No additional agent or software to install on your instance (AMI according to Amazon convention naming).
    Using APIs, there is no risk of loosing connectivity with an agent (due to a network problem, a misconfiguration, or a human error) and no need to maintained the agents that are deployed. Moreover, the agent is itself a target for attack, so using APIs give us an additional level of isolation.
  • Auto-Check Technology: Any cloud resources (especially instances) are under control during the complete life-cycle, as continuous Security Checks based on customizable templates are automatically put in place as soon as the resource is detected by a real time polling system til the resource is shutdown.

Feel free to comment or ask more details on the security points.
/fred

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

August 4, 2011 • 17:37 1

Monitoring Tool: Amazon EC2 plugins for Nagios

SecludIT has published two plugins for monitoring Amazon EC2 with the Nagios Open Source monitoring solution. These plugins are available on Nagios Exchange under the Apache2 License . Both Nagios plugins are written in Ruby on top of the Amazon EC2 Ruby Gem library and use HTTP Query API calls to Amazon API endpoints.

Nagios Plugins for Amazon EC2

Nagios Open Source monitoring solution consists of various Nagios projects as follows:

  • Nagios Core: the open source monitoring engine and multiple APIs for extending core functionality
  • Nagios Plugins: efficient, standalone extensions that provide low-level intelligence for monitoring everything with Nagios Core

Contrarily to traditional IT infrastructures, Cloud Computing stacks (such as Amazon EC2) allow server monitoring through their programming interfaces (APIs), meaning that:

  • you do not need to install and maintain agents on the servers (for example, no need for SNMP agents installation and configuration)
  • you do not need to configure and protect a privileged access to the servers (for example, no remote SSH tunnels)

The plugins we provide illustrate these advantages. Without agents, you can:

  • know the status of your servers (running, stopped, starting, stopping)
  • get metrics of your servers (CPU, Network traffic and disk usage)

Check Amazon EC2 Instance status plugin

The Check AWS EC2 Instance Status plugin allows to retrieve the status of Amazon EC2 Instances. This is a Nagios active check that takes the Amazon API endpoint and an Amazon EC2 Instance ID as input parameters, connects to the Amazon API endpoint through HTTP Query API calls and retrieve the status of an Amazon EC2 Instance.

Get Amazon CloudWatch metrics plugin

The Get Amazon CloudWatch metrics plugins allows to retrieve metrics from Amazon CloudWatch. This is a Nagios active check that takes the Amazon API endpoint, an Amazon EC2 Instance ID and the CloudWatch metric as input parameters, connects to the Amazon API endpoint through HTTP Query API calls and retrieve the value of the metric for the Amazon EC2 Instance.

Security

As these two Nagios Plugins requires Amazon Credentials (Access Key ID and Secret Access Key) to connect to Amazon APIs endpoints we must ensure that the Amazon Credentials are encrypted (that is, not stored in clear on the disk) and permissions for the encryption key and the encrypted credentials must be restricted to the user or daemon running the plugins. Moreover, our plugins only require a read-only access to the Amazon APIs endpoints, therefore we highly recommend the use of AWS Identity and Access Management (IAM) to generate read-only Amazon Credentials. We have written a blogpost on how to generate read-only Amazon EC2 Credentials.

Amazon EC2 security monitoring using SecludIT’s Elastic Detector

SecludIT uses Nagios on Elastic Detector, a Security and Monitoring Tool for Amazon EC2. The two Nagios Plugins (that we gave to the community) are used in Elastic Detector to get the status and metrics of Amazon EC2 instances. This information is one of the inputs to our detection engine, and is complemented by other security related information such as Amazon EC2 Security Groups analysis and open ports. Therefore, Elastic Detector is agentless and detects Amazon EC2 security related events.

Feel free to try out our Nagios plugins and Elastic Detector and let us know what do you think.

/fred

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

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, , , , , , , , ,

June 23, 2011 • 11:37 0

Tendances cloud

Sorry to the non-french readers, but I’m often asked for french papers about cloud computing and security. We are proud to be contributors to a french white paper on cloud computing, so here is the link:

http://www.tendances-cloud.com/

Bonne lecture

Filed under: Cloud Computing, Elastic Security, IaaS, News, SaaS, Secure Cloud, , , , , , , , ,

June 16, 2011 • 09:02 0

How to increase security and visibility of Amazon EC2 instances?

Amazon EC2 administrators have to deal with daily problems such as:

  • Ensuring security of new instances,
  • Detecting performance and capacity problems,
  • Keeping track of the modifications on the infrastructure.

We would like to provide you some insights in our solution to address those problems and to facilitate the life of cloud-administrators by detecting security related issues and events: Elastic Detector. What makes this product unique is that it is fully automated and agentless. You can see how Elastic Detector works on this short video:


Filed under: AWS, Cloud Computing, Elastic Security, IaaS, Internals, Secure Cloud, Solutions, , , , , , , , , ,

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, , , , , , , , , ,

September 22, 2010 • 21:57 2

Multi-factor authentication with Google apps

I have just realized that my last post was about the Multi-Factor Authentication (MFA) on Amazon Web Services, what a coincidence or is it fashion? Anyway, I’m really happy to see that authentication is finally getting some good solutions, and this is an important step to achieve secure clouds.

So, back to the Google announcement. We have been using Google Apps for more than one year now and it is really an easy way to share everything, from documents to calendars. In this case, the second factor authentication uses your telephone. I’ve followed the clear instructions to setup the MFA, installing Google authenticator in my iPhone. Everything was done in 5 minutes and it works!

I’ve to say that I would like to know more about the algorithm that generates the one-time codes, but it really solves the problem of signing in on untrusted terminals, and you can even use it on your everyday computer if you don’t mind having your phone with you and tapping the code.

But there was a problem: I could not get my iPhone synced (contacts, emails, calendars) with the Google account using MFA. I could use the Google Apps but I’m used to use the iPhone default applications so I’ll have to wait for Apple to support the Google MFA…

Yet an integration problem or another example of the usability vs security issue? Any thoughts?

Filed under: Discussions, Secure Cloud, Solutions

March 19, 2010 • 16:19 0

Thoughts about Secure Cloud 2010

I was at Barcelona for the Secure Cloud 2010 conference. Here are my impressions at the end of 2 days of interesting discussions.

I was happy to realize that – thanks to CSA and ENISA – we are definitely moving forward. We are getting out of endless discussions about problem statements and rather heading towards the next phase, which is about solutions. Here some examples:

  • We started to prioritize the issues, best illustration of this is the CSA top threats initiative.
  • We started talking about security metrics and frameworks for assurance and certification (expert groups within CSA)
  • Some community projects are starting, for example, Craig Balding‘s upcoming SkyLab project that uses an Amazon Machine image based on a Backtrack distribution to perform penetration tests within EC2. Issues with Amazon’s service terms are solved. (I cannot resist to also point to our own open source project Cloudy_Scripts).
  • Other very interesting initiatives that have been started already are OIX, an initiative by several industry giants to deal with the communication of online identity credentials over the web, and CloudAudit (former name A6) that works on defining an API to automate auditing and security assessment of cloud deployments.

There are plenty of opportunities to get involved and contribute. Now that we’ve got a better understanding of the security problems and have started moving forward, we must not forget to keep up with the pace of cloud providers, which are constantly working to improve their offerings.

Filed under: AWS, Discussions, Secure Cloud

Twitter Updates

Follow

Get every new post delivered to your Inbox.