Localhost exception in Mongo DB (Security problem?)

200 views
Skip to first unread message

monitor.t...@gmail.com

unread,
Aug 30, 2017, 10:55:32 AM8/30/17
to mongodb-user

I have a Mongo DB database installed and configured, but I have a very big problem regarding security...


I have enabled authentication and created a bunch of users, each with its own permissions, everything ok there, now my problem is that if a bad guy gets access to my server, he can simply restart the service without specifing the authentication parameter, and access all my databases just by loggin with the localhost...


In the documentation it says:

The localhost exception applies only when there are no users created in the MongoDB instance.

Well... I have already created users... and I am still able to access my database using the localhost exception... Am I doing anything wrong? Or is the documentation wrong?


If so, this seems to be a major security problem...


The Mongo version I am using is 3.4.

Stephen Steneker

unread,
Aug 30, 2017, 7:54:48 PM8/30/17
to mongodb-user
On Thursday, 31 August 2017 00:55:32 UTC+10, monitor.tester.1337 wrote:

I have a Mongo DB database installed and configured, but I have a very big problem regarding security...


I have enabled authentication and created a bunch of users, each with its own permissions, everything ok there, now my problem is that if a bad guy gets access to my server, he can simply restart the service without specifing the authentication parameter, and access all my databases just by loggin with the localhost...


Hi,

Authentication only controls access to clients connecting to a MongoDB deployment.

Security involves multiple layers of defence, and access control is only a starting point. Limiting remote network exposure to your server and encrypting your data files are separate security measures.

An attacker gaining shell access to your server with the ability to restart services has successfully bypassed all of your security measures, and at this stage has equivalent (or better) access than you do.

As the administrator of a server, it is your responsibility to have appropriate access control, firewalls, auditing, and other security measures in place. At a minimum you should also enable network encryption (TLS/SSL) and appropriately limit network exposure.


For a list of recommended security measures, see the MongoDB Security Checklist.


Regards,

Stennie

monitor.t...@gmail.com

unread,
Aug 31, 2017, 3:54:51 AM8/31/17
to mongodb-user
Yes, I understand that access to the server is my responsability, but access to the database is Mongo responsability... The documentation says: "The localhost exception applies only when there are no users created in the MongoDB instance.", well, I have already created users in the admin database, but I still can use the localhost exception. Is the documentation wrong? or am I doing anything wrong?

Rhys Campbell

unread,
Aug 31, 2017, 7:02:53 AM8/31/17
to mongodb-user
The docs alos say this...

"The localhost exception changed so that these connections only have access to create the first user on the admin database. In previous versions, connections that gained access using the localhost exception had unrestricted access to the MongoDB instance."


I would double check the database you have created these users in.

monitor.t...@gmail.com

unread,
Aug 31, 2017, 7:12:27 AM8/31/17
to mongodb-user
Yes, my admin user was created in the admin table.

If I log in with him I can see him in

System > admin > Collections > system.users, and in that collection I have my admin user.

At the same level of the folder Collections, I also have another folder called Users, but I cant access it, it gives me the error "Failed to refresh 'Users'. Error: Wrong type for field (_id) string != 7" Is this anything to do with my problem?


Rhys Campbell

unread,
Aug 31, 2017, 8:16:20 AM8/31/17
to mongodb-user
Have you enabled auth by passing the --auth flag or putting it in the config file?


If that checks out then paste the results of...

use admin;
db.system.users.find().pretty();

Redacting any sensitive info so we can have a look at your user.

" "Failed to refresh 'Users'. Error: Wrong type for field (_id) string != 7" Is this anything to do with my problem?" <- Presumably you're using some type of GUI here. Open the shell for this.

Stephen Steneker

unread,
Aug 31, 2017, 8:35:11 AM8/31/17
to mongodb-user
Hi,

We're also discussing this on DBA StackExchange. A key (and incorrect) assumption is that once users have been configured, restarting without access control enabled will still require clients to authenticate:

I have enabled authentication and created a bunch of users, each with its own permissions, everything ok there, now my problem is that if a bad guy gets access to my server, he can simply restart the service without specifing the authentication parameter, and access all my databases just by loggin with the localhost...


Presence of authentication data does not automatically enable access control. If a system administrator restarts MongoDB without enabling access control (or uses a backup of the data on another deployment without access control) it is expected that clients will be able to connect without authentication.

The localhost exception only applies with access control enabled, in order to allow a system administrator to create an initial user. Otherwise a system administrator would be locked out of a deployment with no possibility of creating any users.

An alternative approach for initial configuration is to start your MongoDB server without access control enabled, create an administrative user, and then restart the server with access control enabled. This is the approach used in the Enable Auth tutorial you followed.

At the same level of the folder Collections, I also have another folder called Users, but I cant access it, it gives me the error "Failed to refresh 'Users'. Error: Wrong type for field (_id) string != 7" Is this anything to do with my problem?

This error is unrelated to the access control setting for your MongoDB server. I expect you are using a third party tool which isn't fully compatible with your MongoDB 3.4 deployment and should update to the latest version or file a bug report with the developer.

Regards,
Stennie
Reply all
Reply to author
Forward
0 new messages