How-To

Tighten the security of your OpenStack Clouds

A checklist for common threats from Stratoscale in this two-part tutorial.

June 17, 2016
image

OpenStack is by its nature a complex project, consisting of many independent sub projects. As OpenStack continues to gain momentum and while it matures, security is top priority for production.

In addition, new features are introduced every six months, carrying brand new vulnerabilities that are as yet undiscovered.Recently identified vulnerabilities in glibc and OpenSSL show that even a single component can render a whole system vulnerable. Taking into consideration the number of standard and new components in OpenStack, the attack surface can be quite extensive if the cloud is not deployed and maintained in the correct manner.

At the same time there are best practices and tools that can make the OpenStack cloud secure and compliant with industry regulations. We will begin by discussing the most common security threats to an OpenStack cloud. Then we will discuss threat mitigation tools and techniques, based on security best practices and recommendations to improve the security of an OpenStack cloud.

Security threats for an OpenStack cloud

To suggest mitigation tools and techniques we need to identify potential security threats and define possible attack vectors. Focusing specifically on software, it is common to define the following classes of security threats:

  • Spoofing – Pretending to be something or someone other than one’s true identity.
  • Tampering – Modifying something on disk, network or in memory.
  • Repudiation – Claiming that someone didnít do something, or was not responsible.
  • Information disclosure – Providing information to someone not authorized to see it.
  • Denial of service – Absorbing resources needed to provide a service.
  • Escalation of privileges – Allowing someone to do something they are not authorized to do.

Threats may come from outside, from a cloud provider or from another tenant, attacking both the cloud tenant and the cloud provider’s infrastructure. Here are the most common threats:

  • External threats – Attacker can use a vulnerability in the user’s VM to take a control of it, then move laterally to other VMs in the cloud until the attacker puts their hand on the crown jewels.
  • Threats from a cloud provider – Attacker can use a cloud misconfiguration for escalation of privileges or information disclosure. For example, an attacker can launch a new VM, and attach †a volume that was used by a previously running user VM to access sensitive user data.
  • Threats from another tenant – Attacker can, for example, run an escalation of privileges to escape their VM and take a control over the host and/or other tenants. Attacker can also get access to shared resources, such as storage or network resources.

Threat mitigation for OpenStack: General recommendations

Here is a recommended checklist to mitigate common security threats:

  • Spoofing mitigation:
    • Use public keys infrastructure (PKI) for authentication.
    • Use SSL/TLS for HTTP session protection, with trusted certificates.
    • Change the vendor’s default passwords in the node’s installation and for the cloud’s users.
    • Use OpenStack Keystone integration with LDAP/Active Directory for secure authentication, password policies and account security policies.
  • Tampering mitigation:
  • Repudiation mitigation:
    • Use logging and security audit.
    • Use centralized secure log management, send all of the log events as close to real-time as possible to the secure remote highly available SIEM system.
    • Monitor tenant networks for anomalies. The best practice is to use network-based Intrusion Detection and Prevention Systems (IDS/IPS) for known vulnerabilities and sandboxing systems for zero-day vulnerabilities.
  • Information disclosure mitigation:
    • Use storage encryption (OpenStack Cinder and libvirt both support volume encryption).
    • Use OpenStack permission, domains, tenants and groups to implement MAC/RBAC for user workloads.
  • Denial of service (DoS) mitigation:
    • Use quotas per domain, project and per user and implement OpenStack high availability best practices. HA architecture assumes redundancy, so you can safely isolate or shut down the affected instance and the remaining instances should be able to function normally.
    • Use OpenStack availability zones for physical isolation or redundancy.
    • HTTP reverse proxies for REST API endpoints and HTTP applications in the DMZ that can be used to isolate OpenStack services from a direct access. Each reverse proxy can be a Linux server with a minimal set of packages. Such a proxy can be easily maintained and also can be used as HTTP load balancer, HTTP accelerator (for encrypted connections) and security gateway to efficiently mitigate DoS/DDoS attacks.
  • Escalation of privileges mitigation:
    • Use SELinux/AppArmor to implement MAC/RBAC for hypervisors and OpenStack services.
    • Place OpenStack services into the DMZ, allowing access to API endpoints only.
  • Cloud tenant threat mitigation:
    • Use separated clouds for tenants, if necessary.
    • Use storage encryption per VM or per tenant.
    • OpenStack Nova has a Trusted Filter for Filter Scheduler to schedule workloads to trusted resources only (trusted computing pools), so workloads not requiring trusted execution can be scheduled on any node, depending on utilization, while workloads with a trusted execution requirement will be scheduled only to trusted nodes.
  • Cloud provider threat mitigation:
    • Monitor east-west (server to server) for anomalies.

Encrypt Your Cloud

OpenStack supports several cryptographic algorithms which can be used for identification and authorization, secure data transfer and data protection.
Refer to the OpenStack Security Guide for a list of recommended algorithms and implementation standards. Other recommendations for cryptographic algorithms include:

  • NIST recommendations for cipher suites and key management techniques
  • Salt for passwords – unique for each password, randomly generated
  • Elliptic curve cryptography (ECC) instead of RSA/DSA. ECC requires smaller keys to provide equivalent security, so ECC based algorithms are usually faster.
  • Use the Diffie-Hellman key exchange method for securely exchanging cryptographic keys over a public channel.

Host security

In addition to securing the virtual layers use the following checklist to ensure your OpenStack host physical security:

  • When possible, use FIPS 140-2 certified hardware.
  • Apply all the firmware security updates from hardware vendors. Recent discovery of the potential AMD security issue shows that even the CPU microcode can contain vulnerabilities.
  • Apply all the security updates from operating system vendor (after testing the updates on the staging environment).
  • Administrative functions should be restricted by the specified networks and workstations (administrators can connect only from the specified networks and from the specified workstations).
  • Use a strict change management process to apply any change to any server. Store all of the configuration versions, test all the changes on the staging environment, verify periodically system integrity (files) against the last applied configuration.
  • Use iptables per server to filter incoming and outgoing connections and protocols; use rate limit to perform simple throttling on incoming connections to services, like SSH.
  • Use restrictive SSH settings: use only recommended ciphers, disable SSH protocol version 1; allow only the specified users to use SSH, disable root login, disable authentication by passwords (use public key based authentication only), use chroot to lock down users to their home directories, etc.
  • Use SELinux/AppArmor as a security enhancement for GNU/Linux to implement mandatory access control (MAC).

In the second part of this tutorial, we will review security threat mitigation for specific OpenStack components.

This post first appeared on Stratoscale’s blog.

Superuser is always interested in how-tos and other contributions, please get in touch: [email protected]

[Cover Photo](https://www.flickr.com/photos/pensiero/3147660433/ // CC BY NC

Superuser
Latest posts by Superuser (see all)