Featured

OpenStack Security: A Practical Guide

Here are a few severe vulnerabilities discovered in OpenStack over the past few years, codified as common vulnerability enumerations (CVEs).

October 4, 2022
image

What is OpenStack?

OpenStack is an open source software platform, originally developed in 2010, that allows organizations to build and maintain public and private clouds. OpenStack makes it possible to create cloud infrastructure with compute, storage, and networking components in an Infrastructure-as-a-Service (IaaS) model. It is designed for flexibility, massive scalability, and enterprise-grade security. 

OpenStack allows cloud operators to deploy virtual machines (VMs) that handle various cloud management tasks. It provides an infrastructure that allows cloud users to quickly and easily provision and deprovision cloud components and resources, with the ability to quickly scale resources up and down to match their current needs. All aspects of OpenStack can be accessed programmatically via APIs, to facilitate cloud automation.

Recent OpenStack Security Vulnerabilities

OpenStack is a mission critical system used to deploy enterprise resources at large scale. For this reason, it is a prime target for attackers. Because OpenStack projects are open source, attackers can study their code and discover vulnerabilities relatively easily. Here are a few severe vulnerabilities discovered in OpenStack over the past few years, codified as common vulnerability enumerations (CVEs).

Keep in mind that many more vulnerabilities exist, some of which may not have been discovered yet. The biggest danger is a new “zero day” vulnerability that could exist in your OpenStack deployment right now, unbeknownst to you or OpenStack contributors. This requires a proactive approach to securing applications in the OpenStack toolset, as I discuss in the following section.

CVE-2020-26943

This is an issue with the OpenStack blazar-dashboard component. Users who are granted access to Horizon’s Blazar dashboard can trigger code execution on the Horizon host, due to the use of the Python eval() function. This can result in unauthorized access to the Horizon host compromise of the Horizon service. The vulnerability affects all setups 

Affected versions: 1.3.1, 2.0.0, 3.0.0, and earlier

Affected setup: OpenStack users running the Horizon dashboard using the blazar-dashboard plugin. 

CVE-2021-20267

A flaw was found in the default Open vSwitch firewall rules for openstack-neutron. Anyone controlling a server instance connected to a virtual switch can send a carefully crafted packet and spoof the IPv6 address of another system on the network, causing denial of service (DoS). Another possibility is that traffic destined for other destinations may be intercepted by an attacker.

Affected versions: Openstack-neutron versions 15.3.3, 16.3.1, 17.1.1, and earlier.

Affected setup: Only deployments using the Open vSwitch driver.

CVE-2021-38598

Hardware address spoofing can occur when using the linuxbridge driver with ebtables-nft on Netfilter-based platforms. Anyone controlling a server instance connected to a virtual switch can send a carefully crafted packet and spoof the hardware address of another system on the network. This can result in a denial of service (DoS) or, in some cases, interception of traffic intended for another destination.

Affected versions: Openstack-neutron versions prior to 16.4.1, 17.x before 17.1.3, 18.x before 18.1.1.

Affected setup: Linuxbridge driver with ebtables-nft on Netfilter-based platforms.

CVE-2021-40797

A problem was found in the routing middleware for openStack-neutron. Authenticated users can make API requests that include non-existent controllers, which can cause API workers to consume excessive memory, resulting in poor API performance or denial of service.

Affected versions: Openstack-neutron versions prior to 16.4.1, 17.x before 17.2.1, 18.x before 18.1.1.

Affected setup: OpenStack-neutron.

CVE-2022-23452

An authentication flaw was found in openstack-barbican. This vulnerability could allow anyone with an admin role to add a secret to another project container. This vulnerability could allow an attacker on the network to consume protected resources and cause denial of service.

Affected versions: Openstack-barbican up to and excluding version 14.0.0.

Affected setup: Using the openstack-barbican secrets management REST API

OpenStack Security: 4 Critical Best Practices

1. OpenStack Authentication

Authentication is critical in a production OpenStack deployment. The OpenStack identity service, Keystone, supports multiple authentication methods, including username and password, LDAP, and external authentication methods. Upon successful authentication, the identity service provides the user with an authentication token for subsequent service requests.

Transport Layer Security (TLS) uses X.509 certificates to enable authentication between service accounts and human users. The default mode of TLS is for server-side authentication only, but certificates can also be used for client-side authentication.

Use multi-factor authentication for privileged user accounts accessing cloud networks. The identity service also supports external authentication services through the Apache web server. Servers deployed in OpenStack can also use certificates to enforce client authentication.

By using strong authentication, you can protect cloud users from brute force attacks, social engineering, phishing attacks, account takeover, and many other cyber threats.

2. OpenStack Backup and Recovery

In a cloud deployment, machines eventually become outdated, software needs upgrading, and vulnerabilities are discovered. There must be a convenient way to apply changes to the software or make changes to the configuration.

Backup and recovery is an important part of an OpenStack security strategy. To keep backups secure, ensure only authenticated users and authorized backup clients can access the backup server, and always store and transmit backups with data encryption options.

Use a dedicated, hardened backup server. Backup server logs should be monitored daily and should be accessible only to a small number of people.

Finally, test data recovery regularly. In case of a security compromise, a good way to recover operations is to terminate running instances and restore them from images stored in a protected backup repository.

3. Secure OpenStack API Endpoints

Any process using the OpenStack cloud starts by querying the API endpoint, making API security a key challenge for OpenStack deployments. Although public and private endpoints present different challenges, they are both high-value assets that can pose significant risks if compromised. 

You can force specific services to use specific API endpoints. Any OpenStack service that communicates with the APIs of other services must be explicitly configured to access the appropriate internal API endpoints, and should not have access to other endpoints.

API endpoint processes should be isolated. It is especially important to isolate any API endpoint that is in the public domain. If possible, API endpoints should be deployed on different hosts for greater isolation.

4. Forensics and Incident Response

Log generation and collection are important components for securely monitoring an OpenStack infrastructure. Logs provide visibility into the day-to-day operations of administrators, tenants, and guests, as well as the activity of compute, networking, storage, and other cloud components.

Logs are important for proactive security and ongoing compliance efforts, and provide a valuable source of information for incident investigation and response. For example, analyzing access logs for identity services or external authentication systems can alert you to login failures, their frequency, the source IP, and the context in which anomalous access request occured.

Identifying these types of anomalous events makes it possible to identify and respond to security incidents. You can then take action to mitigate potentially malicious activity, such as blocking IP addresses, recommending stronger user passwords, or disabling dormant user accounts.

Here are some important considerations when implementing log aggregation and analysis:

  • Have a way to detect that no logs are being generated—this indicates service failure or an intruder hiding the trace by temporarily turning off logging or changing the log level.
  • Gain visibility over application events—in particular, unplanned start and stop events should be monitored and investigated for possible security impacts.
  • Monitor operating system events—any OpenStack service system should be monitored for events like user logins and reboots. These provide insights into security issues and also misconfiguration or incorrect system usage.
  • Detect high load—if the logs indicate high load on a management component, deploy additional servers for load balancing to ensure high availability.
  • Other actionable events—watch for other important events such as bridge failures, refreshes of compute node iptables, and unreachable cloud instances which can impact end user experience.

Conclusion

In this article, I covered some of the major vulnerabilities discovered in OpenStack project in recent years, and provided several best practices that can help you take a proactive approach to OpenStack security and prevent the next attack:

  • OpenStack authentication—implement strong authentication for OpenStack services using TLS and multi-factor authentication.
  • OpenStack backup and recovery—use a dedicated, hardened backup server for your critical OpenStack components.
  • Secure openStack API endpoints—isolate API endpoints as much as possible and ensure that OpenStack service can only access endpoints they are explicitly allowed to use.
  • Forensics and incident response—ensure you can collect, visualize, and act on logs from OpenStack systems to identify security incidents.

I hope this will be useful as you improve the security posture of your OpenStack deployments.

Tags: ,

Sagar Nangare
Latest posts by Sagar Nangare (see all)