Webinar slides: How to Secure MongoDB with ClusterControl

Your host & some logisticsI'm Jean-Jérôme from the Severalnines Team and I'm

your host for today's webinar!

Feel free to ask any questions in the Questions section of this application or via the Chat box.

You can also contact me directly via the chat box or via email: [email protected] during or after the webinar.

About Severalnines and ClusterControl

What we do

Manage Scale

Monitor Deploy

ClusterControl Automation & Management

☐ Provisioning☐ Deploy a cluster in minutes☐ On-premises or in the cloud

(AWS)☐ Monitoring

☐ Systems view☐ 1sec resolution☐ DB / OS stats & performance

advisors☐ Configurable dashboards☐ Query Analyzer☐ Real-time / historical

☐ Management☐ Multi cluster/data-center☐ Automate repair/recovery☐ Database upgrades☐ Backups☐ Configuration management☐ Cloning ☐ One-click scaling

Supported Databases

Customers

MongoDB Security

How to Secure MongoDB (with ClusterControl)

Art van Scheppingen, Senior Support Engineer

Agenda

☐ What is the MongoDB ransom hack?☐ What other security threats are valid for MongoDB?☐ How to secure MongoDB from ransomware☐ Try to hack yourself☐ ClusterControl MongoDB security advisors☐ Live Demo

What is the MongoDB ransom hack?

What is the news about?

☐ 40,000 public MongoDB servers found vulnerable in 2015☐ Any user is admin☐ Discovery by the University of Saarland in Germany

☐ Nothing happened for almost two years☐ Someone rediscovers the vulnerability and hijacks servers

What is this vulnerability exactly?

☐ Default binding to every network interface (0.0.0.0)☐ From MongoDB 3.0 onwards, changed to 127.0.0.1☐ Often changed by a sysadmin/dba/devops in multi tenant env

☐ Default ports☐ 27017 / 27018 / 27019

☐ Authentication and authorization disabled by default☐ With authentication disabled, anyone is admin

☐ Exposed publicly on (cloud) hosts without firewall rules

What is this ransomware then?

☐ December 2016 ransomware emerged☐ Scripted approach☐ Copies all your data☐ Removes all databases / collections☐ Creates a WARNING collection containing:

{ "_id" : ObjectId("5859a0370b8e49f123fcc7da"), "mail" : "<[email protected]>", "note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !"}

☐ Even if you pay, you most likely never see your data back!

Is MongoDB at fault here?

☐ Default behaviour☐ Well documented default settings☐ Deliberately exposed by users with MongoDB 3.0 onwards☐ MongoDB security guide certainly not followed up

☐ Is MongoDB at fault here?

Who is targeted by the ransomware?

☐ MongoDB instances with a combination of this:☐ Bound to a public interface☐ Bound to a default port☐ No (or weak) authentication enabled☐ No firewall rules or security groups in place

☐ Ransomware scans hosts for (default) ports that respond☐ Identifies MongoDB instances

Have people secured their MongoDB servers by now?

Other vulnerabilities

HTTP interface

☐ Generally runs on MongoDB port + 1000 (e.g. 28017)☐ HTTP status interface

☐ Operational data☐ Logs☐ Status reports

☐ REST interface☐ Allows sending commands☐ Allows receiving data

☐ HTTP interface has been deprecated in MongoDB 3.2

Serverside Javascript

☐ Generally useful for mapReduce operations ☐ May be vulnerable to command injections and buffer overflows

db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } );

☐ Segfaults can cause a denial of service

MongoDB wire protocol

☐ Buildinfo responds with the MongoDB version☐ Necessary for determining SCRAM-SHA-1 compatibility

☐ Version specific vulnerabilities may be targeted this way☐ LDAP authentication vulnerability (SERVER-20691) up to 3.0.6☐ Denial of Service (SERVER-17521) in 3.0.0☐ No critical vulnerabilities for current versions

☐ https://www.mongodb.com/alerts/

https://jira.mongodb.org/browse/SERVER-20691

https://jira.mongodb.org/browse/SERVER-17521

Excessive rights

☐ Roles/users are stored in the database you connect to☐ Local users with userAdmin role

☐ Able to grant admin role to any database they have rights to

☐ Normally you can’t bypass local authentication☐ Except when you authenticate command line

[user@server ~]$ mongo -u user -p pass --authenticationDatabase test

☐ Or switch databases after authentication

Excessive rights (2)[user@server ~]$ mongo -u admin -p admin test mongodb_0:PRIMARY> db.createUser({ user: "user", pwd: "pass", roles: [ { role: "readWrite", db: "test" }, { role: "userAdmin", db: "test" } { role: "userAdmin", db: "exploited" } ]})

[user@server ~]$ mongo -u user -p pass --authenticationDatabase testmongodb_0:PRIMARY> db.createUser({ user: "exploit", pwd: "pass", roles: [ { role: "readWrite", db: "exploited" }, { role: "dbAdmin", db: "exploited" } ]})

[user@server ~]$ mongo -u exploit -p pass --authenticationDatabase test exploitedmongodb_0:PRIMARY>

How to secure MongoDB from ransomware

1. Enabling authentication

☐ Explicitly enabled in the /etc/mongod.confsecurity: Authentication: on

☐ Implicitly enabled in the /etc/mongod.confsecurity: keyFile: /etc/mongo-cluster.key

☐ Don’t forget to create an admin account first!

2. Don’t use weak passwords

☐ Enabling authentication will not give 100% protection☐ Brute force user / password combinations

☐ Easy to guess users / passwords☐ Scripts can brute force thousands of combinations remotely☐ Brute force tools are readily available

3. Authorization users by roles

☐ Better create a user per role☐ Don’t hand out excessive rights☐ ClusterControl will create a separate admin and backup user

4. Add a replication keyfile

☐ New secondaries can join freely☐ Only possible from primary with clusterManager or admin role

☐ Without a keyfile any host can join a replicaSet☐ Keyfiles are not publicly exposed

☐ Enabling replication keyfile will implicitly enable authentication

☐ Replication keyfiles are enabled by default in ClusterControl

5. Make backups regularly

☐ Ensure to make backups regularly!☐ In case someone is still able to hack your system

☐ Point in time recovery through the oplog☐ Oplog can’t be controlled/tampered with remotely

☐ ClusterControl has a great backup interface☐ (Shard) consistent backups

6. Run MongoDB on a non-standard port

☐ MongoDB default ports are well known to attackers☐ Setting non-standard ports may deflect fixed port scanners☐ One line change in the /etc/mongod.conf

net: port: 17027

☐ ClusterControl allows port customization during deploy time☐ Post deploy: configuration change (from UI) and restart required

7. Does your application require public access?

☐ Publicly available when MongoDB is bound to all interfaces☐ Does your application only need access via localhost?☐ Default setting in /etc/mongod.conf

net: bindIp: 127.0.0.1

7. Does your application require public access?

☐ Hosting and cloud environments may require separation☐ Ensure data gets transmitted via private (internal) network

net: bindIp: 127.0.0.1,172.16.1.234

8. Enable firewall rules or security groups

☐ Enable firewall rule or security groups☐ Even if the host is on a private network☐ Attackers may also come from the inside☐ Compromised web server as jumpbox

☐ Limit access only to hosts that really need to connect

9. Disable serverside Javascript

☐ If you don’t need it, you can disable it:

security: javascriptEnabled: False

10. Disable http interface

☐ Deprecated from MongoDB 3.2 onwards☐ If you don’t need it, you can disable it:

net: http: enabled: False RESTInterfaceEnabled: False

Enable audit logging

☐ Enable the audit log, when possible☐ MongoDB Enterprise☐ Percona Server MongoDB

☐ Scan for unexpected behaviour:auditLog: destination: file format: BSON path: /var/lib/mongodb/auditLog.bson filter: '{ atype: { $in: [ "dropCollection", "dropDatabase", "dropIndexes", "renameCollection" ] } }'

Try to hack yourself

Check for external connectivity

☐ Use an external box (any AWS box would suffice)☐ Try to telnet to your hosttelnet your.host.com 27017

☐ A response indicates MongoDB ports are openTrying your.host.com...Connected to your.host.com.Escape character is '^]'.

Check for external connectivity (3)

☐ MongoDB port closed: (properly firewalled)Starting Nmap 6.40 ( http://nmap.org ) at 2017-01-16 14:37 UTCNmap scan report for 10.10.22.17Host is up (0.00013s latency).PORT STATE SERVICE27017/tcp closed unknown

☐ Authentication enabled, but port still open:Starting Nmap 6.40 ( http://nmap.org ) at 2017-01-16 14:36 UTCNmap scan report for 10.10.22.17Host is up (0.00031s latency).PORT STATE SERVICE27017/tcp open mongodb| mongodb-databases:| code = 13| ok = 0|_ errmsg = not authorized on admin to execute command { listDatabases: 1.0 }

☐ MongoDB build information:[you@host ~]$ nmap -p 27017 --script mongodb-info 10.10.22.17 Starting Nmap 6.40 ( http://nmap.org ) at 2017-01-16 14:37 UTCNmap scan report for 10.10.22.17Host is up (0.00078s latency).PORT STATE SERVICE27017/tcp open mongodb| mongodb-info:| MongoDB Build info| javascriptEngine = mozjs| buildEnvironment| distmod =| target_arch = x86_64…| openssl| running = OpenSSL 1.0.1e-fips 11 Feb 2013| compiled = OpenSSL 1.0.1e-fips 11 Feb 2013| versionArray| 1 = 2| 2 = 11| 3 = -100| 0 = 3| version = 3.2.10-3.0…| Server status| errmsg = not authorized on test to execute command { serverStatus: 1.0 }| code = 13|_ ok = 0

Check for excessive privileges

☐ MongoDB authenticates against the database you connect to☐ Additional rights to other databases may be defined☐ Connect command line with the authenticationDatabase☐ Also switching databases will not re-authenticate

use mydatastoredb.createUser( { user: "user", pwd: "password", roles: [ { role: "readWrite", db: "mysdatastore" }, { role: "readWrite", db: "admin" } ] });

☐ Notice the additional rights on the admin database!

Check for excessive privileges (2)

☐ Review all privileges of all databasesmy_mongodb_0:PRIMARY> use mydatastoreswitched to db mydatastoremy_mongodb_0:PRIMARY> db.getUsers();[ { "_id" : "mysdatastore.user", "user" : "user", "db" : "mysdatastore", "roles" : [ { "role" : "readWrite", "db" : "mysdatastore" }, { "role" : "readWrite", "db" : "admin" } ] }]

ClusterControl MongoDB security features

ClusterControl MongoDB deployment

☐ Enables authentication☐ Enables replication key☐ Binds to configured ip address☐ Port numbers can be customized☐ Disables http / REST api☐ Forces creation of an admin account☐ Separation of roles

☐ Admin☐ Backup user

ClusterControl Authentication advisor

☐ Checks if authentication has been enabled☐ Explicitly☐ Implicitly (e.g. replication key)

☐ Warns if authentication has been disabled

ClusterControl Authentication advisor

ClusterControl Authorization advisor

☐ Verifies users/roles per database☐ Checks for weak passwords☐ Checks for excessive roles☐ Checks for excessive roles on other databases

☐ Warns if these conditions haven’t been met

ClusterControl Authorization advisor

ClusterControl: live demo

Thank you!

☐ Severalnines Blog on MongoDB☐ https://severalnines.com/blog-categories/mongodb

☐ ClusterControl for MongoDB☐ https://severalnines.com/product/clustercontrol/for_mongodb

☐ Download ClusterControl ☐ https://severalnines.com/download-clustercontrol-database-m

anagement-system

☐ Contact: [email protected]

Webinar slides: How to Secure MongoDB with ClusterControl

Internet

Transcript of Webinar slides: How to Secure MongoDB with ClusterControl