Tuesday, September 30, 2014

2014 SVC Awards Recognise VNS3 For Cloud Networking Successes - Now Go Vote!

We're honored to announce today that we're double shortlisted for the Storage Virtualisation Cloud (SVC) Awards. Voting is now open!


Award Categories: 
Our updates to our cloud networking product, VNS3, got us into the finalist spot in two award categories for our work with VNS3 3.5 and our customers' work with Docker container networking.

  • Cloud Security Product of the Year 
  • Vendor Reseller Channel Program of the Year 

With VNS3 version 3.5, customers and partners have been building Docker container systems into VNS3 Manager VM to manage network functions from a single, secure network. That added flexibility, security, and interoperability got the attention of the SVC Awards judges. Now we need your help to make it official - vote for us to win in November!
About VNS3:
VNS3 is a cloud-based networking product made entirely of software. VNS3 acts like a hybrid combination of a router, a switch, a firewall, and security devices. With VNS3 cloud networking, companies can control access and network topology.

With over 1,000 connected customers in more than 24 countries, VNS3 has provided hundreds of millions of devices hours of application networking for the cloud.  VNS3 offers customers enhanced network services on top of the cloud providers' network backbone.

See our Life in the Cloud webinar series, where CohesiveFT customers have been using VNS3 for partner/ customer networks, cloud WAN, HIPAA compliance, and more.

And don't forget to vote for CohesiveFT and VNS3! Cast your vote today: http://www.svcawards.com/voting.php

Thursday, September 25, 2014

Jury Duty and Data Center Over Provisioning

This past Friday I have the distinct pleasure of waiting in the Chicago courthouse all day as a “standby juror.” I reported to the waiting area in the morning, was assigned group numbers, and waited to see if I got called to be interviewed and possibly selected for a jury. The process is slow and the cases could be anything from a murder trial to injury claims. Each group might or might not get called to actually serve a purpose for our city, but in the meantime we all wait together in disgruntled silence.

Just waiting around... Image credit: Wikimedia
While spending 6 hours without wifi, I got to thinking about the jury selection process and traditional computing.

Jury selection is a lot like traditional data center-based computing. 
Wait for it…

The court only needs 12 people at a time for a jury. But, there might be several trials going on that day. And, the lawyers need the flexibility to select or not select jurors for each specific case. So to compensate for the unknown number of jurors called in a day, the courts call more than enough people to sit around and wait, just in case. People are sleeping, reading newspapers, and blankly looking out the window. Not exactly using any of our time well by just waiting.

Traditional data center servers are just like me. Instead of standby juror, the servers are over-provisioned in a data center. Data center administrators and IT teams cannot possibly estimate their compute needs over the lifespan of a dedicated data center (upwards of 15 years, even in a well managed data center with rapid refresh cycles). Instead of risking running out of server capacity, IT teams over-provision and keep servers on hand for added capacity and unique use cases.

What’s the solution? 
In no way could I claim to know the solution to the US justice system, much less propose something in a short blog post. But I can propose a solution to data center over-provisioning: cloud computing.

Cloud is the easy answer for use cases ranging from capacity expansion to new POCs and deployments outside the data center. Rather than build a physical building with the proper HVAC and lighting requirements, buy the very expensive servers and racks, and install all the requisite security and staffing measures public cloud can take care of that for you. For a fee, of course.

Cloud pricing still claims to be "pay-per-use functionality, when really
they’re offering pay-per-allocation" as Chad Lawler points out in our ebook.  But there are great improvements in a cloud-provisioned world compared to data centers. Autoscaling is a cloud-only feature that uses actual load data to either scale up or down, depending on the need for better resource utilization (read: not wasting money on over-provisioning or losing customers by not predicting correctly).

Cloud compute capacity still slightly over-provisions, but has made improvements to use real time data to predict usage. Plus, cloud-based resources use OpEx rather than CapEx, and you get instant gratification for the one-off high availability projects. Cloud computing lets IT organizations spend more time building the current projects rather than worrying about if and when they should plan for future unknowns.

So while I sat there waiting for the possibility of serving on a jury, I at least wrote this blog post. I’ve been productive - can you say the same for the over-provisioned servers in a private data center? 

Good news. I didn't have to resort to this.
Image credit: Paigekellerman

VNS3 and the Shellshock bug: New images and live patching ready to roll.

Bash Command Interface Vulnerability  (CVE-2014-6271) VNS3 supported versions 2.7, 3.0, 3.01, 3.03, 3.04, and 3.5 are potentially affected by the Bash command interpreter bug being labeled the “shellshock” bug (CVE-2014-6271). NIST Notification. Read more about Shellshock via The Register

We've written a full security alert on our security news page: cohesiveft.com/support/security-responses
image credit: Wikimedia Commons

Is VNS3 vulnerable?
Attacks on VNS3 instances are theoretically possible – the standard VNS3 deployment practices do not make such attacks likely. Regardless of this limited attack vector, we are still making new VNS3 images available for all supported cloud environments. For the full security report and available patches, visit cohesiveft.com/support/security-responses

Live Patches: 
We are available to live patch any running Manager. Send a message to our support team to receive instructions on providing access via our multi-factor/multi-party remote support authentication system. The live patch takes less than a minute to apply but requires our involvement.

Monday, September 22, 2014

Secure container provisioning and the VNS3 API - part 3

In the first part of this series we created a simple Docker container and then a separate customisation Dockerfile. In the second part we gave a brief walkthrough on how to write a simple Java utility to interface with the VNS3 API. In this part we’ll wrap things up with a bit more code and lot of exercises for the reader.
Image credit: Docker

At this point the code makes the connection and can handle GET requests but it doesn’t allow POSTs, so we need to extend our code a little. In particular, in the Vns3ApiConnection class we’ll add a post() function:

String post(String api_path, String query) throws Exception {
    String response = "";
    try {
        HttpsURLConnection httpsConnection = setConnection(api_path, "POST");
        httpsConnection.setRequestProperty("Content-length", String.valueOf(query.length()));

        OutputStream outputStream = httpsConnection.getOutputStream();

        if (httpsConnection.getResponseCode() != 200) {
            throw new RuntimeException("HTTP PUT Request Failed with Error code : "
                    + httpsConnection.getResponseCode());

        BufferedReader responseBuffer = new BufferedReader(new InputStreamReader(

        String output;
        while ((output = responseBuffer.readLine()) != null) {
            response += output;

    } catch (Exception e) {
    return response;

This is a straightforward function. It makes the connection, sets the payload (via JSON in the case of the API calls we’ll be using) and sets a return string with the result from the call.
So far, so good. We also need to add some image-specific functionality to our main class. We’ll create two functions:
private static void get_images(Vns3ApiConnection api) throws Exception {
    String imagesURL = "/api/container_system/images";
    String response = api.get(imagesURL);

    System.out.println("Output from Server:  \n" + response);

private static void create_image(Vns3ApiConnection api, String query) throws Exception {
    String imageURL = "/api/container_system/images";
    String response = api.post(imageURL, query);

    System.out.println("Output from Server:  \n" + response);
Finally, we modify the main() function to look like:
public static void main(String[] args) throws Exception {
    try {
        Vns3ApiConnection api = new Vns3ApiConnection(host, user, password);
        String secure_host="";

        String base_image_url = secure_host + "/base_images/base_ssh_image.tar.gz";
        String customise_image_url = secure_host + "/personalisation/customised.tar.gz";


        // Do this properly via a JSON object
        String query = "{\"name\":\"ssh-server\",\"url\":\"" +
                       base_image_url + "\"}";
        create_image(api, query);

        // At this point we would query the images using get_images()
        // until we know that our latest image either succeeded or failed.
        // We'll fake it by sleeping for 20 seconds

        // Then we would create a new image from a Dockerfile referencing the first image
        // Note that "buildurl" is used here because we're using a Dockerfile.
        query = "{\"name\":\"customised\",\"buildurl\":\"" + customise_image_url + "\"}";
        create_image(api, query);

    } catch (Exception e) {

At this point we have enough that we can create an image and then recreate one, or to import a base image and then customise it.

The files for this post can be downloaded here.

Once we have this running we can start a container. This container will have an IP address tied to the VNS3 manager and will only be accessible if the firewall rules have been set. One of the exercises for the reader is to adapt the code so that firewall rules can be added. (The URL is /api/firewall/rules and the usual REST verbs of GET, POST and DELETE apply.)

The rules needed will look similar to:
-o eth0 -s -j MASQUERADE
PREROUTING_CUST -i eth0 -p tcp -s --dport 9022 -j DNAT --to

Where the first line is enabling masquerading, 9022 is the port from the outside (port 22 is already in use by default) and is the IP address of the container.

In this series of posts we’ve looked at creating a simple method of customising Docker containers within VNS3 and using the API rather than the GUI. I’ve deliberately left out a lot of steps and the code is sparse by design. Take the code, fix it up, flesh it out and put it to use in a real library or application. Let us know your results.

The VNS3 Manager API documentation can be found here: http://www.cohesiveft.com/dnld/CohesiveFT-VNS3-3.5-API.pdf

Friday, September 19, 2014

Weekly news roundup for Cloud and Networking: September 15 - 19

Cloud and Networking news for the week of Sept 15th
  • InfoWorld: 4 ways Docker fundamentally changes application development
  • From Tim Fernholz on Quartz: How two “holy grails” of cryptography can make the cloud safe everywhere
  • The Programmable Web: The Naked Truth about Internet Security >> recent attacks were just another successful hack in a long line of them. The news is proof of "(1) the lengths to which hackers with nefarious intent will go to achieve their objectives, (2) the fundamental problems with the way the Internet is secured, and (3) how APIs are increasing the Internet's vulnerable surface area and what API providers must do about it"
  • Talkin' Cloud: The 3 Most Dangerous Misconceptions About the Cloud
  • Venture Beat: Docker, the hottest cloud startup in the West, adds $40M
This is not what SSL keys look like, but you get the idea. Reuters/Akhtar Soomro via Quartz

CohesiveFT in the news:

Catch up with the CohesiveFT team:

Share this Post

Related Posts Plugin for WordPress, Blogger...