# Ensure Security Groups do not allow unrestricted ingress access to MongoDB ports 27017 and 27018 - Source: https://support.icompaas.com/support/solutions/articles/a_1786022719488564-ensure-security-groups-do-not-allow-unrestricted-ingress-access-to-mongodb-ports-27017-and-27018 - Section: [Solutions](https://support.icompaas.com/support/solutions) › [Utho Cloud](https://support.icompaas.com/support/solutions/c_1786022244474917) › [Utho Checks](https://support.icompaas.com/support/solutions/folders/utho-checks) - Last updated: 2026-08-06 - Publisher: iCompaas, Inc. (https://www.icompaas.com) Description: This check verifies that no Utho Cloud Security Group permits unrestricted inbound access to MongoDB services on TCP ports 27017 and 27018 from any IPv4 (0.0.0.0/0) or IPv6 (::/0) address. MongoDB instances should only be accessible from trusted application servers, private networks, VPN gateways, or authorized administrator IP addresses. Restricting MongoDB access minimizes the risk of unauthorized database access, data exposure, and service compromise. Rationale: MongoDB databases exposed directly to the Internet have historically been frequent targets of unauthorized access, ransomware attacks, and data theft. Allowing unrestricted access to MongoDB ports significantly increases the risk of compromise. This check helps: - Prevent unauthorized access to MongoDB databases. - Reduce the risk of data leakage, modification, or deletion. - Restrict database connectivity to trusted application servers and internal networks. - Meet security best practices recommended by industry compliance standards. Impact: - Reduces the attack surface of MongoDB database servers. - Prevents Internet-based scanning and attacks targeting MongoDB services. - Improves the overall security posture of cloud-hosted databases. - Clients connecting from unauthorized networks will be unable to access MongoDB until their IP addresses are explicitly allowed. Default Value: Utho Cloud Security Groups do not automatically restrict MongoDB access. If administrators create an inbound rule allowing TCP ports 27017 or 27018 from 0.0.0.0/0 or ::/0, the Security Group is considered non-compliant. Pre-requisites: - Utho Cloud account. - Permissions to view and manage Security Groups. - Access to the Utho Cloud Console or Utho API. - MongoDB servers or compute instances protected by Security Groups. Test Plan: Using the Utho Cloud Console 1. Sign in to the Utho Cloud Console. 2. Navigate to Networking → Security Groups. 3. Select each Security Group. 4. Review all inbound (Ingress) rules. 5. Verify that no rule exists with: - Protocol = TCP - Port = 27017 or 27018 - Source = 0.0.0.0/0 (or ALL)                              OR - Source = ::/0 (or ALL) If an unrestricted MongoDB rule exists, the Security Group is non-compliant. Using the Utho API List all Security Groups (Firewalls). curl -s -H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ https://api.utho.com/v2/firewall Retrieve the details of each Security Group. curl -s -H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ https://api.utho.com/v2/firewall/ Implementation Plan: Using the Utho Cloud Console 1. Log in to the Utho Cloud Console. 2. Navigate to Networking → Security Groups. 3. Select the non-compliant Security Group and click Manage. 4. Locate the inbound rule allowing: - Protocol: TCP - Port: 27017 or 27018 - Source: 0.0.0.0/0 or ::/0 6. Delete the unrestricted MongoDB rule. 6. Create new inbound rules allowing access only from: - Application server Security Groups. - Private VPC/Subnet CIDR ranges. - VPN gateway IP ranges. - Specific trusted administrator IP addresses (if administrative access is required). 7. Save the Security Group. 8. Verify MongoDB connectivity from authorized clients only. Using the Utho API Delete the unrestricted MongoDB rule using the Rule ID obtained from the firewall details. curl -s -X DELETE \\ \-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ https://api.utho.com/v2/firewall//rule//delete Create a restricted MongoDB rule. curl -s -X POST \\ \-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ \-H "Content-Type: application/json" \\ \-d '{   "type":"incoming",  "service":"MongoDB",  "protocol":"TCP",  "port":"27017",  "addresses":"10.0.0.0/16"}' \\ https://api.utho.com/v2/firewall//rule/add If MongoDB uses port 27018, create an additional rule for port 27018 with the same trusted source restrictions. Replace 10.0.0.0/16 with your organization's trusted private network or approved CIDR range. Backout Plan: 1. Log in to the Utho Cloud Console. 2. Navigate to Networking → Security Groups. 3. Select the modified Security Group. 4. Restore the previous MongoDB rule if legitimate application connectivity is interrupted. 5. Verify MongoDB connectivity. 6. Replace the temporary rule with one that restricts access to trusted private networks or approved IP ranges, rather than allowing unrestricted Internet access. References: - [Utho Docs - Deploy Firewall](https://utho.com/docs/products/networking/firewall/how-tos/deploy-firewall/) - [Utho Docs - Delete Rules](https://utho.com/docs/products/networking/firewall/how-tos/delete-rules/) - [Utho Docs - VPC (Virtual Private Cloud)](https://utho.com/docs/products/networking/vpc/) - [Utho Docs - API Token](https://utho.com/docs/products/account/api-token/) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.