If MongoDB is your document store of choice, then this article should help you configure everything securely and properly for a production-ready environment.
The MongoDB Installation Tutorial covers how to install MongoDB on a droplet.
As always, please read the official documentation on Security and Authentication.
There are two differently recommended paths that are available. The first is to connect securely to your database through an SSH tunnel. The alternative is to allow connections to your database over the internet. Of the two choices, the former is recommended.
By connecting to your Mongo VIrtual Private Server through an SSH tunnel, you can avoid a lot of potential security issues. The caveat is that your VPS must otherwise be totally locked down with few to no other ports open. A recommended SSH configuration is key-only or key+password.
To setup an SSH tunnel, you'll need to ensure that:
Next, run the following command to initialize the connection:
# The \s are just to multiline the command and make it more readable ssh \ -L 4321:localhost:27017 \ -i ~/.ssh/my_secure_key \ ssh_user@mongo_db_droplet_host_or_ip
Let's run through this step-by-step:
Number 2 is really the meat of the instruction. This will determine how you tell your applications or services to connect to your MongoDB Droplets.
If connecting over an SSH tunnel is not necessarily an option, you can always connect over the internet. There are a few security strategies to consider here.
The first is to use a non-standard port. This is more of an obfuscation technique and simply means that default connection adapters will not work.
# In your MongoDB configuration file, change the following line to something other than 27017 port = 27017
Secondly, you'll want to bind Mongo directly to your application server's IP address. Setting this to 127.0.0.1 will ensure that Mongo only accepts connections locally.
# In your MongoDB configuration file, change the following line to your application server's IP address bind_ip = 127.0.0.1
Lastly, consider using MongoDB's authentication feature and set a username and password. To set this up, connect to the MongoDB shell as an admin with the `mongo` command and add a user. Once that's done, make sure you're adding the newly added username/password in your MongoDB connection strings.
Please consider the above a starting point and not the be-all-end-all for MongoDB security. A key factor NOT mentioned here are server firewall rules. To see the 10gen firewall recommendations for MongoDB, head to their security documentation.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Click below to sign up and get $200 of credit to try our products over 60 days!
Enter your email to get $200 in credit for your first 60 days with DigitalOcean.
The assumptions of this article are strange and some less experienced people are going to think they have secured their mongodb instance when they have not.
This article gives two options for securing mongo (and really, any service that listens on a port).
Option #1 a. Secure everything (not described) b. Use ssh tunnel to connect
In option #1 this article assumes that the user does not know how to use SSH’s -L and -i options. However, it also assumes that the user knows how to “totally lock down everything” without a single sentence describing how one might go about this (For example: “see: Firewall”). If 100 users read this article, you can imagine at least a few naive users will assume that the tunneling is the important part (as it is the only part described) and just doing that bit.
Option #2 a. Change the port mongo is listening on b. Bind mongo to localhost
Here, the article assumes that the reader does not know that “port” and “bind_id” are respectively the port that mongo listens on and the IP mongo binds to. However, the article does assume that the user knows how to check which port and IP mongo currently uses, how to find the mongo config or how to specify a mongo conf file on startup.
There is a note at the bottom with a link to firewall docs as well as links where all of this other stuff is being discussed. Hopefully less experienced people will read down to that part and realize they missed something above.
Nice article, thank you. One suggestion to the SSH tunnel setup. I think it could be beneficial to mention also -fN option in setting up the SSH tunnel to keep it alive. (https://explainshell.com/explain?cmd=ssh+-fN+-L+-i)
One of the things I remember after the huge vulnerability in MongoDB related to
bindIpis that it should be set to
127.0.0.1the difference being that
0.0.0.0enables MongoDB to listen on all the IPs of the machine where it is running.
This means that if a machine has a private IP like
10.11.xxx.xxxand a public IP of
87.22.xxx.xxxMongoDB would be able to listen and respond on both IPs.
This enables both internal (same-network) connections as well as external connections.
The proposed solution here only allows traffic using the machine’s public IP which is something you might not want to do, when you’re connecting to it from the same network/VPC
Poorly explained. Assumed too much. Glossed over or skipped completely a lot of important topics. Add the “Downvote” button back.
I wrote a similar article on this topic a while ago - 10 Tips to improve mongodb security
A couple important things missing in the artcile
regards, Dharshan Rangegowda Founder | Scalegrid.io | @dharshanrg
I’ve read @jtal04 and I’ll check that topic deeply. It’s a great contribution.
However, by the moment, I have a question regarding step 2. What do you mean with “current machine”?
I’m developing a (Android) Java application and wold like to connect to a MongoDB.
Is it possible to only allow defined IPs to connect to the server? A whitelist, so to say.
Thx! This helped alot.
This is such a GREAT article. Thank you so much for sharing this with the community!
@Ivan: It shouldn’t affect performance too much. I haven’t tried that but you can run some benchmarks with and without the SSH tunnel and see whether it noticeably affects performance or not.