NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



NoSQL security: All content tagged as NoSQL security in NoSQL databases and polyglot persistence

Why NoSQL Equals NoSecurity

If it seems that security is an afterthought in the big data ecosystem, you’re right. And that’s unfortunate, because attackers go where the data is. Our security surveys consistently show that even conventional structured databases aren’t protected as well as they should be. And now we’re piling up unstructured data.

Security is an issue in the NoSQL space, but don’t claim to offer solutions just to get some registrations and sell the services of a security consulting firm.

Update: the Hacker News thread1

  1. Security experts abound on comment sites like Hacker News or Reddit. 

Original title and link: Why NoSQL Equals NoSecurity (NoSQL database©myNoSQL)


CouchDB 1.2.0: Performance, Security, API, Core and Replication Improvements

CouchDB 1.2.0 was released on April 6th. The linked post provides all the details of the new version, but here are some important improvements included with the new release:

  • Performance: added a native JSON parser
  • Performance: optional file compression for database and view index files
  • Performance: a new replicator implementation. More reliable, faster, configurable.
  • Security: the _users database and information in the _replication databases are not longer readable by everyone
  • Core: added support for automatic compaction. Automatic compaction is off by default, but can be enabed through Futon or the .ini file and configured to run based on multiple variables:
    • A threshold for the file_size to disk_size ratio (say 70%)
    • A time window specified in hours and minutes (e.g 01:00-05:00)
    • Compaction can be cancelled if it exceeds the closing time.
    • Compaction for views and databases can be set to run in parallel
    • If there’s not enough space (2 × data_size) on the disk to complete a compaction, an error is logged and the compaction is not started.

Original title and link: CouchDB 1.2.0: Performance, Security, API, Core and Replication Improvements (NoSQL database©myNoSQL)


Authorization and Authentication in Hadoop

Everything from authentication to authorization at HDFS, MapReduce, NameNode and JobTacker level explained:

In the context of MapReduce, the users and groups are used to determine who is allowed to submit or modify jobs. In MapReduce, jobs are submitted via queues controlled by the scheduler. Administrators can define who is allowed to submit jobs to particular queues via MapReduce ACLs. These ACLs can also be defined on a job-by-job basis. Similar to the HDFS permissions, if the specified users or groups don’t exist, the queues will be unusable, except by superusers, who are always authorized to submit or modify jobs. […]

When a user runs a hadoop command, the NameNode or JobTracker gets some information about the user running that command. Most importantly, it knows the username of the user. The daemons then use that username to determine what groups the user belongs to. This is done through the use of a pluggable interface, which has the ability to take a username and map it to a set of groups that the user belongs to.

Original title and link: Authorization and Authentication in Hadoop (NoSQL database©myNoSQL)


Data Encryption for Hadoop and NoSQL Databases From Gazzang

The Gazzang Encryption Platform for Big Data works as a last line of defense for protecting data within Hadoop, Cassandra and MongoDB, non-relational, distributed and horizontally scalable data stores that have become common management tools for big data initiatives.

Sounds good so far. But then:

Gazzang today launched a cloud-based encryption […] The Encryption Platform transparently encrypts and secures data “on the fly,” whether in the cloud or on premises, ensuring there is minimal performance lag in the encryption or decryption process.

Anyone having any idea how a cloud-based solution could encrypt/decrypt on premises data on the fly? I don’t.

Original title and link: Data Encryption for Hadoop and NoSQL Databases From Gazzang (NoSQL database©myNoSQL)


NoSQL Security: Installing and Hardening Redis

Many useful pieces of advice—from the very basics to renaming commands—in Marc Wickenden post about securing Redis:

Redis doesn’t have much in the way of security so I knew that anyone who managed to pop the box could theoretically connect to the local Redis instance and mess around. I’ll take you through the steps I took to install and harden Redis, on a Debian Squeeze GNU/Linux box.


Original title and link: NoSQL Security: Installing and Hardening Redis (NoSQL database©myNoSQL)


CouchDB in Node Package Manager Exposed Password Hashes

The security alert:

  • Your password wasn’t leaked, but the hash was. Still not great.
  • It’s fixed now.

The root problem?

To do login, npm uses the /_users database in couchdb. By default, CouchDB prior to version 1.2.0 makes this database world-readable.

Yet another problem

Latest stable CouchDB release is 1.1.1. And you’ll probably find some more nasty comments in the Hacker News thread.


Captured by Klint Finley from Jan Lehnardt:

For those not ready to upgrade to 1.2.0 CouchDB developer Jan Lehnardt suggests restricting access to /_users with a proxy.


  1. Klint Finley:

    The good news of course is that the CouchDB is changing this default behavior. The bad news is that it took this long for the problem with NPM to be noticed and fixed.

  2. Me: the very bad news is that security is still an after-thought for many NoSQL databases.

Original title and link: CouchDB in Node Package Manager Exposed Password Hashes (NoSQL database©myNoSQL)

NoSQL Databases and Security: Cassandra and MongoDB Security Reviewed

Herman Stevens summarizes the findings of the paper “Security Issues in NoSQL Databases”:

The paper itself concluded that the main problems to both Cassandra and MongoDB are “the lack of encryption support for the data files, weak authentication both between the client and the servers and between server members, very simple authorization without support for RBAC or fine-grained authorization, and vulnerability to SQL Injection and Denial of Service attacks”

Cassandra security reviewed

Cassandra security

MongoDB security reviewed

MongoDB security

Even without the findings of Attacking NoSQL and Node.js: Server-Side JavaScript Injection (SSJS) things might be scary.

Original title and link: NoSQL Databases and Security: Cassandra and MongoDB Security Reviewed (NoSQL database©myNoSQL)


Nmap Scripts for Riak, Redis, Memcached

If you take a look at the topic of security in the NoSQL context, you’ll notice that things are far from being perfect. So, any contributions in this area are welcome. Patrik Karlsoon added a couple of network exploration Nmap scripts for Riak, Redis, and Memcached. And while these will not help much with security they might proove useful for managing your NoSQL deployments:

  • Added the script riak-http-info that lists version and statistics information from the Basho Riak distributed database.

  • Added the script memcached-info that lists version and statistics information from the distributed memory object caching service memcached

  • Added the script redis-info that lists version and statistic information gathered from the Redis network key-value store.

  • Added the redis library and the script redis-brute that performs brute force password guessing against the Redis network key-value store.

Original title and link: Nmap Scripts for Riak, Redis, Memcached (NoSQL database©myNoSQL)

Attacking NoSQL and Node.js: Server-Side JavaScript Injection (SSJS)

Jeff Darcy has written a while back about the (lack of) security in NoSQL database. Unfortunately things haven’t changed much and if you check the NoSQL + Node.js applications I’ve posted lately you’ll notice that some of them are completely ignoring security.

And there are some people realizing the risks and starting to express their concerns:

Playing with MongoDB lately, I’m getting scared. Because I’m seeing some really bad practices out there. Seeing it in live code. In tutorials.

Bryan Sullivan (Senior Security Researcher, Adobe Secure Software Engineering Team) has published a paper (PDF) explaining some of the possible server-side JavaScript injection attacks and the risks the apps and the data are exposed to. Teaser: he can do pretty much everything.

It should be noted that exploitation of server-side JavaScript injection vulnerabilities is more like that of SQL injection than of cross-site scripting. SSJS injection does not require any social engineering of an intermediate victim user the way that reflected XSS or DOM-based XSS do; instead, the attacker can attack the application directly with arbitrarily created HTTP requests.

Because of this, defenses against SSJS injection are also similar to SQL injection defenses:

  • Avoid creating “ad-hoc” JavaScript commands by concatenating script with user input.
  • Validate user input used in SSJS commands with regular expressions.
  • Avoid use of the JavaScript eval command. In particular, when parsing JSON input, use a safer alternative such as JSON.parse.

Remember there’s no such thing as security through obscurity.

Original title and link: Attacking NoSQL and Node.js: Server-Side JavaScript Injection (SSJS) (NoSQL database©myNoSQL)

Hadoop Security Explained

Brilliant article:

In nutshell, Hadoop has strong support for authentication and authorization. On the other hand privacy and data integrity is optionally supported when Hadoop services are accessed through RPC and HTTP, while the actual HDFS blocks are transferred unencrypted. Hadoop assumes network involved in HDFS block transfer is secure and not publicly accessible for sniffing, which is not a bad assumption for private enterprise network.

Original title and link: Hadoop Security Explained (NoSQL database©myNoSQL)


Securing MongoDB

So, MongoDB presented us with two problems:

  • When sharding it, we can’t even use the basic security that it supports.
  • The basic security that it offers is not reasonable for allowing external servers to connect to MongoDB.

Let’s just review:

  • you have this sharding setup: MongoDB sharding

  • on top of that add some Nginx

  • switch from using a binary protocol to HTTP

Doesn’t sound easy or out of the box anymore.

Original title and link: Securing MongoDB (NoSQL databases © myNoSQL)

Secure HBase

A short presentation about HBase access control security

Original title and link: Secure HBase (NoSQL databases © myNoSQL)