Misconfigured datastore services abound in the cloud
Are you configuring your cloud perimeter responsibly?
Cloud hosting provides great flexibility for your developers. They are lured to the cloud by promises of rapid deployments and order-of-magnitude decreases in maintenance costs. But this agility comes with security risks as new services are deployed without adequate safeguards for security and compliance.
Not only do improperly configured cloud environments pose a significant risk to your business by inadvertently exposing services and data on your cloud perimeter, flaws in these services can provide a safe haven for hackers to build out botnets or perform other malicious attacks. Indeed, a record-setting 1.3Tbps DDOS attack in February 2018 relied on the abundance of improperly secured Memcached servers to execute the attack.
Services exposed on cloud providers
For this post, we look at one of the many corners of the the internet that we track at Qadium: datastore services that appear on well-known cloud hosting providers. In addition to Memcached and its successor, Redis, we also investigate some popular NoSQL databases, namely Cassandra, CouchDB, and MongoDB. These modern datastore services power much of the web we know and love, which explains their popularity in the cloud.
Despite their popularity, these services have one concerning thing in common: they are not security-hardened for the public-facing internet. Indeed, the only safe cloud configuration of these services places them behind restrictive security groups or private VPCs — they should never be directly connected to the public internet.
The figure above shows the percentage of each cloud provider’s total IPv4 space that hosts a publicly accessible datastore service. The absolute numbers are astronomical: In March 2018, Qadium identified more than 75,000 total exposures of these services in the five cloud providers above.
Are default cloud deployments part of the problem?
Every provider we evaluated offers a large number of how-to articles — Hello World instructions — emphasizing how easy it is to deploy X service on their cloud. But when these articles gloss over important security details, it leads to a proliferation of risky perimeter exposures.
Qadium went through each cloud provider to find examples of lax policy related to the development services analyzed, and found that the “Hello World” example configurations for Redis on Azure and MongoDB on Google Cloud Platform create services that are public by default.
Azure & Redis
Azure offers Redis as a managed service, but appears to require a paid “Premium Azure Redis Cache” to block access from the public internet. For many developers on new projects, the lure of “free” gives them the ability to develop prototypes with minimal corporate friction, but in this case, it also means development with minimal security.
Indeed, a publicly addressable Redis instance appears to ignore Redis’ own security guide which explains that “Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet…”
Google & MongoDB
Google provides a number of guides to set up MongoDB on its infrastructure. But here, we again see a pattern of insecure-by-default configurations. While Google’s instructions do deploy MongoDB with Node.js warn users that this sets up MongoDB insecurely, our observations suggest that a large number of developers are not taking that warning seriously.
Once again, this quickstart goes against the best-practice advice from the MongoDB manual, which implores developers to “Ensure that MongoDB runs in a trusted network environment…”.
Amazon, SoftLayer, and Rackspace
We couldn’t find any evidence that the final three providers, Amazon, SoftLayer, and Rackspace offer insecure-default deployments. In fact, we often found the opposite. For example, Amazon’s instructions place Redis in a restrictive security group by default. Why do we still see so many exposures in all cloud providers for these services?
The answer likely lies in lack of awareness of the security risk. Developers connect to services directly during development, which is acceptable when the services are protected within a secure local network. In order to get the same access with cloud services, developers may open up access to the services to the entire internet without setting up appropriate network access controls.
In effect, this treats the global internet as a trusted local network — convenient for development, but the security costs of services like this on your cloud perimeter far outweigh any benefits.
What to do?
- Configure cloud services responsibly. The vast majority of networked services should never be seen on your perimeter, simply because the security of most internet protocols isn’t hardened enough for public environments. Redis, MongoDB, CouchDB, Cassandra, and Memcached are extreme examples of this — all risk data leakage when directly connected to the internet. Make sure services like these are configured behind a VPN and not inadvertently accessible on your cloud perimeter.
- Don’t expect your developers to figure out the right answer on their own. Configuring services securely is hard — especially new and trendy ones, where security isn’t emphasized. Don’t assume that cloud provider documentation will help your developers to create a secure configuration when they spin up a service. Provide your own documentation and best practice material, and over-communicate about the risks of misconfiguration.
- Use Qadium to avoid cloud perimeter surprises. The “Shadow Cloud” is bound to happen when companies empower non-security functions to procure technology — and even when they don’t. Qadium helps you define and secure your cloud perimeter, allowing you to quickly discover when services pop up, by hosting provider, as they are exposed. Use Qadium to bring your cloud perimeter back into compliance, get on top of any surprises, and craft and enforce best practices that truly protect your cloud perimeter.
