This past week, a widely-reported ransomware attack was carried out against tens of thousands of MongoDB databases, and the attackers also targeted several hundred Elasticsearch instances for good measure. Those affected were given a distressing ultimatum: pay Bitcoin to the attackers, or have their data deleted. To add further insult, many who paid the ransom did not even receive their data in return.If you’re a Bonsai customer, rest assured: your clusters are perfectly safe.This particular attack targeted databases that are open to the internet, and totally unsecured. Attackers would crawl public IP addresses en masse in order to find such services. By automating the collection, probing, and attack of MongoDB and Elasticsearch instances, hackers were able to ransom a significant amount of data in a very short amount of time.As anyone with a public-facing SSH service on port 22 can attest, this kind of attack is not uncommon. With services that can automate the scanning of the entire IPv4 space, managing the security of your data is an ongoing concern for anyone hosting such services. And, unfortunately, most people are not particularly great at this kind of operational security.At Bonsai, it’s our job to anticipate these kinds of problems, and make opinionated architectural design decisions to help prevent them. Here’s a small sample:
- All Bonsai clusters are protected with HTTP authentication by default. These credentials are randomly generated, making them resistant to dictionary attacks or password reuse between services. All traffic to your cluster must have correct credentials, or it will be rejected with an HTTP 401 error. This protects against unauthorized access, including the kind of data exfiltration and modification used in this kind of attack.
- Furthermore, we support secure TLS encryption by default for all clusters. This helps to further ensure the safety and security of your credentials by transmitting them over a secure channel. Granted, MITM and packet sniffing techniques weren’t used in this attack, but good security is designed in layers.
- Bonsai cluster URLs have a randomly-generated hostname, and are routed through a specially designed layer 7 proxy, custom built for routing and load balancing Elasticsearch cluster traffic. This all but eliminates scanning by inflating the search space to an impractically large size. Your unique cluster URL is one of trillions of possibilities, and even if someone were to guess it perfectly, they can’t get any further without guessing the password.
We have also previously published a detailed blog entry covering a few other tidbits about how we handle security for Elasticsearch, if you’re interested in some light reading on the subject.This most recent attack underscores that one of the most important thing our users can do to protect their data is to treat the cluster URL like a password. It’s sensitive information and access to it should follow the principal of least privilege. Also, we provide the option of rotating the randomly-generated credentials, which users should do regularly (and especially if there is reason to suspect that their full URL has been leaked). For detailed information about your cluster URL, see our thorough documentation here:
We take security very seriously and are constantly monitoring for and responding to potential threats. It would be much easier to design an architecture that pushed some of these decisions onto our customers. But we know that our customers appreciate our service because of the opinionated expertise that we integrate directly into our systems. We take every precaution and are opinionated about our infrastructure as a result.Hopefully you’ve found this insightful! Both for a few specific design points and policies, as well as for the overall sense of responsibility and design philosophy with which we approach the design of our service.If you ever have any concerns or questions about how we’re keeping your data safe, or what you can do to beef up your own security, please don’t hesitate to reach out!
