Enabling IP Security for MongoDB 3.6 on Ubuntu

Jay Gordon
December 19, 2017

MongoDB 3.6 provides developers and DevOps professionals with a secure by default configuration that protects data from external threats by denying unauthorized access on a public network. MongoDB servers will now only listen for connections on the local host unless explicitly configured to listen on another address.

This tutorial will briefly show you how to enable IP addresses beyond localhost to your MongoDB node to ensure your networked servers are able to connect to your database. You will see how easily MongoDB is configured to start up and listen on specific network interfaces.

This tutorial assumes you have:

  • Installed MongoDB 3.6 (this does not handle upgrading from previous versions)
  • Multiple network interfaces on your server (we'll use an AWS EC2 instance)
  • Basic understanding of IP Networks and how to configure a private network for your data (we’ll use an AWS VPC)
  • Understanding that "localhost" refers to IP 127.0.0.1

Getting Started

I have launched an AWS EC2 instance with Ubuntu 16.04 LTS and installed MongoDB as described on the MongoDB downloads page.

I want to enable the private IP range that is part of my VPC to allow us to access our MongoDB database. By doing this, we'll ensure that only our private network and "localhost" are valid network paths to connect to the database. This will help ensure we never have outsiders poking into our database!

I first launch an Ubuntu 16.04 EC2 instance in my public subnet within my VPC. By doing this, I will allow my network interface to allow network connections to the outside world without requiring a NAT Gateway.

Next, I follow the instructions on the MongoDB documentation on how to install MongoDB on Ubuntu. I can verify which ethernet interfaces the process starts on in Linux by running the following command:

ubuntu@ip-172-16-0-211:~$ sudo netstat -plant | egrep mongod
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      2549/mongod

This output means that users are only permitted to access our MongoDB instance on port 27017 via IP 127.0.0.1. If you would like to make this available to other systems on your network, you'll want to bind the local IP associated with the private network. To determine network interface configuration easily, we can just run an ifconfig from the command line:

ubuntu@ip-172-16-0-211:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 0e:5e:76:83:49:3e
          inet addr:172.16.0.211  Bcast:172.16.0.255  Mask:255.255.255.0
          inet6 addr: fe80::c5e:76ff:fe83:493e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
          RX packets:65521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7358 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:94354063 (94.3 MB)  TX bytes:611646 (611.6 KB)

We have the IP we want to make part of the list of acceptable network addresses we can listen from. I will open the /etc/mongodb.conf file and edit it to reflect the additional network IP:

The file's changes will be:

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1,172.16.0.211

After modifying bindIP under "net" from just 127.0.0.1 to include private IP address 172.16.0.211, we should be able to restart and see it listening from netstat on both now:

ubuntu@ip-172-16-0-211:~$ sudo service mongod stop
ubuntu@ip-172-16-0-211:~$ sudo service mongod start
ubuntu@ip-172-16-0-211:~$ sudo netstat -plnt | egrep mongod
tcp        0      0 172.16.0.211:27017      0.0.0.0:*               LISTEN      2892/mongod
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      2892/mongod

Now our database will be able to accept requests from both the specified IP address as well as localhost:

Shell access via localhost

ubuntu@ip-172-16-0-211:~$ mongo localhost
MongoDB shell version v3.6.0-rc2
connecting to: mongodb://127.0.0.1:27017/localhost

Shell access via private IP

ubuntu@ip-172-16-0-211:~$ mongo 172.16.0.211
MongoDB shell version v3.6.0-rc2
connecting to: mongodb://172.16.0.211:27017/test

Next Steps

The default localhost configuration has tremendous benefits to security as you now must explicitly allow network connections, blocking attackers from untrusted networks. Keeping your MongoDB database safe from remote intrusion is extremely important. Make sure you follow our Security Checklist to configure your MongoDB database cluster with the appropriate security best practices.

Now that you understand how to configure additional IP addresses on your MongoDB 3.6 server, you're able to begin configuring replication. Don't forget backups, monitoring and all the other important parts of your MongoDB clusters' health. If you'd rather spend less time on these tasks and deploy MongoDB clusters with a click or an API call, check out MongoDB Atlas, our fully managed database as a service.

← Previous

New MongoDB 3.6 Security Features

MongoDB has always made it quick and easy to iterate -- from prototype to production to maturity, keeping pace in modern agile release cycles. Our 3.6 release is a milestone in security, adding two new features to improve the ease and cost of security management, even for the most fast-paced development environments. Localhost Default Flexibility has led to widespread adoption of MongoDB by users who appreciate the ease of installation and use. These same users also expect a level of balance between performance and safety that only can be achieved with secure-by-default configurations. This is why we are happy to now provide our users with a localhost binding set by default. Upon installation MongoDB (3.6 and later) can only be accessed from the local machine on which it has been installed (using Mongo shell, a MongoDB driver, or tools and utilities such as Ops Manager or Compass). When MongoDB is started it has to have networking explicitly enabled and configured. What happens when you connect your instance to the internet? “If you explicitly turn on [networking], but don’t turn on authentication, we can’t help you at that point. But you have to consciously do that, and we’d hope that people think about it a little” CTO Eliot Horowitz explained to The Next Web . We see this change as fundamentally raising the bar on safety, eliminating whole classes of threats, while still preserving our popular deployment speed and ease. IP Whitelisting for Authentication After enabling whitelisting , a client authenticating against a user account in MongoDB must meet all listed restrictions in any document attached to that user. Clients authenticating against a user account which is a member of a restricted role must meet all listed restrictions in any document attached to that role. For example here is how a document attached to a database user or role can be set to only allow 192.168.17.6 clients to connect. Beyond that it can be set to only connect to the services listening in 10.10.10.0/24. Using the following syntax an IP must be matched during authentication to login. authenticationRestrictions: [{ clientSource: [“192.168.17.6”, “127.0.0.1”] serverAddress: [“10.10.10.0/24”, “127.0.0.1”] }] We’re always striving to make safe development easier. That’s why we have taken an approach to facilitate safe choices within a flexible product, in order to serve the many development community decisions for deploying MongoDB. The security changes in 3.6 remove bottlenecks and obviate workarounds, expanding MongoDB use to an even wider variety of applications, and providing security teams the configurations they demand for mission critical situations. MongoDB 3.6 applies the "safe by default" principle so you can confidently move at the speed of your data. To learn more about everything new in MongoDB 3.6, download the What's New guide . About the Author - Davi Ottenheimer Davi leads Product Security at MongoDB.

December 19, 2017
Next →

Data and the European Landscape: 3 Trends for 2022

The past two years have brought massive changes for IT leaders: large and complex cloud migrations; unprecedented numbers of people suddenly working, shopping and learning from home; and a burst in demand for digital-first experiences. Like everyone else, we are hoping that 2022 isn’t so disruptive (fingers crossed!), our customer conversations in Europe do lead us to believe the new year will bring new business priorities. We’re already noticing changes in conversations around vendor lock-in, thanks to the Digital Markets Act, a new enthusiasm for combining operational and analytical data to drive new insights faster, and a more strategic embrace of sustainability. Here’s how we see these trends playing out in 2022. Digital markets act draws new attention to cloud vendor lock-in in Europe We’ve heard plenty about the European Commission’s Digital Markets Act , which, in the name of ensuring fair and open digital markets, would place new restrictions on companies that are deemed to be digital “gatekeepers” in the region. That discussion will be nothing compared to the vigorous debate we expect once the EU begins the very tricky political business of determining exactly which companies will fall under the act. If the EU sets the bar for revenues, users, and market size high enough, it’s possible that the regulation will end up affecting only Facebook, Amazon, Google, Apple, and Microsoft. But a European group representing 2,500 CIOs and almost 700 organizations is now pushing to have the regulation encompass more software companies. Their main concern centers around “distorted competition” in cloud infrastructure services and a worry that companies are being locked into one cloud vendor. A trend that will likely increase in 2022 that pushes back on cloud vendor lock-in is embracing multi-cloud strategies. We should expect to see more organisations in the region pursuing multi-cloud environments as a means to improve business continuity and agility whilst being able to access best of breed services from each cloud provider. As we have always said …”it’s fine to date your cloud provider….but don’t ever marry them.” The convergence of operational and analytical data The processing of operational and analytical data is almost always contained in different data systems, each tuned to that use case and managed by separate teams. But because that data lives in separate places, it’s almost impossible for organisations to generate insights and automate actions in real time, against live data. We believe 2022 is the year we’ll see a critical mass of companies in the region make significant progress toward a convergence of their operational and analytical data. We’re already starting to see some of the principles of microservices in operational applications, such as domain ownership, be applied to analytics as well. We’re hearing about this from so many of our customers locally, who are looking at MongoDB as an application data platform that allows them to perform queries across both real-time and historical data, using a unified platform and a single query API. This results in the applications they are building becoming more intelligent and contextual to their users, while avoiding dependencies on centralized analytics teams that otherwise slow down how quickly new, data-driven experiences can be released. Sustainability drives local strategic IT choice Technology always has some environmental cost. Sometimes that’s obvious — such as the energy needs and emissions associated with Bitcoin mining. More often, though, the environmental costs are well hidden. The European Green Deal commits the European Union to reducing emissions by 55% by 2030, with a focus on sustainable industry. With the U.N. Climate Change Conference (COP26) recently completed in Glasgow, and coming off the hottest European summer on record, climate issues have become top of mind. That means our customers are increasingly looking to make their technical operations more sustainable — including in their choice of cloud provider and data centers. According to research from IDC , more than 20% of CxOs say that sustainability is now important in selecting a strategic cloud service provider, and some 29% of CxOs are including sustainability into their RFPs for cloud services. Most interesting, 26% say they are willing to switch to providers with better sustainability credentials. Historically, it’s been difficult to make a switch like that. That’s part of the reason we built MongoDB Atlas — to give our customers the flexibility to run in any region , with any of the three largest cloud providers, and to make it easy to switch between them, and even to run a single database cluster across them. Publicly available information about the footprint of individual regions and even single data centers will make it simpler for companies to make informed decisions. Already, at least one cloud platform has added indicators to regions with the lowest carbon footprint. Source: IDC, European Customers Engage Services Providers at All Stages of Their Cloud Journey, IDC Survey Spotlight, Doc #EUR248484021, Dec 2021

December 21, 2021