Heartbleed security update

As many of you know, a serious vulnerability in the OpenSSL cryptographic software library was recently discovered: CVE-2014-0160. This vulnerability is commonly called the “Heartbleed Bug” and is described at http://heartbleed.com.

The Heartbleed vulnerability can be exploited by an attacker to gain access to the cryptographic keys used to secure communication between clients and servers using SSL, which includes most communication with web servers using HTTPS. Furthermore, this vulnerability can be used to access the system memory of running servers. As a result, an attacker can potentially listen to client-server traffic, steal passwords, and even hijack an HTTP session.

What actions are we taking?

On Monday we patched all services most vulnerable to attack and since then we have been carefully reviewing the less vulnerable components in our system and either patching or disabling them as appropriate.

  • We have patched all front-facing web services that talk over HTTPS to include the latest protected version of OpenSSL.

  • We have regenerated all SSL certificates used by MongoLab web servers, and we have revoked our old certificates.

  • We have reset all browser sessions active prior to the vulnerability.

  • We have reviewed the vulnerability of all database hosts and temporarily disabled any features that use the OpenSSL library. These services will remain disabled until they have been patched. Please note that your MongoDB servers are not using the affected library and that your database instances are not vulnerable to direct attack.

What actions should you be taking?

We have no evidence that any customer assets have been compromised. However, there are precautionary steps you should now take to ensure that your MongoLab account and MongoLab databases are as secure as possible:

(1) You should change all mongolab.com account user passwords and audit your list of MongoLab account users to ensure that all users in your MongoLab account are legitimate.

You can change your password on the User settings page which you can link to from the upper-right corner of the screen underneath the “Logout” button.

(2) You should re-generate all user API keys. We suggest you do this even if you have never used your MongoLab API key.

These API keys are per MongoLab user and can be regenerated on the same screen that you use to reset your password in step (1) above.

(3) You should reset all database credentials for all of the database deployments you have with MongoLab and audit the list of users in each database to ensure that all users are legitimate.

To manage database credentials, navigate to your database and click on the “Users” tab.

(4) If you are not using it already, you should enable 2-factor authentication (2FA) for your MongoLab account user.

Going forward

While we have closed all obvious attack vectors we will continue to respond to this threat by carefully reviewing all of our infrastructure and taking additional actions we deem necessary or prudent.

For updates please see our status page, which we will be keeping up-to-date.

Of course, if you have any questions or concerns please email us at support@mongolab.com.



MongoDB driver tips & tricks: Mongoose

Many of the support requests we get at MongoLab are questions about how to properly configure and use particular MongoDB drivers and client libraries.

This blog post is the 2nd of a series where we are covering the popular MongoDB drivers in depth (we covered Mongoid last time). The driver we’re covering today is Mongoose, which is maintained by Aaron Heckmann (@aaronheckmann) and officially supported by MongoDB, Inc. Continue Reading →

{ "comments": 1 }

MongoLab now manages over 100,000 databases! (102,280 to be exact)

We’re proud to announce that MongoLab is now powering over 100,000 cloud MongoDB databases in 23 datacenters worldwide! Continue Reading →

Finding duplicate keys with MongoDB’s aggregation framework

Quite frequently our users want to create a unique index on a data set but encounter some form of the following error because of duplicate key value(s):

E11000 duplicate key error index: db.collection.$field_1_field2_1  dup key: { : 1.0 : 1.0 }

While MongoDB supports an option to drop duplicates, dropDups, during index builds, this option forces the creation of a unique index by way of deleting data. If you use the dropDups option, MongoDB will create an index on the first occurrence of a value for a given key and then  delete all subsequent values. While this behavior may be acceptable in some cases, it’s important to be cautious whenever you are deleting data. Continue Reading →

MongoDB driver tips & tricks: Mongoid 3

Many of the support requests we get at MongoLab are questions about how to properly configure and use particular MongoDB drivers.

This blog post is the first of a series where we plan to cover each of the major MongoDB drivers in depth. The driver we’ll be covering today is Mongoid, developed by Durran Jordan (@modetojoy). Continue Reading →

{ "comments": 1 }

Future of MongoDB: Fireside chat with MongoDB CTO Eliot Horowitz

Last night I attended a Meetup at MongoDB Inc.’s new Palo Alto office to hear MongoDB’s CTO, Eliot Horowitz, speak about the product roadmap. With a new production release right around the corner and MongoDB World in the not-so-distant future, the buzz and excitement around all things MongoDB is high. For those who were not able to attend, we’re going to recap all the major points Eliot made.

Continue Reading →

{ "comments": 3 }

Finding and terminating long-running operations in MongoDB

When your MongoDB becomes unresponsive, it’s imperative that you can quickly identify the cause.

Although there can be many reasons for unresponsiveness, we sometimes find that particularly long-running and/or blocking operations (either initiated by a human or an application) are the culprit. Some examples of common operations that can bog down the database are:

  • operations on unindexed fields

  • index builds

  • expensive map-reduce jobs

One way to quickly see if one or more operations are particularly long-running is to use db.currentOp().

Continue Reading →

Managing disk space in MongoDB

In our previous post on MongoDB storage structure and dbStats metrics, we covered how MongoDB stores data and the differences between the dataSize, storageSize and fileSize metrics. We can now apply this knowledge to evaluate strategies for re-using MongoDB disk space.

When documents or collections are deleted, empty record blocks within data files arise. MongoDB attempts to reuse this space when possible, but it will never return this space to the file system. This behavior explains why fileSize never decreases despite deletes on a database.

If your app frequently deletes or if your fileSize is significantly larger than the size of your data plus indexes, you can use one of the methods below reclaim free space. Continue Reading →

{ "comments": 3 }