Americas

  • United States

Asia

Oceania

Skyport eases the pain of deploying and securing remote servers

Reviews
Feb 29, 201612 mins
SecurityVirtualization

SkySecure Server is a bulletproof, preconfigured box running Xen as a platform for VMs.

cloud security
Credit: Thinkstock

Skyport does one thing, and it does it well. Skyport offers SkySecure Server, a remotely deployable platform for Windows and/or Linux virtual machines in a fortress-like environment.

You can rent one for $2,500 per month, or less.

Skyport SkySecure Servers solve a major pain point for IT execs looking for control over their remote servers. Skyport provides a hardened server that can be safely deployed to off-premises locations with little to no pre-configuration headaches.

It comes pre-built and ready to host and secure either their list or your qualified list of popular host operating systems as VMs. Once deployed it’s largely tamper proof, and its subsequent use is done remotely, securely, with full online-monitoring control. Skyport is as security-paranoid as we are; therefore we liked it, finding only a few foibles.

The company is a startup, and in the space of time we used their chassis and software, we saw incremental improvements. We’re usually suspect of single server “solutions,” but the problem is real enough. The secret sauce employed by Skyport is that it’s not only convenient, but uses at every turn, a chain-of-authority in security and systems configuration that allows it to be managed fully by remote control through its portal.

Its single major weakness is incomplete backup, which Skyport says will be upgraded soon.

A future backup upgrade, along with other upgrades, are free, part of “the deal” when you rent this server for $2,500 a month (longer term costs less). The only downside to upgrades is that the server will probably have to be rebooted to accommodate their upgrade methodologies, rather than being slipstreamed into the server. Each new upgrade renders a new TPM-controlled datum that is keyed to systems authenticity and plausible non-repudiation needed to quell audit concerns.

Readying the server

Skyport sent a SkySecure system, per our configuration requests, which amounted to choosing the network interface and the server’s DNS host name. We slammed it into the rack in our NOC at Expedient in Indianapolis. We plugged it into our switch, then into the power lines, and left the NOC for the lab, 70 miles away.

Nothing more can be done to the server directly at installation as it’s in a highly tamper-resistant chassis, with one tiny exception. Only network ports are exposed. If you can manage to get the server plugged into a network, power it up, and have a nearby/reachable DNS server configured to know the server’s DNS host name—which you’ll pick in advance—then you’re done once the server finds the mothership portal—which it did, automatically in our case.

For 90%+ of deployments, this is a piece of cake. Everything, every characteristic and platform setting, is done through the portal. In a multi-tenant environment, it stands alone as an island accessed only through the bridge of Skyport’s SkySecure portal.

We returned to the lab. We logged in to the portal and the server was already communicating. Nothing outside the server can talk to the server, except to us via the portal (and with your explicit permission, SkySecure support staff). The server hosts compartments, which will wrap virtual machines, either pre-configured or generated/mounted inside the SkySecure server.

Each new compartment inside the server is a Xen-controlled environment for each operating system, and all of the defaults are totally walled to the outside world until an administrator explicitly enables proxied services (think ssh, RDP, etc) that can talk to a generated VM within a compartment.

Only the portal, via admin access, can touch the controls that in turn make ports available to the virtualized host OS. The ports are nicely scrambled, and can be scrambled and proxied again from outside the compartment to a non-standard port address inside the compartment

We could choose either Skyport-provided and supported workloads (think Windows server, RedHat, Canonical, Debian) or we could import own custom workload cuts.

An administrator will specify exactly how the deployed operating systems will talk to the rest of the world from their compartment, or the local resources either inside the box, or outside of it.

Our small criticism is that Skyport doesn’t keep track of all the proxy ports, and so it’s possible to make stupid configuration mistakes that are easily remedied.

+ ALSO: Will enhanced servers do away with need for switches? +

Each compartment’s network traffic can be fully mirrored back to the SkySecure portal if desired for debug or audit purposes. It’s possible for VMs to talk to each other, and of course, the outside world/Internet. Otherwise, communications goes through the portal and nowhere else until such traffic capabilities are enabled. The portal can also be queried via JSON calls if you know what you’re doing, or you can merely watch in awe through a Chrome debug browser as their web service makes calls using RESTful API & JSON actions/responses.

There is no documentation on the portal API set, but the rest of the documentation we used was both complete and correct, and explicit.

The SkySecure Server

There are two eight-core Intel Xeon processors (E5 2630v), twin 960GB SSDs, 128GB of memory, and a TPM chip on both the motherboard, and the SkySecure I/Controller inside the server. Pick one. This is the only model. If you need more, get two.

The SkySecure server inside our rack in the NOC had no jacks, save a single mini-USB jack that can be used as a terminal via SLIP over USB, and as it times out logon failures, it should take about 9,000 years to hack using dictionary attacks.

There are two network options: two jacks of either 10Gigabit Ethernet fiber and/or copper. We chose 10G Ethernett fiber. It’s otherwise tamper proof, unless you want to solder or clip something into the motherboard. However, many such mods can be detected, and for protection and forensic analysis, Skyport can send you pictures of your exact server so as to get a visual identification of any mods that may have been done. Many mods will also trip protections around the TPM chips.

Net results

COMPANY:SkyPort Systems
PRODUCT:SkySecure Server
PRICE:$2,500/month, $2,200 for three years
PROS:Leasable highly secure VM host; tamper-resistant
CONS:Portal slow to react sometimes; integrated backup lacking

The TPM chip on the x86 motherboard serves as the basis for a chain of authorities in terms of firmware and infrastructure. The server system does periodic authentications on the two primary components of the server, the x86 subsystem which is the server motherboard/related component, and the TPM chip resident on SkySecure’s proprietary I/O controller. There is internal storage space for preloaded or subsequently populated OS images.

Upon this substrate, one deploys compartments, which are Xen VMs. SkySecure supplies two “demo” containers that serve as examples of templates that can be deployed in compartments, which can be downloaded directly from SkySecure, and a list of heterogeneous operating systems that also can be downloaded as essentially unconfigured ISO-type examples supported by SkySecure directly.

Up and hosting VMs

For those of us desiring our own images for whatever reason, they can be imported, but only in Xen-supported formats, which include .OVA (VMware-like single file payload package), QCOW2, a raw IMG file, or VMDK file; these can be gzipped images in any of the aforementioned formats. The payloads available from SkyPort include Centos7, RedHat, Windows 2008 and 2012 (various revs), Debian, and Ubuntu Linux; these are checked images. Other images are supported experimentally, which is good, because that’s the first thing we tried.

We made an Ubuntu 15.10 server image, above the 14.04 LTS available from SkySecure by forming it in VMware vCenter 5.5, then into a .OVA payload. We could use NFS to move this image into the SkySecure server, but we chose SCP to do this.

Here comes the reason why we should have uploaded and stored our images in the SkySecure portal: The portal must drag the image, upload it to the portal, then download it to the compartment under its control, essentially dragging it through the Internet to accomplish this. That means it’s about 2x+ the normal time to deploy units on one’s own subnet, because the portal is the total and exclusive nexus for downloading the desired file. Then it must start the image once loaded.

Scorecard

Administration4
ServiceabilityN/A (must be replaced)
Security/Docs5
Features4.5
TOTAL:4.5

There are a number of tailoring steps at compartment generation time that concern how SkySecure manages the honeycomb wrapper around the compartment/VM. Much of this is turning on and off any/all sorts of IPv4/6 ports, choosing if SSH, RDP, ports will be used, and the choice of the port number to use, as well as attachment permission to LDAP, AD, etc. We could close all ports, TCP/UDP, meaning that we could make the compartment as visible as we’d like, and the ports would be scrambled so that if a network bot was looking for ssh, RDP, VNC, etc., it wouldn’t be where they expected it — if we allowed such a service at all.

This also means that it’s possible, from within the SkySecure portal, to get a web page view of the instance as well, as seen by a remote-desktop/DaaS sort of view for support purposes. Or not—our choice.

In all, the honeycomb compartmentalization of the operating systems instances are largely bulletproof, and so a field deployment of OS instances is both automated, and requires about a tenth of the time of manually-composed services, and perhaps half the time of servers composed from the best automation services.

The downsides

All instances have reaction latency that’s a direct function of the latencies between the SkySecure portal, the circuit between it, and the administrator accessing the portal. The latencies add-up. We drummed our fingers a few times, and went for caffeinated beverages.

+ ALSO Low-cost RADIUS servers for Wi-Fi security +

There are single points of failure potential. If someone infects a container that can punch through the hardened Xen and hardened Linux substrate underneath— and the added SkySecure security walls, the server loses its status as inviolate. Of course if this happens, AWS and others will soon explode, as well, which means that Xen-as-a-target has big organizations tending to its safety, which counterbalances the possible threat to Xen exploding. We rank this as a low possibility, but to be remembered nonetheless. The VPN connection via TLS is also vulnerable in a similar way.

The SkySecure Center portal is the second area of potential failure; Skyport must keep this portal inviolate at all costs, and it exists in only one US-domestic data center. Once breached, the keys to many data principalities and workflows kingdoms are exposed. They seem to do a good job, and seem zealous about their architecture in a delightfully paranoid sort of way, meaning that our mild observations indicate that they’re paying attention. Nonetheless, a single point of failure exists here.

Images of OS instances can be saved onto local storage, via an export method using a regimen where an initial template is made salient to the OS instance, then the template/image is exported. This can be simple for many organizations, but it isn’t automated in a snapshot-ish methodology, and so replication isn’t as easy as it could be. We’re told this may be fixed/featured by the time you read this.

SkySecure server machine instances can be connected to each other for N+1 reliability/failover, but such connections are up to the organization in terms of linking VMs, as the underlying server hardware and software are autonomous and not linkable in any way, so failover or transaction-based systems must solve N+1 at the VM layer, and not underneath at the host/hypervisor layer.

This is a decided weakness, although the deployment from a cratered OS instance from a local storage is comparatively quick, and so if app/data/configuration/transactional information are exported outside of the auspices of SkySecure server controls, a comparatively easy restoration from fatality is possible. Servers must be considered islands with VMs on them that link to other servers for N+1 redundancy and transaction-tracking purposes.

Backup images can be restored immediately when a compartment is re-started, and there are N+1 configurations of multiple SkySecure servers, where images can be drawn from a multi-server pool of them.

If a deployed server has a hardware failure, and such things happen, there’s not a viable regimen to fix the server in the field. It has to be replaced, although with worldwide logistics being as mature as they are, SkySecure claims they can ship same-day on orders. We did not test this claim.

Summary

You can go through the various trials, tribulations, and procedures to generate a VM host for remote deployment, including making a server securely deployable, or consider that Skyport has done the very vast amount of homework, integration, and security thoughtfulness for you. It has a usable, web-based portal that administers the characteristics of the server, and of all of the compartments/workloads within it. Its security is absolutely draconian, but comparatively simple to integrate and manage. It ascribes to none of the major vendor-tied ecosystems, both a weakness and for many, a strength. We like the use of the TPM modules that prevent software tampering. Rootkit installations should be really difficult to perform.

Skyport’s SkySecure methodology poised towards remote deployments is a winner for the non-ecosystem-aligned organization that needs the convenience of Skyport’s business model, which is that they own the servers—you lease them—they ship them—you do the container management and occasionally reboot for update installation(s).

How we tested

We deployed the server hardware into our NOC at Expedient in Indianapolis, to a 10GBE fiber network controlled by an Extreme Summit Series L2/L3 switch, which is in turn, connected to Expedient’s core backbone.

We used a Bind9-based DNS server in our testing, localizing a VLAN for testing the server. We used Firefox and Chrome Browsers to access the portal using hypervised Windows and Mac sessions from our Lab and other sites using Comcast broadband circuits to the SkySecure Center portal.

Tom Henderson runs ExtremeLabs, in Bloomington, Ind. He can be reached at kitchen-sink@extremelabs.com.

tom_henderson

Tom Henderson is dojo of ExtremeLabs, researcher at Network World, world traveler, and friend to many.

More from this author