Skyport eases the pain of deploying and securing remote servers

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.

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.

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.