Configure Linux iptables Firewall for MongoDB
On this page
On contemporary Linux systems, the
iptables program provides methods for managing the Linux Kernel’s
netfilter or network packet filtering capabilities. These firewall rules make it possible for administrators to control what hosts can connect to the system, and limit risk exposure by limiting the hosts that can connect to a system.
This document outlines basic firewall configurations for
iptables firewalls on Linux. Use these approaches as a starting point for your larger networking organization. For a detailed overview of security practices and risk management for MongoDB, see Security.
iptables configurations fall into chains, which describe the process for filtering and processing specific streams of traffic. Chains have an order, and packets must pass through earlier rules in a chain to reach later rules. This document addresses only the following two chains:
- Controls all incoming traffic.
- Controls all outgoing traffic.
Be aware that, by default, the default policy of
iptables is to allow all connections and traffic unless explicitly disabled. The configuration changes outlined in this document will create rules that explicitly allow traffic from specific addresses and on specific ports, using a default policy that drops all traffic that is not explicitly allowed. When you have properly configured your
iptables rules to allow only the traffic that you want to permit, you can Change Default Policy to DROP.
This section contains a number of patterns and examples for configuring
iptables for use with MongoDB deployments. If you have configured different ports using the
port configuration setting, you will need to modify the rules accordingly.
The goal of this pattern is to explicitly allow traffic to the
mongod instance from the application server. In the following examples, replace
<ip-address> with the IP address of the application server:
The first rule allows all incoming traffic from
<ip-address> on port
27017, which allows the application server to connect to the
mongod instance. The second rule, allows outgoing traffic from the
mongod to reach the application server.
If you have only one application server, you can replace
<ip-address> with either the IP address itself, such as:
198.51.100.55. You can also express this using CIDR notation as
198.51.100.55/32. If you want to permit a larger block of possible IP addresses you can allow traffic from a
/24 using one of the following specifications for the
<ip-address>, as follows:
mongos instances provide query routing for sharded clusters. Clients connect to
mongos instances, which behave from the client’s perspective as
mongod instances. In turn, the
mongos connects to all
mongod instances that are components of the sharded cluster.
Use the same
iptables command to allow traffic to and from these instances as you would from the
mongod instances that are members of the replica set. Take the configuration outlined in the Traffic to and from mongod Instances section as an example.
Config servers host the config database that stores metadata for sharded clusters. Config servers listen for connections on port
27019. As a result, add the following
iptables rules to the config server to allow incoming and outgoing connection on port
27019, for connection to the other config servers.
<ip-address> with the address or address space of all the
mongod that provide config servers.
Shard servers default to port number
27018. You must configure the following
iptables rules to allow traffic to and from each shard:
<ip-address> specification with the IP address of all
mongod. This allows you to permit incoming and outgoing traffic between all shards including constituent replica set members, to:
Furthermore, shards need to be able make outgoing connections to:
mongodinstances in the config servers.
Create a rule that resembles the following, and replace the
<ip-address> with the address of the config servers and the
|||All shards in a cluster need to be able to communicate with all other shards to facilitate chunk and balancing operations.|
Changed in version 3.6: MongoDB 3.6 removes the deprecated HTTP interface and REST API to MongoDB.
The default policy for
iptables chains is to allow all traffic. After completing all
iptables configuration changes, you must change the default policy to
DROP so that all traffic that isn’t explicitly allowed as above will not be able to reach components of the MongoDB deployment. Issue the following commands to change this policy:
This section contains a number of basic operations for managing and using
iptables. There are various front end tools that automate some aspects of
iptables configuration, but at the core all
iptables front ends provide the same basic functionality:
By default all
iptables rules are only stored in memory. When your system restarts, your firewall rules will revert to their defaults. When you have tested a rule set and have guaranteed that it effectively controls traffic you can use the following operations to you should make the rule set persistent.
On Red Hat Enterprise Linux, Fedora Linux, and related distributions you can issue the following command:
On Debian, Ubuntu, and related distributions, you can use the following command to dump the
iptables rules to the
Run the following operation to restore the network rules:
Place this command in your
rc.local file, or in the
/etc/network/if-up.d/iptables file with other similar operations.
To list all of currently applied
iptables rules, use the following operation at the system shell.