# Ensure Security Groups do not allow unrestricted ingress access to Redis port 6379 - Source: https://support.icompaas.com/support/solutions/articles/a_1786022635580375-ensure-security-groups-do-not-allow-unrestricted-ingress-access-to-redis-port-6379 - 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 the Redis service (TCP port 6379) from any IPv4 (0.0.0.0/0) or IPv6 (::/0) address. Redis instances should only be accessible from trusted application servers, private networks, VPN gateways, or other authorized sources. Restricting access to Redis prevents unauthorized users from accessing in-memory data stores and reduces the risk of data exposure or compromise. Rationale: Redis is designed to operate within trusted networks and should never be exposed directly to the public Internet. Unrestricted access to Redis can allow attackers to read, modify, or delete cached data, execute unauthorized commands, or exploit misconfigured Redis instances. This check helps: - Prevent unauthorized access to Redis databases. - Reduce the risk of data leakage and manipulation. - Limit Redis access to trusted application servers and internal networks. - Meet security best practices recommended by industry compliance standards. Impact: - Reduces the attack surface of Redis deployments. - Prevents Internet-based scanning and exploitation of Redis services. - Improves the security posture of cloud-hosted applications. - Clients connecting from unauthorized networks will be unable to access Redis until their IP addresses are explicitly allowed. Default Value: Utho Cloud Security Groups do not automatically restrict access to Redis. If administrators create an inbound rule allowing TCP port 6379 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. - Redis servers or compute instances protected by Security Groups. Remediation Steps: 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 = 6379 - Source = 0.0.0.0/0 (or ALL)           OR - Source = ::/0 (or ALL) If an unrestricted Redis 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: 6379 - Source: 0.0.0.0/0 or ::/0 6. Delete the unrestricted Redis rule. 6. Create a new inbound rule allowing access only from: - Application server Security Groups. - Private VPC/Subnet CIDR ranges. - VPN gateway IP ranges. - Specific trusted administrator or management IP addresses (if administrative access is required). 7. Save the Security Group. 8. Verify Redis connectivity from authorized clients only. Using the Utho API Delete the unrestricted Redis 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 Redis rule. curl -s -X POST \\ \-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ \-H "Content-Type: application/json" \\ \-d '{   "type":"incoming",  "service":"Redis",  "protocol":"TCP",  "port":"6379",  "addresses":"10.0.0.0/16"}' \\ https://api.utho.com/v2/firewall//rule/add 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 Redis rule if legitimate application connectivity is interrupted. 5. Verify Redis 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.