MongoDB Sharding and its Threats

MongoDB Sharding and its Threats

By: Anam ZahidMS(IT)-13

Agenda

• Sharding Components• Sharding mechanics• MongoDB Sharding Security• Weaknesses• Identified Threats

2

Main components• Shard– A Shard is a node of the cluster– Each Shard can be a single mongod or a replica set

• Config Server (meta data storage)– Stores cluster chunk ranges and locations– Can be only 1 or 3 (production must have 3)– Not a replica set

• Mongos – Acts as a router / balancer– No local data (persists to config database)– Can be 1 or many

3

Chunk is a section of the entire range

Chunk Partitioning

Chunk splitting

• A chunk is split once it exceeds the maximum size• There is no split point if all documents have the same shard

key• Chunk split is a logical operation (no data is moved)

Chunk is a section of the entire range

Balancing

• Balancer is running on mongos• Once the difference in chunks between the most dense

shard and the least dense shard is above the migration threshold, a balancing round starts

Acquiring the Balancer Lock

• The balancer on mongos takes out a “balancer lock”• To see the status of these locks:

use config

db.locks.find({ _id: “balancer” })

Moving the chunk

• The mongos sends a moveChunk command to source shard• The source shard then notifies destination shard• Destination shard starts pulling documents from source shard

Committing Migration

• When complete, destination shard updates config server- Provides new locations of the chunks

Cleanup

• Source shard deletes moved data- Must wait for open cursors to either close or time out

• The mongos releases the balancer lock after old chunks are deleted

Sharding Mechanics

11

Sharding Security - Authentication

• Password Authentication or MongoDB-CR• External Authentication

1) PLAIN SASL (Simple Authentication and Security Layer)

2) Kerberos Authentication using GSSAPI3) X.509 Certificate based authentication

12

MongoDB-CR

• Intra-Cluster authentication still use MongoDB-CR by using keyfile option

• Keyfile act as a shared password• Same keyfile for all members of a cluster

(including mongod and mongos) • A Keyfile contains random characters in

base64 set

13

SSL with X509 Certificate based Authentication

• The MONGODB-X509 mechanism authenticates a username derived from the distinguished subject name of the X.509 certificate presented by the driver during SSL negotiation. This authentication method requires the use of SSL connections with certificate validation and is available in MongoDB 2.5.1 and newer.

14

Kerberos Authentication

3. TCP:27017Here is a KerberosService Ticket

{ user: ”username@EXAMPLE.COM", roles: ["readWrite"], userSource: "$external"} Key

Distribution Center

Key Distribution

Center

1. I am “username@EXAMPLE.COM”, help me prove it to mongod(UDP:88)

2. Here is a Service Ticket

MongodMongod

5. Welcome, here is Service

4. Keytab

15

PLAIN SASL(Simple Authentication and Security Layer)

• Proposed in RFC 4616• New in version 2.6.• MongoDB Enterprise Edition versions 2.5.0 and

newer support the SASL PLAIN authentication mechanism, initially intended for delegating authentication to an LDAP (Lightweight Directory Access Protocol) server.

• MongoDB Enterprise for Windows does not include LDAP support for authentication

16

Sharding Security - Authorization• MongoDB System defined Access Control Roles

– read– readWrite– dbAdmin (clean, create, drop database etc)– userAdmin (for a single database)– readAnyDatabase– readWriteAnyDatabase– dbAdminAnyDatabase– userAdminAnyDatabase (for all databases)– clusterAdmin (no access to config. database but

have only access to admin database)

17

Transmission Security

• SSL encryption (with CA validation) used for inter- server (between servers) data transmission security

18

Data-at-rest Security

• 3rd Party Security Provider Gazzang’s ZnCrypt• File system Encryption

File System – All contents encryptedFile System – All contents encrypted

OSOS GazzangGazzang

Gazzang Key managementGazzang Key management

19

Security Weaknesses• No Field level Access control• No Strong internal security (e.g. MongoDB-CR is still used for intra-cluster

authentication)• No data integrity check• Need application firewall for egress and ingress filtering of incoming

connections within a sharded cluster

Other Weaknesses• No separate Audit log• Database level locking support only• Mongod audit logs only contains write operations with no mappings of

these operations against user_id . This is because mongods are unaware of their data users in sharded environments.

20

Threats• Malicious insider threat

– A malicious person injects its own shard in sharded cluster– All Credentials for databases other than the admin database reside in

the mongod instance that is the primary shard for that database.– Readwrite access on config database is needed to add shards, once

permitted a malicious user may access all collections in config database

• Man in the middle attack– Can occur due to sending of plain data during transmission as SSL is not

enabled by default in mongoDB.– PLAIN SASL mechanism send passwords in PLAIN text format to the LDAP

server– Intra-cluster authentication still uses KeyFile and does not support

Kerberos authentication

21

General Threats• Additionally, Weak Auditing facilities in MongoDB may also cause

– Repudiation Attack• Default Open ports e.g 28017, 27017 etc can cause

– Port scan attack– Dos Attack

• Weak validation of input in MongoDB REST API can cause– Cross Site Request Forgery (CSRF)

• Weak validation of input in PHP driver can results in– NoSQL Injection

• Flaws in Rest API allows– Stored Cross Side Scripting (XSS) Attack

22

References• http://docs.mongodb.org/manual/core/inter-

process-authentication/• http://api.mongodb.org/python/2.6.2/

examples/authentication.html• https://securosis.com/assets/library/reports/

SecuringBigData_FINAL.pdf• http://docs.mongodb.org/manual/reference/

user-privileges/• http://www.slideshare.net/DefconRussia/firstov-

attacking-mongo-db

23

24