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

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

  

Rationale:

Allowing unrestricted RDP access from the Internet significantly increases the risk of unauthorized access and compromise of Windows-based cloud instances.

This check helps:

-   Prevent brute-force and credential-stuffing attacks against RDP services.
    
-   Reduce the attack surface of Windows 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 Windows workloads.
    
-   Administrators connecting from unauthorized networks will be unable to access Windows instances until their IP addresses are explicitly allowed.
    

  

Default Value:

Utho Cloud Security Groups do not automatically restrict RDP access. If administrators create an inbound rule allowing TCP port 3389 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.
    
-   Windows 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 = 3389
    
-   Source = 0.0.0.0/0 (or ALL)
    

                        OR

-   Source = ::/0 (or ALL)
    

If an unrestricted RDP 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/3389 rule.

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

  

curl -s \\  
\-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\  
[https://api.utho.com/v2/firewall/](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: 3389
    
-   Source: 0.0.0.0/0 or ::/0
    

5.  Delete the rule.
    

6.  Create a new RDP 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.
    
8.  Verify Remote Desktop connectivity from authorized locations.
    

  

Using the Utho API

Delete the open RDP rule (using the rule ID obtained from the GET request), then add a source-restricted replacement.

Delete the existing rule:

  
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 RDP rule:

curl -s -X POST \\  
\-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\  
\-H "Content-Type: application/json" \\  
\-d '{  
  "type":"incoming",  "service":"RDP",  "protocol":"TCP",  "port":"3389",  "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 RDP rule if legitimate administrative access is interrupted.
    
5.  Verify Remote Desktop 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.
