# Ensure no security groups allow ingress from all IPs to SSH Port in Utho

- Source: https://support.icompaas.com/support/solutions/articles/a_1786022496139147-ensure-no-security-groups-allow-ingress-from-all-ips-to-ssh-port-in-utho
- 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 SSH access (TCP port 22) from any IPv4 (0.0.0.0/0) or IPv6 (::/0) address. SSH should only be accessible from trusted IP addresses, corporate networks, VPN gateways, or bastion hosts. Restricting SSH access minimizes the exposure of administrative interfaces to unauthorized users and automated attacks.

  

Rationale:

Allowing unrestricted SSH access from the Internet significantly increases the risk of unauthorized access and compromise of cloud resources.

This check helps:

-   Prevent brute-force and credential-stuffing attacks against SSH services.
    
-   Reduce the attack surface of cloud instances.
    
-   Restrict administrative access to trusted networks.
    
-   Meet security best practices recommended by industry compliance standards.
    

  

Impact:

-   Reduces the likelihood of unauthorized administrative access.
    
-   Minimizes exposure to Internet-based scanning and brute-force attacks.
    
-   Improves the overall security posture of cloud workloads.
    
-   Administrators connecting from unauthorized networks will be unable to access instances until their IP addresses are explicitly allowed.
    

  

Default Value:

Utho Cloud Security Groups do not automatically restrict SSH access. If administrators create an inbound rule allowing TCP port 22 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.
    
-   Compute instances protected by Security Groups.
    

  

Test Plan:

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 = 22
    
-   Source = 0.0.0.0/0 (or) ALL
    
-   OR Source = ::/0 (or) ALL
    

6.  If an unrestricted SSH rule exists, follow the implementation steps.
    

  

Using the Utho API:

List every firewall, then inspect each firewall's rules array for an open incoming TCP/22 rule.

curl -s -H "Authorization: Bearer $UTHO\_API\_TOKEN" https://api.utho.com/v2/firewall

  

curl -s -H "Authorization: Bearer $UTHO\_API\_TOKEN" https://api.utho.com/v2/firewall/<FIREWALL\_ID>

Fail if any object in the firewall's rules\[\] has type=incoming, protocol=TCP, port=22, and addresses=0.0.0.0/0 (or ::/0). Pass if port 22 is absent from incoming rules or every such rule lists a specific trusted CIDR.

Implementation Plan:

1.  Log in to the Utho Cloud Console.
    
2.  Navigate to Networking → Security Groups.
    

3.  Select the non-compliant Security Group and click on Manage.
    

4.  Locate the inbound rule allowing:
    

-   Protocol: TCP
    
-   Port: 22
    
-   Source: 0.0.0.0/0 or ::/0
    

6.  Delete the rule.
    

6.  Create a new SSH rule allowing access only from:
    

-   Corporate public IP addresses.
    
-   VPN gateway IP ranges.
    
-   Bastion host IP addresses.
    
-   Specific administrator IP addresses.
    

7.  Save the Security Group.
    

  

Using the Utho API:

Delete the open rule (using the rule id from the GET above) and add a source-restricted replacement.

curl -s -X DELETE -H "Authorization: Bearer $UTHO\_API\_TOKEN" [https://api.utho.com/v2/firewall/](https://api.utho.com/v2/firewall/)<FIREWALL\_ID>/rule/<RULE\_ID>/delete

  

curl -s -X POST -H "Authorization: Bearer $UTHO\_API\_TOKEN" -H "Content-Type: application/json" -d '{"type":"incoming","service":"SSH","protocol":"TCP","port":"22","addresses":"203.0.113.10/32"}' https://api.utho.com/v2/firewall/<FIREWALL\_ID>/rule/add

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 SSH rule if legitimate administrative access is interrupted.
    
5.  Verify SSH connectivity.
    
6.  Update the rule later with the correct trusted IP ranges instead of 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 - Update Firewall (Cloud instance)](https://utho.com/docs/products/compute/cloud/how-tos/update-firewall/)
    
-   [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.