As times change so do the problems that we face. In today’s world we face the problems of ever changing datasets. When creating an application the schema that is used to contain our data is no longer fixed. Due to the rapidity of development, companies can’t wait weeks to complete the definition of how they want to store their data. Waiting a week or a month on your application or enhancement may spell disaster for your product. In some cases you want the flexibility to change how your data is stored and queried to get the most out of your data. Because of these challenges the NoSQL movement was born.
NoSQL is a technology that allows you to have non-fixed datasets when storing data into a database. The minimal need you want to solve by using NoSQL is the need for two or more items stored in a dataset to have different properties. An example would be if you wanted to store contact information such as name, address, and telephone number. What if you had users that had twitter, foursquare, or Facebook data that you wanted to store with your traditional contact data? In a traditional relational database you would need to preallocate all the fields that you need upfront. You can change your fields within a relational database but it may take an extreme amount of time to apply those changes to your database. This may cause downtime or loss of productivity. Because of this NoSQL was created. Because we have moved forward with NoSQL doesn’t mean that we leave traditional databases behind. If you’re using a fixed field dataset then odds are traditional databases still work for that application.
NoSQL databases are popular in the field of web applications and analytics. There are even a few different types of NoSQL systems as they accomplish different things. One example is an in memory database. This would include Redis or Memcache. These systems are used for high volume queries that need extremely low latency responses. Great uses for these systems are for things like trending lists on social networks or online games. They both need low latency access to a set of data. In the case of social networks such as Twitter tens of millions of people look at the top trends per day. A backend system performs analysis on the feed on incoming tweets and then posts the result of the analysis to the memory database. When users are looking to see what the hottest trends are they will access the memory store and then get a very fast response. This is much better than the usual query against a database. A database would need to spin up its disks, perform a calculation, and then return the data.
Because of the popularity of these databases and the fact that they are being used in a wide variety of applications, we naturally intersect with security risks. By default these databases do not use authentication. This would be the state if you downloaded the software and installed it yourself. Why not use authentication? Well the idea is accessibility toward developers. Ideally these databases are deployed in firewall secured locations or listening so only on server processes can talk to them. With the drive of cloud based services its possible to assemble an application of any scale very quickly. Sometimes in doing so developers may forget about the need for authentication.
Besides user data it’s common to store things such as session cookies or other application state data inside of these databases. In extreme examples an attacker could dump all of your session cookies and then use this to access a site with another users credentials. Other cases attackers used the NoSQL systems to store and serve malware.
The biggest issue here isn’t with the databases themselves but as with most security issues it has to deal with the humans configuring them. Below is a series of links on how to enable authentication on the various databases that I mentioned. Ideally you would want to limit access to the systems with a network firewall or perhaps server side firewalling. If the database’s port is open to the Internet odds are someone will attempt a brute force attack on the system to break in. This is common with any authenticated service (SSH, FTP, HTTP, etc.) let alone a service that provides the potential for very valuable data. There is even a module for Metasploit to brute force against a MongoDB host. There are other similar modules for scanning for Redis and other NoSQL systems.
When choosing to use any service you need to be aware of the implications of it. If your going to use a service to host data, the protocol or application is irrelevant, be aware of the risk if that data is made accessible. Because NoSQL systems are somewhat new to network security administrators its important to be aware of the potential risks of these services running in your network.
MongoDB: MongoDB Security
Redis: Redis Security
CouchDB: CouchDB Security
Memcache: Memcached Security
Discussing a wide range of topics impacting enterprises and data center security.