Configure Windows netsh Firewall for MongoDB

On Windows Server systems, the netsh program providesmethods for managing the Windows Firewall. These firewall rules make it possiblefor administrators to control what hosts can connect to the system,and limit risk exposure by limiting the hosts that can connect to asystem.

This document outlines basic Windows Firewall configurations.Use these approaches as a starting point for yourlarger networking organization.For a detailed over view of securitypractices and risk management for MongoDB, seeSecurity.

See also

Windows Firewalldocumentation from Microsoft.

Overview

Windows Firewall processes rules in an ordered determinedby rule type, and parsed in the following order:

  • Windows Service Hardening
  • Connection security rules
  • Authenticated Bypass Rules
  • Block Rules
  • Allow Rules
  • Default RulesBy default, the policy in Windows Firewall allows all outbound connectionsand blocks all incoming connections.

Given the default ports of allMongoDB processes, you must configure networking rules that permit _only_required communication between your application and the appropriatemongod.exe and mongos.exe instances.

The configuration changes outlined in this document will create ruleswhich explicitly allow traffic from specific addresses and on specificports, using a default policy that drops all traffic that is notexplicitly allowed.

You can configure the Windows Firewall with using the netsh command linetool or through a windows application. On Windows Server 2008 thisapplication is Windows Firewall With Advanced Security in Administrative Tools.On previous versions of Windows Server, access theWindows Firewall application in the System and Security control panel.

The procedures in this document use the netsh command line tool.

Patterns

This section contains a number of patterns and examples forconfiguring Windows Firewall for use with MongoDB deployments.If you have configured different ports using the port configurationsetting, you will need to modify the rules accordingly.

Traffic to and from mongod.exe Instances

This pattern is applicable to all mongod.exe instances runningas standalone instances or as part of a replica set.The goal of this pattern is to explicitly allow traffic to themongod.exe instance from the application server.

  1. netsh advfirewall firewall add rule name="Open mongod port 27017" dir=in action=allow protocol=TCP localport=27017

This rule allows all incoming traffic to port 27017, whichallows the application server to connect to themongod.exe instance.

Windows Firewall also allows enabling network access foran entire application rather than to a specific port, as in thefollowing example:

  1. netsh advfirewall firewall add rule name="Allowing mongod" dir=in action=allow program=" C:\Program Files\MongoDB\Server\3.4\bin\mongod.exe"

You can allow all access for a mongos.exe server, with thefollowing invocation:

  1. netsh advfirewall firewall add rule name="Allowing mongos" dir=in action=allow program=" C:\Program Files\MongoDB\Server\3.4\bin\mongos.exe"

Traffic to and from mongos.exe Instances

mongos.exe instances provide query routing forsharded clusters. Clients connect to mongos.exeinstances, which behave from the client’s perspective asmongod.exe instances. In turn, the mongos.execonnects to all mongod.exe instances that are components ofthe sharded cluster.

Use the same Windows Firewall command to allow traffic toand from these instances as you would from the mongod.exeinstances that are members of the replica set.

  1. netsh advfirewall firewall add rule name="Open mongod shard port 27018" dir=in action=allow protocol=TCP localport=27018

Traffic to and from a MongoDB Config Server

Configuration servers, host the config database that stores metadatafor sharded clusters. Each production cluster has three configurationservers, initiated using the mongod —configsvroption. [1] Configuration servers listen for connections on port27019. As a result, add the following Windows Firewall rules to theconfig server to allow incoming and outgoing connection on port27019, for connection to the other config servers.

  1. netsh advfirewall firewall add rule name="Open mongod config svr port 27019" dir=in action=allow protocol=TCP localport=27019

Additionally, config servers need to allow incoming connections fromall of the mongos.exe instances in the cluster and allmongod.exe instances in the cluster. Add rules thatresemble the following:

  1. netsh advfirewall firewall add rule name="Open mongod config svr inbound" dir=in action=allow protocol=TCP remoteip=<ip-address> localport=27019

Replace <ip-address> with the addresses of themongos.exe instances and the shard mongod.exeinstances.

[1]You also can run a config server by using theconfigsvr value for the clusterRole setting in aconfiguration file.

Traffic to and from a MongoDB Shard Server

For shard servers, running as mongod —shardsvr[2] Because the default port number is 27018 when runningwith the shardsvr value for the clusterRole setting,you must configure the following Windows Firewall rules to allowtraffic to and from each shard:

  1. netsh advfirewall firewall add rule name="Open mongod shardsvr inbound" dir=in action=allow protocol=TCP remoteip=<ip-address> localport=27018
  2. netsh advfirewall firewall add rule name="Open mongod shardsvr outbound" dir=out action=allow protocol=TCP remoteip=<ip-address> localport=27018

Replace the <ip-address> specification with the IP address of allmongod.exe instances. This allows you to permit incomingand outgoing traffic between all shards including constituent replicaset members to:

Furthermore, shards need to be able make outgoing connections to:

Create a rule that resembles the following, and replace the<ip-address> with the address of the config servers and themongos.exe instances:

  1. netsh advfirewall firewall add rule name="Open mongod config svr outbound" dir=out action=allow protocol=TCP remoteip=<ip-address> localport=27018
[2]You can also specify the shard server option with the shardsvr valuefor the clusterRole setting in the configuration file. Shardmembers are also often conventional replica sets using the defaultport.
[3]All shards in a cluster need to be able tocommunicate with all other shards to facilitate chunk andbalancing operations.

Provide Access For Monitoring Systems

The mongostat diagnostic tool, when running with the—discover needs to be able to reachall components of a cluster, including the config servers, the shardservers, and the mongos.exe instances.

Changed in version 3.6: MongoDB 3.6 removes the deprecated HTTP interface and REST API toMongoDB.

Manage and Maintain Windows Firewall Configurations

This section contains a number of basic operations for managing andusing netsh. While you can use the GUI front ends to manage theWindows Firewall, all core functionality is accessible isaccessible from netsh.

Delete all Windows Firewall Rules

To delete the firewall rule allowing mongod.exe traffic:

  1. netsh advfirewall firewall delete rule name="Open mongod port 27017" protocol=tcp localport=27017
  2.  
  3. netsh advfirewall firewall delete rule name="Open mongod shard port 27018" protocol=tcp localport=27018

List All Windows Firewall Rules

To return a list of all Windows Firewall rules:

  1. netsh advfirewall firewall show rule name=all

Reset Windows Firewall

To reset the Windows Firewall rules:

  1. netsh advfirewall reset

Backup and Restore Windows Firewall Rules

To simplify administration of larger collection of systems, you can export orimport firewall systems from different servers) rules very easily on Windows:

Export all firewall rules with the following command:

  1. netsh advfirewall export "C:\temp\MongoDBfw.wfw"

Replace "C:\temp\MongoDBfw.wfw" with a path of your choosing. Youcan use a command in the following form to import a file created usingthis operation:

  1. netsh advfirewall import "C:\temp\MongoDBfw.wfw"