1. MongoDB Sharding and its Threats
By: Anam Zahid
MS(IT)-13

2. Agenda Sharding Components Sharding mechanics
MongoDB Sharding Security
Weaknesses
Identified Threats

3. Main components Shard Config Server (meta data storage) Mongos
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

4. Chunk is a section of the entire range
Chunk Partitioning
Chunk is a section of the entire range

5. Chunk is a section of the entire range
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)
Once chunk size is reached, mongos asks mongod to split a chunk
+ internal function called splitVector()
mongod counts number of documents on each side of split
+ based on avg. document size `db.stats()`
Chunk split is a **logical** operation (no data has moved)
Chunk is a section of the entire range

6. 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

7. 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” })
Balancer lock actually held on config server.

8. 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

9. Committing Migration
When complete, destination shard updates config server
Provides new locations of the chunks

10. 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

11. Sharding Mechanics

12. Sharding Security - Authentication
Password Authentication or MongoDB-CR
External Authentication
PLAIN SASL (Simple Authentication and Security Layer)
Kerberos Authentication using GSSAPI
X.509 Certificate based authentication
X.509 authentication for both user and intra-cluster authentication. 1 and 2 are supported in mongoDB enterprise only

13. 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

14. 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 and newer.

15. Kerberos Authentication
3. TCP:27017
Here is a
Kerberos
Service Ticket {
user:
roles: ["readWrite"],
userSource: "$external" }
Key Distribution Center
1. I am
help me prove it to mongod
(UDP:88)
2. Here is a Service Ticket
Mongod
5. Welcome, here is Service
4. Keytab

16. PLAIN SASL(Simple Authentication and Security Layer)
Proposed in RFC 4616
New in version 2.6.
MongoDB Enterprise Edition versions 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

17. 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)
readWrite on config. database necessary for some sharding admin tasks (like stopping/starting the balancer), currently role based per database authorization
UserAdmin – modify permissions and create new roles

18. Transmission Security
SSL encryption (with CA validation) used for inter- server (between servers) data transmission security
SSL (with CA validation) ensures that the hosts are who they say they are, but that’s separate from user authentication within MongoDB.

19. Data-at-rest Security
3rd Party Security Provider Gazzang’s ZnCrypt
File system Encryption
File System – All contents encrypted OS
Gazzang
Gazzang Key management

20. 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.
i-e rely on 3rd party tools for security (Gazzang Zncrypt)

21. 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

22. General Threats
Additionally, Weak Auditing facilities in MongoDB may also cause
Repudiation Attack
Default Open ports e.g 28017, 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

23. References

24. THANKS!!!