Stormy Weather

Basics in the Cloud

After choosing a provider, the next step is usually to set up the basic virtual environment in which you will be operating your services. A few basics should be considered that allow implicit security and are based on the assumption that caution is better than indulgence.

Unfortunately, you can still see public cloud setups today that admins have simply and stubbornly copied from conventional environments into the cloud. Although not totally reprehensible, it does kill most of the benefits that users want to leverage when switching to the cloud.

Virtual environments in the cloud ideally have as little persistent data as possible. On one hand, admins can achieve this through a high degree of automation – preferably through orchestration, which every modern cloud offers. On the other hand, consistent implementation of a functional continuous integration/continuous delivery environment can create VMs or containers in a completely automated process.

In concrete terms, this means that if a VM or a container in a cloud has to be updated, an automatic process ideally creates a new VM or builds a new container that then replaces the old instance, almost without downtime; the admin does not need to worry about manually tracking the versions of individual systems.

It is also useful if a setup can be rebuilt out of the box in a few minutes by orchestration and automation, so that only the data (e.g., in a database) needs to be reloaded on completion. Such a system demonstrates effective, living, state-of-the-art security that helps eliminate problems caused by outdated software.

Use Firewalls

Of course, such a setup does not release the admin from keeping an eye on security basics. As on physical systems, it is a good idea in clouds to protect your own setup against attackers (e.g., by deploying firewalls). However, you need to keep in mind that networks in clouds work in a somewhat different way than in conventional setups. In clouds, the VMs or containers are never directly connected to the Internet.

To achieve the goal of central manageability and save resources, clouds instead use network nodes to redirect network traffic. Depending on the SDN setup, every node in a cloud can also be a network node and does not initially change the way traffic is redirected.

Conceivably, you could now store your firewall rules directly on the VMs, thus more or less working around the cloud. However, this choice deprives the admin of the API-controlled management tools that most clouds offer and instead requires establishing the corresponding firewall rules at the platform level.

In tech speak, this is normally known as a security group: Each virtual network port is connected to at least one security group, and for each group, the admin determines which access rules apply. The cloud then converts these rules into Netfilter instructions and enables them at the right place in the (physical) underlay.

Admins are well advised to build a functional security group configuration for their virtual environments once only and then convert it to a template for the platform's orchestrator (Figures 2 and 3) to allow the rules to be recycled at any time and even modified from the outside.

Figure 2: In clouds, security groups often control which packages make it to the VMs. The admin first creates a security group …

Figure 3: … and then provides it with concrete rules regarding the permitted connections.

Conveniently, if an attacker manages to break into the virtual environment, by whatever means, the firewall rules still apply. The attacker cannot open port 22 to the outside by deleting the corresponding Netfilter rule to gain access to the system by SSH.

How security groups can be used in AWS is explained in an Amazon document [6], and OpenStack provides a manual [7], as well.

The Trouble with IDSs

Some admins might be used to working with intrusion detection systems (IDSs) in their conventional setups. For the reasons mentioned above, however, these cannot usually be used ad hoc in a cloud. In a bare metal setup, admins usually configure IDSs so that one port on the switch mirrors and evaluates all the traffic from all the other ports. The traffic therefore does not pass through the IDS before it reaches the target systems.

Such a setup cannot be implemented in clouds because of the network nodes mentioned earlier: Users usually have no access to them. If users still want to operate an IDS in a cloud, they need to rely on the cooperation of their cloud providers. If you are using an SDN solution such as OpenContrail, you might be able to use virtual network functions (VNFs) in your own virtual environment. In practice, the user then stores an operating system image with the Suricata project administrator manager in the cloud's image store and then starts a VNF instance based on that Suricata image.

How VNFs are implemented differs greatly between the individual SDN implementations. What almost all environments have in common, however, is that direct access to the virtual packet router is not possible. A cloud provider that does not offer VNF functionality leaves the customer whistling in the wind.