After reviewing several MongoDB official documents (see list at the bottom) I understand that MongoDB security in communications (as in community version 4.2) works as follows:
For internal communication authentication (i.e. between the members of a replica set or between mongos and the replica sets which implement the different shards) there are two mechanisms available:
shared keyfile (--keyFile)
x.509 certificates
For internal communication encryption, SSL/TLS is the only possibility. In other words, shared keyfile (--keyFile) provides only authentication, but if you want encryption you need to use SSL/TLS alternative. Using SSL/TLS requires to use x.509 certificates also (so, we can say that encryption also provides authentication)
For client to MongoDB communications (either standalone, replica set or mongos in a shard cluster):
there isn't keyfile option
the only way to secure communication (which provides both authentication and encryption) is SSL/TLS with x.509 certificates
I'd like just to confirm my understanding, as the documentation I have browsed is a little "disperse" and I'm not sure if I have got the point. Any feedback, comment, extra info or documentation pointers is really welcome!
PD: the statement which I'm most unsure is this one: "shared keyfile (--keyFile) provides only authentication, but if you want encryption you need to use SSL/TLS alternative"
References checked:
https://docs.mongodb.com/manual/tutorial/configure-ssl
https://docs.mongodb.com/manual/tutorial/configure-ssl-clients/
https://docs.mongodb.com/manual/core/security-internal-authentication
For client to MongoDB communications (either standalone, replica set or mongos in a shard cluster) there are several authentication methods:
No authentication
Internal authentication with username/password
Kerberos Authentication
LDAP Proxy Authentication
LDAP Authentication
Note, you can always connect to MongoDB database, even without an account. However, you are not permitted to execute any command unless you are authenticated.
Related
I'm having some mongodb connection securtity concerns for my env.
Here is my environment:
one ECS hosted on cloud that has a public IP but no domain and no ssl certificate neither.
installed mongodb service on this ECS that needs username/password to authenticate
only specific IPs in the whitelist can access the ECS/mongodb
I'm wondering if the data transfer between this mongodb and my local pc is safe or not?
Will the data be encrpyted during the transmission or just plain text so that everyone on the internet can catch and read it? (As I don't have https so it's not using TLS/SSL)
Can canyone explain the machanism or give some some doc links?
Thanks!
As your not using SSL, your data on fly is not encrypted. You need to use TLS/SSL to encrypt the network transmission. You must have the TLS/SSL certificates as PEM files, which are concatenated certificate containers
In addition to encrypting connections, TLS/SSL allows for authentication using certificates, both for client authentication and for internal authentication of members of replica sets and sharded clusters
In the beginning of the year, lots of MongoDB databases were hacked. This also included my database. Yesterday I noticed my brand new database with authorization enabled was hacked as well. The username and password is very secure (16+ characters password with random characters and symbols).
I've now decided to fully secure it, but I honestly don't know where to proceed. I already have:
security:
authorization: enabled
and that should be enough (after sudo service mongod restart). I only have 1 database and no admin user, but anonymous access from a remote connection is still allowed. I keep reading many places, that I should run mongod like mongod --auth, but that it's the same as enabling authorization as I've done above.
At this point I'm struggling to disable anonymous authentication on the server. What did I miss? Why can I authenticate without an account?
To enable security you'll want to follow the Security Checklist on the MongoDB Website.
Here you are provided with role based authorization and authentication instructions. It's also advised you disable listening to all ethernet interfaces and bind your MongoDB ports to the interfaces you'd like exposed.
For a guide to network hardening, you will want to review these instructions, but the most important aspect is to avoid unwanted network exposure. Consider using a firewall or security groups (if in cloud).
I'm using MongoDB 3.2.6 and I want to use Keyfile Access Control for MongoDB replication.
What I read in this link:
https://docs.mongodb.com/manual/tutorial/enforce-keyfile-access-control-in-existing-replica-set/
Enforcing access control on a replica set requires configuring Security between members of the replica set using Internal
Authentication
Unfortunately I can not find in the link below how I enable Internal Authentication:
https://docs.mongodb.com/manual/core/security-internal-authentication/
Should I configure auth = true in the mongo configuration file (and configure users)?
How I enable Internal Authentication?
The opposite question:
If I will enable configure auth = true in the mongo configuration then I have to use Keyfile Access Control for the MongoDB replication (otherwise the MongoDB replication will not work).
Correct?
There is not a separate option to enable internal authentication. Basically, internal authentication and client authentication need to be either both enabled or both disabled.
Note, that specifying the keyFile will implicitly enable authentication (e.g. setting auth=true is redundant/implied and not required). But setting both keyFile and auth is probably a good idea to avoid confusion.
When authentication is enabled and you are running a replica set or sharded cluster, then you must utilize one of the internal authentication mechanisms to allow the members to authenticate and communicate with each other. Meaning you will need to either use a keyFile or x.509 authentication in order for replication/sharding to work.
Does kerberos encrypt only the authentication process or all client communications?
I was under the impression it was like a VPN for the LAN.
So that all LAN communications are encrypted. Just like all internet communications are encrypted with a VPN.
Regards
Aubrey
Kerberos is quite capable of encrypting traffic between client and server, but depending on exactly how kerberos is used in the application, it may or may not be using the kerberos session keys to encrypt the traffic.
The kerberos protocol provides the means to exchange a session key that can be used to encrypt message traffic after the initial authentication exchange. Encrypted message exchange is generally the default for protocols that actually use GSSAPI. See gss_wrap documentation
GSSAPI is a generalized API for doing secure network applications. Kerberos is the mostly commonly used driver underneath GSSAPI.
If the application does not use GSSAPI, or the native kerberos messaging libraries, then it is likely using TLS to encrypt the traffic or the traffic is not encrypted.
Kerberos message encryption was designed to support relatively long lived tcp based client/server applications ( think telnet or ssh ). The API does not always map well to the way current applications are architected. Kerberos support is often bolted on well after the application is under construction
and is only used for authentication.
Kerberos is an distributed service that is generally used for secure authentication only. It does neither ensure that a user has the required permissions to access a resource (that would be Authorization) however it may be used to encrypt arbitrary data. As per RFC 3961 "Encryption and Checksum Specifications" which extends and correct aspects of RFC 1510 the Kerberos protocol provides confidentiality and integrity services.
While Kerberos can be used to encrypt information passed between authenticated peers in many cases it only performs the authentication step. Thus, you will find that Kerberos is used as component in a secure environment to ensure a secure authentication with other components and protocols handling the authorization and the secure transport.
In the end, it heavily depends on your usa-case to determine if the tradeoffs between using Kerberos or something else as a transport protocol make sense for you.
While the Kerberos protocol can be used to provide encryption services on most platforms, microsoft provides no mechanism to do this directory. Instead GSSAPI may be used to call these services.
For example, Active Directory uses Kerberos for message integrity.
Similarly, you could use e.g. TLS or IPsec to encrypt your data on the wire and combine it with Kerberos for authentication. But again, this is another protocol performing the actual transport encryption and just using Kerberos as an authentication component.
We have a mondogDB deployment currently in our test environment. We have a 7 member Replica Set and no Arbiter.
We want to configure the data replication between the replica set members secure.
We don't want to configure SSL for the clients to our MongoDB cluster as the communication from the client to this MongoDB cluster is via Stunnel. So the client doesn't need to use SSL to connect.
Just curious to see if this possible i.e configure only the data being replicated between replica set members Secure but not the actual communication from the Client to this MongoDB cluster
_THanks much
I've not tried this personally but I do believe you can do this. In addition to compiling mongodb with ssl, or purchasing one of the MongoDb subscriptions that support SSL you will need to run with the following option:
--sslMode
set to preferSSL. This will use SSL for inter-server communications but allow both SSL and non-SSL for other connections:
http://docs.mongodb.org/manual/reference/program/mongod/
That of course is all in addition to the other configuration settings required for running with SSL:
http://docs.mongodb.org/manual/tutorial/configure-ssl/
Note that this is new for version 2.6. I don't have a version of mongodb compiled with ssl support so it's not been tested by me.
#DurgaDeep in MongoDB v2.6 you can run the MongoDB instance in mixed mode SSL while also specifying the x509 certificates for the cluster members to authenticate each other. Please note that SSL is not part of the default community build and you may need to build the binary on your own if you are using community build. x509 certificates is only available on subscription builds so that will not work for you if you are using a community build.
The easiest option to achieve what you want to do irrespective of the MongoDB version would be to setup stunnel between the replica-set nodes and let it take care of encrypted channel independently. This is the usual route a lot of applications take which do not have SSL embedded as an option.