# Ensure Cloud Firewalls Do Not Allow Unrestricted RDP Access

- Source: https://support.icompaas.com/support/solutions/articles/ensure-cloud-firewalls-do-not-allow-unrestricted-rdp-access
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules)
- Last updated: 2026-08-13
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

## Description

This rule verifies that no DigitalOcean Cloud Firewall permits RDP (TCP port 3389) from an unrestricted source. DigitalOcean Cloud Firewalls are the equivalent of a security group; an unrestricted source is 0.0.0.0/0 (All IPv4) or ::/0 (All IPv6).

The rule enumerates every firewall's inbound\_rules and flags any rule whose protocol is TCP, whose ports include 3389, and whose sources include 0.0.0.0/0 or ::/0. RDP is relevant for Windows workloads run on DigitalOcean Droplets via custom images.

Remediation narrows the source of the port-3389 rule to specific administrative IPs, a VPN egress address, or a bastion host, and removes the unrestricted rule once the scoped replacement is verified.

-   Inbound TCP rules on port 3389 with source 0.0.0.0/0
    
-   Inbound TCP rules on port 3389 with source ::/0
    
-   Port-range or 'all' rules that encompass port 3389 from an unrestricted source
    

## Rationale

RDP exposed to the internet is a leading initial-access vector for ransomware and hands-on-keyboard intrusions. Automated scanners continuously enumerate hosts answering on port 3389 and follow up with credential-stuffing, password spraying, and exploitation of RDP vulnerabilities. Once an attacker authenticates, they gain an interactive desktop session on the host.

Confining RDP to a small set of trusted administrative networks removes the service from internet-wide reach and forces an attacker onto an allowed network before the service is even reachable, defeating the great majority of opportunistic campaigns.

-   RDP is a top ransomware entry point when exposed publicly
    
-   Network scoping stops brute-force and RDP exploits before authentication
    
-   Reduces exposure to protocol-level RDP vulnerabilities
    

## Impact

Pros:

-   Removes a well-known ransomware initial-access vector
    
-   Limits interactive desktop access to trusted networks
    
-   Lowers exposure to RDP protocol exploits and brute-force
    

Cons:

-   Remote administrators need a VPN, bastion, or maintained IP allow-list
    
-   Dynamic administrative IPs require ongoing allow-list maintenance
    
-   Requires inventory of who connects and from where
    

## Default Value

DigitalOcean firewalls suggest only an SSH (port 22) inbound rule on creation; no RDP rule is added by default, and firewalls deny all inbound traffic not expressly permitted, so any port-3389 exposure was added deliberately.

## Pre-Requisite

-   Control Panel access with permission to view and edit firewalls
    
-   A DigitalOcean API token or doctl authenticated for API/CLI checks
    
-   Knowledge of the administrative source IPs, VPN egress, or bastion used for RDP
    

## Remediation

### Test Plan

Using the DigitalOcean Control Panel:

1.  Sign in to cloud.digitalocean.com.
    
2.  Go to Networking, then Firewalls.
    
3.  Open each firewall and select the Rules tab.
    
4.  Under Inbound Rules, look for any Custom TCP rule whose Ports include 3389 (RDP).
    
5.  Inspect the Sources for that rule and note whether it lists 'All IPv4' and/or 'All IPv6'.
    
6.  Pass: No inbound rule allowing TCP port 3389 has a source of All IPv4 (0.0.0.0/0) or All IPv6 (::/0).
    
7.  Fail: At least one inbound rule allows TCP port 3389 from All IPv4 or All IPv6.
    

Using doctl or the API:

Enumerate firewalls and inspect inbound rules for port 3389 open to an unrestricted source.

doctl compute firewall list --format ID,Name,InboundRules

curl -s -X GET -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/firewalls" | jq '.firewalls\[\] | {id, name, offending: \[.inbound\_rules\[\] | select(.protocol=="tcp" and (.ports=="3389" or .ports=="0") and (.sources.addresses // \[\] | any(.=="0.0.0.0/0" or .=="::/0")))\]}'

Pass: the offending array is empty for every firewall. Fail: any firewall returns an inbound TCP rule covering port 3389 with a source of 0.0.0.0/0 or ::/0.

### Implementation Steps

Using the DigitalOcean Control Panel:

1.  In Networking, then Firewalls, open the firewall and select the Rules tab.
    
2.  Click Add inbound rule, choose Custom, protocol TCP, port 3389, and set Sources to your specific administrative IPs, CIDR ranges, VPN egress, or a bastion Droplet/tag.
    
3.  Save the rule and confirm RDP still works from an allowed source.
    
4.  Find the original port-3389 rule whose source is All IPv4 / All IPv6, click the … (More) menu, and choose Delete rule.
    
5.  Repeat for every firewall exposing RDP to an unrestricted source.
    

Using doctl or the API:

Add a scoped port-3389 rule, then remove the unrestricted one.

doctl compute firewall add-rules <firewall-id> --inbound-rules "protocol:tcp,ports:3389,address:203.0.113.10/32"

doctl compute firewall remove-rules <firewall-id> --inbound-rules "protocol:tcp,ports:3389,address:0.0.0.0/0"

curl -s -X POST -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -H "Content-Type: application/json" -d '{"inbound\_rules":\[{"protocol":"tcp","ports":"3389","sources":{"addresses":\["203.0.113.10/32"\]}}\]}' "https://api.digitalocean.com/v2/firewalls/<firewall-id>/rules"

curl -s -X DELETE -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -H "Content-Type: application/json" -d '{"inbound\_rules":\[{"protocol":"tcp","ports":"3389","sources":{"addresses":\["0.0.0.0/0","::/0"\]}}\]}' "https://api.digitalocean.com/v2/firewalls/<firewall-id>/rules"

### Backout Plan:

1.  If scoping breaks legitimate access, temporarily re-add the prior rule with doctl compute firewall add-rules <firewall-id> --inbound-rules "protocol:tcp,ports:3389,address:0.0.0.0/0" (or the equivalent POST /rules call).
    
2.  After confirming correct source addresses, re-apply the scoped rule and remove the unrestricted rule again.
    

## References:

1.  [DigitalOcean Cloud Firewalls overview](https://docs.digitalocean.com/products/networking/firewalls/)
    
2.  [How to Configure Firewall Rules](https://docs.digitalocean.com/products/networking/firewalls/how-to/configure-rules/)
    
3.  [Firewalls API reference](https://docs.digitalocean.com/reference/api/reference/firewalls/)
    
4.  [doctl compute firewall add-rules](https://docs.digitalocean.com/reference/doctl/reference/compute/firewall/add-rules/)
    
5.  [doctl compute firewall reference](https://docs.digitalocean.com/reference/doctl/reference/compute/firewall/)

## 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.