Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Verify that the MongoDB configuration file (default location: /etc/mongod.conf) contains the following: security: authorization: "enabled" If this parameter is not present, this is a finding.
Edit the MongoDB configuration file (default location: /etc/mongod.con) to include the following: security: authorization: "enabled" This will enable SCRAM-SHA-1 authentication (default). Instruction on configuring the default authentication is provided here: https://docs.mongodb.com/v3.4/tutorial/enable-authentication/ The high-level steps described by the above will require the following: 1. Start MongoDB without access control. 2. Connect to the instance. 3. Create the user administrator. 4. Restart the MongoDB instance with access control. 5. Connect and authenticate as the user administrator. 6. Create additional users as needed for your deployment.
Review the system documentation to determine the required levels of protection for DBMS server securables by type of login. Review the permissions actually in place on the server. If the actual permissions do not match the documented requirements, this is a finding. MongoDB commands to view roles in a particular database: db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true } )
Use createRole(), updateRole(), dropRole(), grantRole() statements to add and remove permissions on server-level securables, bringing them into line with the documented requirements. MongoDB commands for role management can be found here: https://docs.mongodb.com/v3.4/reference/method/js-role-management/
Check the MongoDB configuration file (default location: '/etc/mongod.conf)' for a key named 'auditLog:'. Example shown below: auditLog: destination: syslog If an "auditLog:" key is not present, this is a finding indicating that auditing is not turned on. If the "auditLog:" key is present and contains a subkey of "filter:" with an associated filter value string, this is a finding. The site auditing policy must be reviewed to determine if the "filter:" being applied meets the site auditing requirements. If not, then the filter being applied will need to be modified to comply. Example show below: auditLog: destination: syslog filter: '{ atype: { $in: [ "createCollection", "dropCollection" ] } }'
If the "auditLog" setting was not present in the MongoDB configuration file (default location: '/etc/mongod.conf)' edit this file and add a configured "auditLog" setting: auditLog: destination: syslog Stop/start (restart) the mongod or mongos instance using this configuration. If the "auditLog" setting was present and contained a "filter:" parameter, ensure the "filter:" expression does not prevent the auditing of events that should be audited or remove the "filter:" parameter to enable auditing all events.
Verify User ownership, Group ownership, and permissions on the "<MongoDB auditLog directory>": > ls –ald <MongoDB auditLog data directory> If the User owner is not "mongod", this is a finding. If the Group owner is not "mongod", this is a finding. If the directory is more permissive than "700", this is a finding. (The path for the MongoDB auditLog directory will vary according to local circumstances. The auditLog directory will be found in the MongoDB configuration file whose default location is '/etc/mongod.conf'.) To find the auditLog directory name, view and search for the entry in the MongoDB configuration file for the auditLog.path: Example: auditLog: destination: file format: BSON path: /var/lib/mongo/auditLog.bson Given the example above, to find the auditLog directory name run the following command: > dirname /var/lib/mongo/auditLog.bson the output will be the "<MongoDB auditLog directory>" /var/lib/mongo
Run these commands: "chown mongod <MongoDB auditLog directory>" "chgrp mongod <MongoDB auditLog directory>" "chmod 700 <<MongoDB auditLog directory>" (The path for the MongoDB auditLog directory will vary according to local circumstances. The auditLog directory will be found in the MongoDB configuration file whose default location is '/etc/mongod.conf'.) To find the auditLog directory name, view and search for the entry in the MongoDB configuration file for the auditLog.path: Example: auditLog: destination: file format: BSON path: /var/lib/mongo/auditLog.bson Given the example above, to find the auditLog directory name run the following command: > dirname /var/lib/mongo/auditLog.bson the output will be the "<MongoDB auditLog directory>" /var/lib/mongo
Verify User ownership, Group ownership, and permissions on the “<MongoDB configuration file>": (default name and location is '/etc/mongod.conf') (The name and location for the MongoDB configuration file will vary according to local circumstances.) Using the default name and location the command would be: > ls –ald /etc/mongod.conf If the User owner is not "mongod", this is a finding. If the Group owner is not "mongod", this is a finding. If the filename is more permissive than "700", this is a finding.
Run these commands: "chown mongod <MongoDB configuration file>" "chgrp mongod <MongoDB configuration file>" "chmod 700 <<MongoDB configuration file>" (The name and location for the MongoDB configuration file will vary according to local circumstances. The default name and location is '/etc/mongod.conf'.) Using the default name and location the commands would be: > chown mongod /etc/mongod.conf > chgrp mongod /etc/mongod.conf > chmod 700 /etc/mongod.conf
Review procedures for controlling, granting access to, and tracking use of the DBMS software installation account. If access or use of this account is not restricted to the minimum number of personnel required or if unauthorized access to the account has been granted, this is a finding.
Develop, document, and implement procedures to restrict and track use of the DBMS software installation account.
Review the MongoDB software library directory and note other root directories located on the same disk directory or any subdirectories. If any non-MongoDB software directories exist on the disk directory, examine or investigate their use. If any of the directories are used by other applications, including third-party applications that use the MongoDB this is a finding. Only applications that are required for the functioning and administration, not use, of the MongoDB should be located in the same disk directory as the MongoDB software libraries. If other applications are located in the same directory as the MongoDB database this is a finding.
Install all applications on directories separate from the MongoDB software library directory. Relocate any directories or reinstall other application software that currently shares the MongoDB software library directory.
Run the following command to get the roles from a MongoDB database. For each database in MongoDB: use <database> db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true } ) Run the following command to the roles assigned to users: use admin db.system.users.find() Analyze the output and if any roles or users have unauthorized access, this is a finding.
Use the following commands to remove unauthorized access to a MongoDB database. db.revokePrivilegesFromRole() db. revokeRolesFromUser() MongoDB commands for role management can be found here: https://docs.mongodb.com/v3.4/reference/method/js-role-management/
Review the list of components and features installed with the MongoDB database. If unused components are installed and are not documented and authorized, this is a finding. RPM can also be used to check to see what is installed: yum list installed | grep mongodb This returns MongoDB database packages that have been installed. If any packages displayed by this command are not being used, this is a finding.
On data-bearing nodes and arbiter nodes, the mongodb-enterprise-tools, mongodb-enterprise-shell and mongodb-enterprise-mongos can be removed (or not installed). On applications servers that typically run the mongos process when connecting to a shared cluster, the only package required is the mongodb-enterprise-mongos package.
In the MongoDB database configuration file (default location: /etc/mongod.conf), review the following parameters: net: http: enabled: true JSONPEnabled: true RESTInterfaceEnabled: true If any of the <booleans> are "True" or "Enabled", this is a finding.
In the MongoDB database configuration file (default location: /etc/mongod.conf), ensure the following parameters either: Does not exist in the file OR Are set to "false" as shown below: http: enabled: false JSONPEnabled: false RESTInterfaceEnabled: false
To view another user’s information, you must have the "viewUser" action on the other user’s database. For each database in the system, run the following command: db.getUsers() Ensure each user identified is a member of an appropriate organization that can access the database. If a user is found not be a member or an appropriate organization that can access the database, this is a finding. Verify that the MongoDB configuration file (default location: /etc/mongod.conf) contains the following: security: authorization: "enabled" If this parameter is not present, this is a finding.
Prereq: To drop a user from a database, must have the "dropUser" action on the database. For any user not a member of an appropriate organization and has access to a database in the system run the following command: // Change to the appropriate database use <database> db.dropUser(<username>, {w: "majority", wtimeout: 5000} If the MongoDB configuration file (default location: /etc/mongod.conf) does not contain security: authorization: "enabled" Edit the MongoDB configuration file, add these parameters, stop/start (restart) any mongod or mongos process using this MongoDB configuration file.
If MongoDB is using Native LDAP authentication where the LDAP server is configured to enforce password complexity and lifetime, this is not a finding. If MongoDB is using Kerberos authentication where Kerberos is configured to enforce password complexity and lifetime, this is not a finding. If MongoDB is configured for SCRAM-SHA1, MONGODB-CR, LDAP Proxy authentication, this is a finding. See: https://docs.mongodb.com/v3.4/core/authentication/#authentication-methods
Either configure MongoDB for Native LDAP authentication where LDAP is configured to enforce password complexity and lifetime. OR Configure MongoDB Kerberos authentication where Kerberos is configured to enforce password complexity and lifetime.
MongoDB supports x.509 certificate authentication for use with a secure TLS/SSL connection. The x.509 client authentication allows clients to authenticate to servers with certificates rather than with a username and password. If X.509 authentication is not used, a SCRAM-SHA-1 authentication protocol is also available. The SCRAM-SHA-1 protocol uses one-way, salted hash functions for passwords as documented here: https://docs.mongodb.com/v3.4/core/security-scram-sha-1/ To authenticate with a client certificate, you must first add a MongoDB user that corresponds to the client certificate. See Add x.509 Certificate subject as a User as documented here: https://docs.mongodb.com/v3.4/tutorial/configure-x509-client-authentication/ To authenticate, use the db.auth() method in the $external database, specifying "MONGODB-X509" for the mechanism field, and the user that corresponds to the client certificate for the user field. If the mechanism field is not set to "MONGODB-X509", this is a finding.
Do the following: - Create local CA and signing keys. - Generate and sign server certificates for member authentication. - Generate and sign client certificates for client authentication. - Start MongoDB cluster in non-auth mode. - Set up replica set and initial users. - Restart MongoDB replica set in X.509 mode using server certificates. Example shown here for x.509 Authentication: https://www.mongodb.com/blog/post/secure-mongodb-with-x-509-authentication Additionally, SSL/TLS must be on as documented here: https://docs.mongodb.com/v3.4/tutorial/configure-ssl/
In the MongoDB database configuration file (default location: /etc/mongod.conf), review the following parameters: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/mongodbca.pem If the "CAFile" parameter is not present, this is a finding. If the "allowInvalidCertificates" parameter is found, this is a finding. net: ssl: allowInvalidCertificates: true
In the MongoDB database configuration file (default location: /etc/mongod.conf) ensure the following parameters are set and configured correctly: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/mongodbca.pem Remove any occurrence of the "allowInvalidCertificates" parameter: net: ssl: allowInvalidCertificates: true Stop/start (restart) the mongod or mongos instance using this configuration.
In the MongoDB database configuration file (default location: /etc/mongod.conf), review the following parameters: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/mongodbca.pem Verify ownership, group ownership, and permissions on the file given for PEMKeyFile (default 'mongodb.pem'). Run following command and review its output: ls -al /etc/mongod.conf typical output: -rw------- 1 mongod mongod 566 Apr 26 20:20 /etc/mongod.conf If the user owner is not "mongod", this is a finding. If the group owner is not "mongod", this is a finding. If the file is more permissive than "600", this is a finding. Verify ownership, group ownership, and permissions on the file given for CAFile (default 'ca.pem'). If the user owner is not "mongod", this is a finding. If the group owner is not "mongod", this is a finding. If the file is more permissive than "600", this is a finding.
Run these commands: "chown mongod:mongod /etc/ssl/mongodb.pem" "chmod 600 /etc/ssl/mongodb.pem" "chown mongod:mongod /etc/ssl/mongodbca.pem" "chmod 600 /etc/ssl/mongodbca.pem"
To authenticate with a client certificate, you must first add the value of the subject from the client certificate as a MongoDB user. Each unique x.509 client certificate corresponds to a single MongoDB user; i.e. you cannot use a single client certificate to authenticate more than one MongoDB user. Login to MongoDB and run the following command: use $external db.getUsers() If the output does not contain a Relative Distinguished Name (RDN) for an authorized user, this is a finding. If the output shows a Relative Distinguished Name (RDN) for users that are not authorized, this is a finding.
Add x.509 Certificate subject as an authorized user. To authenticate with a client certificate, you must first add the value of the subject from the client certificate as a MongoDB user. Each unique x.509 client certificate corresponds to a single MongoDB user; i.e. you cannot use a single client certificate to authenticate more than one MongoDB user. Note: The RDNs in the subject string must be compatible with the RFC2253 standard. Retrieve the RFC2253 formatted subject from the client certificate with the following command: openssl x509 -in <pathToClient PEM> -inform PEM -subject -nameopt RFC2253 The command returns the subject string as well as certificate: subject= CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry -----BEGIN CERTIFICATE----- # ... -----END CERTIFICATE----- Add the RFC2253 compliant value of the subject as a user. Omit spaces as needed. For example, in the mongo shell, to add the user with both the "readWrite" role in the test database and the "userAdminAnyDatabase" role which is defined only in the admin database: db.getSiblingDB("$external").runCommand( { createUser: "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry", roles: [ { role: 'readWrite', db: 'test' }, { role: 'userAdminAnyDatabase', db: 'admin' } ], writeConcern: { w: "majority" , wtimeout: 5000 } } ) In the above example, to add the user with the "readWrite" role in the test database, the role specification document specified "test" in the "db" field. To add "userAdminAnyDatabase" role for the user, the above example specified "admin" in the "db" field. Note: Some roles are defined only in the admin database, including: clusterAdmin, readAnyDatabase, readWriteAnyDatabase, dbAdminAnyDatabase, and userAdminAnyDatabase. To add a user with these roles, specify "admin" in the "db" field. See Manage Users and Roles for details on adding a user with roles. To remove a user that is not authorized run the following command: use $external db.dropUser("<RDN of user>")
If MongoDB is deployed in a classified environment: In the MongoDB database configuration file (default location: /etc/mongod.conf), search for and review the following parameters: net: ssl: FIPSMode: true If this parameter is not present in the configuration file, this is a finding. If "FIPSMode" is set to "false", this is a finding. Check the server log file for a message that FIPS is active: Search the log for the following text ""FIPS 140-2 mode activated"". If this text is not found, this is a finding. Verify that FIPS has been enabled at the operating system. The following will return "1" if FIPS is enabled: cat /proc/sys/crypto/fips_enabled If the above command does not return "1", this is a finding.
Enable FIPS 140-2 mode for MongoDB Enterprise. Edit the MongoDB database configuration file (default location: /etc/mongod.conf) to contain the following parameter setting: net: ssl: FIPSMode: true Stop/start (restart) the mongod or mongos instance using this configuration. For the operating system finding, please refer to the appropriate operating system documentation for the procedure to install, configure, and test FIPS mode.
MongoDB grants access to data and commands through role-based authorization and provides built-in roles that provide the different levels of access commonly needed in a database system. You can additionally create user-defined roles. Check a user's role to ensure correct privileges for the function: Prereq: To view a user's roles, you must have the "viewUser" privilege. Connect to MongoDB. For each database in the system, identify the user's roles for the database: use <database> db.getUser("[username]") The server will return a document with the user's roles. View a role's privileges: Prereq: To view a user's roles, you must have the "viewUser" privilege. For each database, identify the privileges granted by a role: use <database> db.getRole( "read", { showPrivileges: true } ) The server will return a document with the "privileges" and "inheritedPrivileges" arrays. The "privileges returned document lists the privileges directly specified by the role and excludes those privileges inherited from other roles. The "inheritedPrivileges" returned document lists all privileges granted by this role, both directly specified and inherited. If the role does not inherit from other roles, the two fields are the same. If a user has a role with inappropriate privileges, this is a finding.
Prereq: To view a user's roles, must have the "viewUser" privilege. Connect to MongoDB. For each database, identify the user's roles for the database. use <database> db.getUser("[username]") The server will return a document with the user's roles. To revoke a user's role from a database use the db.revokeRolesFromUser() method. To grant a role to a user use the db.grantRolesToUser() method.
Check the MongoDB configuration file (default location: /etc/mongod.conf). The following should be set: net: ssl: mode: requireSSL If this is not found in the MongoDB configuration file, this is a finding.
Follow the documentation guide at https://docs.mongodb.com/v3.4/tutorial/configure-ssl/. Stop/start (restart) and mongod or mongos using the MongoDB configuration file.
Journaling is enabled by default in 64-bit systems. With journaling enabled, if mongod stops unexpectedly, the program can recover everything written to the journal. MongoDB will re-apply the write operations on restart and maintain a consistent state. By default, the greatest extent of lost writes, i.e., those not made to the journal, are those made in the last 100 milliseconds, plus the time it takes to perform the actual journal writes. Verify the mongod process startup options. If the mongod process was started with the "--nojournal" option, this is a finding.
Modify the mongod startup command-line options by removing the "--nojournal" option. Edit the MongoDB database configuration file (default location: /etc/mongod.conf) to ensure it contains the following parameter setting: storage: journal: enabled: true Stop/start (restart) any or all mongod processes.
If the MongoDB Encrypted Storage Engines is being used, ensure that the "security.enableEncryption" option is set to "true" in the MongoDB configuration file (default location: /etc/mongod.conf) or that MongoDB was started with the "--enableEncryption" command line option. Check the MongoDB configuration file (default location: /etc/mongod.conf). If the following parameter is not present, this is a finding. security: enableEncryption: "true" If any mongod process is started with "--enableEncryption false", this is a finding.
Ensure that the MongoDB Configuration file (default location: /etc/mongod.conf) has the following set: security: enableEncryption: "true" Ensure that any mongod process that contains the option "--enableEcryption" has "true" as its parameter <boolean> value (e.g., "--enableEncryption true"). Stop/start (restart) and mongod process using either the MongoDB configuration file or that contains the "--enableEncryption" option.
Review the procedures for the refreshing of development/test data from production. Review any scripts or code that exists for the movement of production data to development/test systems, or to any other location or for any other purpose. Verify that copies of production data are not left in unprotected locations. If the code that exists for data movement does not comply with the organization-defined data transfer policy and/or fails to remove any copies of production data from unprotected locations, this is a finding.
Modify any code used for moving data from production to development/test systems to comply with the organization-defined data transfer policy, and to ensure copies of production data are not left in unsecured locations.
Verify the permissions for the following database files or directories: MongoDB default configuration file: "/etc/mongod.conf" MongoDB default data directory: "/var/lib/mongo" If the owner and group are not both "mongod", this is a finding. If the file permissions are more permissive than "755", this is a finding.
Correct the permission to the files and/or directories that are in violation. MongoDB Configuration file (default location): chown mongod:mongod /etc/mongod.conf chmod 755 /etc/mongod.conf MongoDB data file directory (default location): chown -R mongod:mongod/var/lib/mongo chmod -R 755/var/lib/mongo
As a client program assembles a query in MongoDB, it builds a BSON object, not a string. Thus traditional SQL injection attacks are not a problem. However, MongoDB operations permit arbitrary JavaScript expressions to be run directly on the server. If the "security.javascriptEnabled" option is set to "true" in the config file, this is a finding. Starting with MongoDB 3.2, database-level document validation can be configured for specific collections. Configured validation rules for the selected database can be viewed via the db.getSisterDB("database_name").getCollectionInfos() command in mongo shell. If validation is desired, but no rules are set, the valdiationAction is not "error" or the "bypassDocumentValidation" option is used for write commands on the application side, this is a finding.
Disable the javascriptEnabled option in the config file. security: javascriptEnabled: false If document validation is needed, it should be configured according to the documentation page at https://docs.mongodb.com/manual/core/document-validation/.
MongoDB operations permit arbitrary JavaScript expressions to be run directly on the server. If the following parameter is not present or not set as show below in the MongoDB configuration file (default location: /etc/mongod.conf), this is a finding. security: javascriptEnabled: "false"
Disable the "javascriptEnabled" option. Edit the MongoDB configuration file (default location: /etc/mongod.conf" to include the following: security: javascriptEnabled: false
Check custom database code to verify that error messages do not contain information beyond what is needed for troubleshooting the issue. If custom database errors contain PII data, sensitive business data, or information useful for identifying the host system or database structure, this is a finding. When attempting to login with incorrect credentials, the user will receive an error message that the operation was unauthorized. If a user is attempting to perform an operation for which they do not have privileges, the database will return an error message that the operation is not authorized.
Configure custom database code and associated application code not to divulge sensitive information or information useful for system identification in error messages.
A mongod or mongos running with "security.redactClientLogData" redacts any message accompanying a given log event before logging. This prevents the mongod or mongos from writing potentially sensitive data stored on the database to the diagnostic log. Metadata such as error or operation codes, line numbers, and source file names are still visible in the logs. Verify that the MongoDB configuration file (default location: /etc/mongod.conf) contains the following: security: redactClientLogData: "true" If this parameter is not present, this is a finding.
Edit the MongoDB configuration file (default location: /etc/mongod.conf) and add the following parameter "redactClientLogData" in the security section of that file: security: redactClientLogData: "true" Stop/start (restart) any mongod or mongos using the MongoDB configuration file.
MongoDB supports role-based access control at the collection level. If enabled, the database process should be started with "security.authorization:enabled" in the config file or with "--auth" in the command line. For documents that have been labeled (e.g., {"tag" : "classified"}), read-only views can be created and secured via access privileges such that a user can only view those documents that have a specific tag or tags (e.g., user x can only view records that are labeled with the tag of classified). Existing views can be listed using the db.getCollectionInfos() command for the selected database in mongo shell. If a view is not present for the collection requiring security labeling, this is a finding. MongoDB supports field-level redaction that allows the application to indicate to the database whether or not certain fields should be returned based on values in the field labels. If desired and aggregation queries in the application code are not using the $redact stage with appropriate logic, this is a finding.
Follow the documentation page to setup RBAC:https://docs.mongodb.com/manual/core/authorization/. For the required collections, create specific read-only views that allow access to only a subset of the data in a collection as documented here: https://docs.mongodb.com/manual/core/views/. Permissions on the view are specified separately from the permissions on the underlying collection. Use the "$redact" operator to restrict the contents of the documents based on information stored in the documents themselves as documented here: https://docs.mongodb.com/master/reference/operator/aggregation/redact/
Review the system documentation to obtain the definition of the database/DBMS functionality considered privileged in the context of the system in question. If any functionality considered privileged has access privileges granted to non-privileged users, this is a finding.
Revoke any roles with unnecessary privileges to privileged functionality by executing the revoke command as documented here: https://docs.mongodb.com/v3.4/reference/method/db.revokeRolesFromUser/ Revoke any unnecessary privileges from any roles by executing the revoke command as document here: https://docs.mongodb.com/v3.4/reference/method/db.revokePrivilegesFromRole/ If a new role with associated privileges needs to be created, follow the documentation here: https://docs.mongodb.com/v3.4/reference/command/createRole/
MongoDB can be configured to write audit events to the syslog in Linux, but this is not available in Windows. Audit events can also be written to a file in either JSON on BSON format. Through the use of third-party tools or via syslog directly, audit records can be pushed to a centralized log management system. If a centralized tool for log management is not installed and configured to collect audit logs or syslogs, this is a finding.
Install a centralized syslog collecting tool and configured it as instructed in its documentation. To enable auditing and print audit events to the syslog in JSON format, specify the syslog for the --auditDestination setting: mongod --dbpath data/db --auditDestination syslog Alternatively, these options can also be specified in the configuration file: storage: dbPath: data/db auditLog: destination: syslog
Investigate whether there have been any incidents where MongoDB ran out of audit log space since the last time the space was allocated or other corrective measures were taken. If there have been incidents where MongoDB ran out of audit log space, this is a finding. A MongoDB audit log that is configured to be stored in a file is identified in the MongoDB configuration file (default: /etc/mongod.conf) under the "auditLog:" key and subkey "destination:" where "destination" is "file". If this is the case then the "AuditLog:" subkey "path:" determines where (device/directory) that file will be located. View the mongodb configuration file (default location: /etc/mongod.conf) and identify how the "auditlog.destination" is configured. When the "auditlog.destination" is "file", this is a finding.
View the mongodb configuration file (default location: /etc/mongod.conf) and view the "auditlog.path" to identify the storage volume. Allocate sufficient space to the storage volume hosting the file identified in the MongoDB configuration "auditLog.path" to support audit file peak demand.
A MongoDB audit log that is configured to be stored in a file is identified in the MongoDB configuration file (default: /etc/mongod.conf) under the "auditLog:" key and subkey "destination:" where "destination" is "file". If this is the case then the "AuditLog:" subkey "path:" determines where (device/directory) that file will be located. View the mongodb configuration file (default location: /etc/mongod.conf) and identify how the "auditlog.destination" is configured. When the "auditlog.destination" is "file", this is a finding.
View the mongodb configuration file (default location: /etc/mongod.conf) and view the "auditlog.path" to identify the storage volume. Install MongoDB Ops Manager or other organization approved monitoring software. Configure the required alert in the monitoring software to send an alert where storage volume holding the auditLog file utilization reaches 75%.
If MongoDB supports only software development, experimentation, and/or developer-level testing (that is, excluding production systems, integration testing, stress testing, and user acceptance testing), this is not a finding. Review the MongoDB security settings with respect to non-administrative users' ability to create, alter, or replace functions or views. These MongoDB commands can help with showing existing roles and permissions of users of the databases. db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true }) If any such permissions exist and are not documented and approved, this is a finding.
Revoke any roles with unnecessary privileges to privileged functionality by executing the revoke command. Revoke any unnecessary privileges from any roles by executing the revoke command. Create, as needed, new role(s) with associated privileges.
Review the security configuration of the MongoDB database(s). If unauthorized users can start the mongod or mongos processes or edit the MongoDB configuration file (default location: /etc/mongod.conf), this is a finding. If MongoDB does not enforce access restrictions associated with changes to the configuration of the database(s), this is a finding. To assist in conducting reviews of permissions, the following MongoDB commands describe permissions of databases and users: Permissions of concern in this respect include the following, and possibly others: - any user with a role of userAdminAnyDatabase role or userAdmin role - any database or with a user have a role or privilege with "C" (create) or "w" (update) privileges that are not necessary MongoDB commands to view roles in a particular database: db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true })
Prereq: To view a user's roles, must have the "viewUser" privilege. https://docs.mongodb.com/v3.4/reference/privilege-actions/ Connect to MongoDB. For each database, identify the user's roles for the database. use <database> db.getUser("[username]") The server will return a document with the user's roles. To revoke a user's role from a database use the db.revokeRolesFromUser() method. https://docs.mongodb.com/v3.4/reference/method/db.revokeRolesFromUser/ To grant a role to a user use the db.grantRolesToUser() method. https://docs.mongodb.com/v3.4/reference/method/db.grantRolesToUser/
If organization-defined circumstances or situations require reauthentication, and these situations are not configured to terminate existing logins to require reauthentication, this is a finding.
Determine the organization-defined circumstances or situations that require reauthentication and ensure that the mongod and mongos processes are stopped/started (restart).
If MongoDB is configured to authenticate using SASL and LDAP/Active Directory check the saslauthd command line options in the system boot script that starts saslauthd (the location will be dependent on the specific Linux operating system and boot script layout and naming conventions). If the "-t" option is not set for the "saslauthd" process in the system boot script, this is a finding. If any mongos process is running (a MongoDB shared cluster) the "userCacheInvalidationIntervalSecs" option can be used to specify the cache timeout. The default is "30" seconds and the minimum is "1" second.
If MongoDB is configured to authenticate using SASL and LDAP/Active Directory modify and restart the saslauthd command line options in the system boot script and set the "-t" option to the appropriate timeout in seconds. From the Linux Command line (with root/sudo privs) run the following command to restart the saslauthd process after making the change for the "-t" parameter: systemctl restart saslauthd If any mongos process is running (a MongoDB shared cluster) the "userCacheInvalidationIntervalSecs" option to adjust the timeout in seconds can be changed from the default "30" seconds. This is accomplished by modifying the mongos configuration file (default location: /etc/mongos.conf) and then restarting mongos.
To run MongoDB in SSL mode, you have to obtain a valid certificate singed by a single certificate authority. Before starting the MongoDB database in SSL mode, verify that certificate used is issued by a valid DoD certificate authority (openssl x509 -in <path_to_certificate_pem_file> -text | grep -i "issuer"). If there is any issuer present in the certificate that is not a DoD approved certificate authority, this is a finding.
Remove any certificate that was not issued by an approved DoD certificate authority. Contact the organization's certificate issuer and request a new certificate that is issued by a valid DoD certificate authorities.
Review the documentation and/or specification for the organization-defined information. If any data is PII, classified or is deemed by the organization to be encrypted at rest, this is a finding. Verify the mongod command line contain the following options: --enableEncryption --kmipServerName <KMIP Server HostName> --kmipPort <KMIP server port> --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem If these above options are not part of the mongod command line, this is a finding. Items in the <> above and starting with kmip* are specific to the KMIP appliance and need to be set according to the KMIP appliance configuration.
Configure MongoDB to use the Encrypted Storage Engine and a KMIP appliance as documented here: https://docs.mongodb.com/v3.4/core/security-encryption-at-rest/ https://docs.mongodb.com/v3.4/tutorial/configure-encryption/
Review the system information/specification for information indicating a strict requirement for data integrity and confidentiality when data is being prepared to be transmitted. If such information is absent therein, this is not a finding. If such information is present, inspect the MongoDB configuration file (default location: /etc/mongod.conf) for the following entries: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem If net.ssl.mode is not set to "requireSSL", this is a finding.
Stop the MongoDB instance if it is running. Obtain a certificate from a valid DoD certificate authority to be used for encrypted data transmission. Modify the MongoDB configuration file with ssl configuration options such as: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem Set "net.ssl.mode" to the "requireSSL". Set "net.ssl.KeyFile" to the full path of the certificate (.pem) file. Start/stop (restart) all mongod or mongos instances using the MongoDB configuration file (default location: /etc/mongod.conf).
If the data owner does not have a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process, this is not a finding. If such strict requirement for ensure data integrity and confidentially is present, inspect the MongoDB configuration file (default location: /etc/mongod.conf) for the following entries: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem If net.ssl.mode is not set to "requireSSL", this is a finding.
Obtain a certificate from a valid DoD certificate authority to be used for encrypted data transmission. Modify the MongoDB configuration file (default location: /etc/mongod.conf) with the network configuration options. net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem Set "net.ssl.mode" to the "requireSSL". Set "net.ssl.KeyFile" to the full path of the certificate (.pem) file. Start/stop (restart) all mongod or mongos instances using the MongoDB configuration file (default location: /etc/mongod.conf).
As a user with the "dbAdminAnyDatabase" role, execute the following on the database of interest: use myDB db.getCollectionInfos() Where "myDB" is the name of the database on which validator rules are to be inspected. This returns an array of documents containing all collections information within myDB. For each collection's information received. If the "options" sub-document within each does not contain a "validator" sub-document, this is a finding.
Document validation can be added at the time of creation of a collection. Existing collections can also be modified with document validation rules. Use the "validator" option to create or update a collection with the desired validation rules.
For the MongoDB command-line tools "mongo shell", "mongodump", "mongorestore", "mongoimport", "mongoexport", which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation, verify that the system documentation explains the need for the tool, who uses it, and any relevant mitigations and that AO approval has been obtained. If it is not documented, this is a finding. Request evidence that all users of these MongoDB command-line tools are trained in the use of the "-p" option plain-text password option and how to keep the password protected from unauthorized viewing/capture and that they adhere to this practice. If evidence of training does not exist, this is a finding.
For the "mongo shell", "mongodump", "mongorestore", "mongoimport", "mongoexport", which can accept a plain-text password, and any other essential tool with the same limitation: Document the need for it, who uses it, and any relevant mitigations, and obtain AO approval. Train all users of the tool in the nature of using the plain-text password option and in how to keep the password protected from unauthorized viewing/capture and document they have been trained.
Review the MongoDB documentation and configuration to determine it is configured in accordance with DoD security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs. If the MongoDB is not configured in accordance with security configuration settings, this is a finding.
Configure MongoDB in accordance with security configuration settings by reviewing the Operation System and MongoDB documentation and applying the necessary configuration parameters to meet the configurations required by the STIG, NSA configuration guidelines, CTOs, DTMs, and IAVMs.
To determine the current running MongoDB server version, run the following command from the Mongo Shell: db.version() MongoDB 3.x is no longer supported by the vendor. If the system is running MongoDB 3.x, this is a finding.
Remove or decommission all unsupported software products. Upgrade unsupported DBMS or unsupported components to a supported version of the product.