Transcript MongoDB sharding and its Threats

MongoDB Sharding and its
Threats
By: Anam Zahid
MS(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 Partitioning
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)
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 GSSAPI
3) 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
{
user: ”[email protected]",
roles: ["readWrite"],
userSource: "$external"
}
1. I am “[email protected]”,
help me prove it to mongod
Key
(UDP:88)
2. Here is a Service Ticket
3. TCP:27017
Here is a
Kerberos
Service Ticket
Distribution
Center
5. Welcome,
here is Service
4. Keytab
Mongod
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
Gazzang Key
management
OS
Gazzang
File System – All contents encrypted
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/interprocess-authentication/
• http://api.mongodb.org/python/2.6.2/examples/
authentication.html
• https://securosis.com/assets/library/reports/Sec
uringBigData_FINAL.pdf
• http://docs.mongodb.org/manual/reference/user
-privileges/
• http://www.slideshare.net/DefconRussia/firstovattacking-mongo-db
23
24