# Ensure Security Groups do not allow unrestricted ingress access to Postgres port 5432

- Source: https://support.icompaas.com/support/solutions/articles/a_1786022707943973-ensure-security-groups-do-not-allow-unrestricted-ingress-access-to-postgres-port-5432
- 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 PostgreSQL service (TCP port 5432) from any IPv4 (0.0.0.0/0) or IPv6 (::/0) address. PostgreSQL database servers should only be accessible from trusted application servers, private networks, VPN gateways, or authorized administrator IP addresses. Restricting PostgreSQL access minimizes the risk of unauthorized database access, data breaches, and service compromise.

  

Rationale:

Exposing PostgreSQL directly to the Internet significantly increases the risk of unauthorized access, brute-force attacks, credential theft, and exploitation of database vulnerabilities. PostgreSQL servers should only accept connections from trusted systems that require database access.

This check helps:

-   Prevent unauthorized access to PostgreSQL databases.
    
-   Reduce the risk of data theft, 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 PostgreSQL database servers.
    
-   Prevents Internet-based scanning and attacks targeting PostgreSQL services.
    
-   Improves the overall security posture of cloud-hosted databases.
    
-   Clients connecting from unauthorized networks will be unable to access the database until their IP addresses are explicitly allowed.
    

  

Default Value:

Utho Cloud Security Groups do not automatically restrict PostgreSQL access. If administrators create an inbound rule allowing TCP port 5432 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.
    
-   PostgreSQL servers or compute instances protected by Security Groups.
    

  

Default Value:

Utho Cloud Security Groups do not automatically restrict POstgres SQL access. If administrators create an inbound rule allowing TCP port 3306 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.
    
-   Postgres SQL 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 = 5432
    
-   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/<FIREWALL\_ID>

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: 5432
    
-   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/<FIREWALL\_ID>/rule/<RULE\_ID>/delete

Create a restricted Redis rule.

curl -s -X POST \\  
\-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\  
\-H "Content-Type: application/json" \\  
\-d '{  
  "type":"incoming",  
  "protocol":"TCP",  "port":"5432",  "addresses":"10.0.0.0/16"}' \\  
https://api.utho.com/v2/firewall/<FIREWALL\_ID>/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 Postgres SQL rule if legitimate application connectivity is interrupted.
    
5.  Verify Postgres SQL 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.