Ensure management ports are restricted from the internet

Overview

Network security groups should be periodically evaluated for port misconfigurations. Where certain ports and protocols may be exposed to the Internet, they should be evaluated for necessity and restricted wherever they are not explicitly required.

Rationale

The potential security problem with using SSH over the Internet is that attackers can use various brute force techniques to gain access to Virtual Machines. Once the attackers gain access, they can use a virtual machine as a launch point for compromising other machines on the Network or even attack networked devices outside of the Cloud.

Remediation guidance

AWS

Check your EC2 security groups for inbound rules that allow unrestricted access (i.e. 0.0.0.0/0 or ::/0) to TCP port 22. Restrict access to only those IP addresses that require it, in order to implement the principle of least privilege and reduce the possibility of a breach.

Perform the following to implement the prescribed state:

Login to the AWS Management Console at https://console.aws.amazon.com/vpc/home
In the left pane, click Security Groups
For each security group, perform the following:
Select the security group
Click the Inbound Rules tab
Identify the rules to be removed
Click the x in the Remove column
Click Save

Impact

For updating an existing environment, care should be taken to ensure that administrators currently relying on an existing ingress from 0.0.0.0/0 have access to ports 22 and/or 3389 through another security group.

References:

Security groups: inbound and outbound rules

Azure

Where SSH is not explicitly required and narrowly configured for resources attached to the Network Security Group, Internet-level access to your Azure resources should be restricted or eliminated.

From Azure Console

Go to Virtual Machines
For each virtual machine you want to restrict SSH for, under Settings, go to Networking
In the list of inbound port rules, delete any Allow rule with port 22 and with Source as Any, Internet or 0.0.0.0/0. Review all Allow rules with port 22 that have static IPs and remove the ones that are not necessary.

After direct SSH access from the Internet is disabled, you have other options you can use to access these virtual machines for remote management:

By default, SSH access from the internet is not enabled.

References:

Google Cloud

From Console

Go to VPC Network.
Go to the Firewall Rules.
Click the Firewall Rule you want to modify.
Click Edit.
Modify Source IP ranges to specific IP.
Click Save.

**Via CLI gcloud **

Update Firewall rule with new SOURCE_RANGE from below command:

gcloud compute firewall-rules update FirewallName --allow=[PROTOCOL[:PORT[-PORT]]] --source-range=[CIDR_RANGE]

Impact

All SSH connections from outside of the network to the concerned VPC(s) will be blocked. There could be a business need where ssh access is required from outside of the network to access resources associated with the VPC. In that case, specific source IP(s) should be mentioned in firewall rules to white-list access to SSH port for the concerned VPC(s).

References

https://cloud.google.com/vpc/docs/firewalls#blockedtraffic

Notes

Currently Google Cloud VPC only supports IPV4 however, Google is already working on adding IPV6 support for VPC. In that case along with source IP range 0.0.0.0, rule should be checked for IPv6 equivalent ::0 as well.

Alibaba

Similar with Azure, you have to check your Elastic Compute Services (ECS) security groups for inbound rules that allow unrestricted access (i.e. 0.0.0.0/0 or ::/0) to TCP port 22.

References:

Security groups for different use cases

Multiple Remediation Paths

AWS

SERVICE-WIDE (RECOMMENDED when many resources are affected): Deploy centralized guardrails and remediation using AWS Config Conformance Packs and (if applicable) AWS Organizations SCPs.

aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml

ASSET-LEVEL: Apply the resource-specific remediation steps above to only the affected assets.

PREVENTIVE: Add CI/CD policy checks (CloudFormation/Terraform validation) before deployment to prevent recurrence.

Google Cloud

SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.

gcloud org-policies set-policy policy.yaml

ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.

PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.

Azure

SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.

PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.

References for Service-Wide Patterns

AWS Config Conformance Packs: https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html
AWS Organizations SCP examples: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

AWS: deploy/adjust organization conformance packs and policy guardrails.

aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml

Google Cloud: apply organization policy constraints at org/folder scope.

gcloud org-policies set-policy policy.yaml

Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

2. Remediate Existing Affected Assets

Execute the control-specific Console/CLI steps documented above for each flagged resource.
Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

Re-scan after each remediation batch.
Track exceptions with owner and expiry date.
Add preventive checks in IaC/CI pipelines.

Query logic

These are the stored checks tied to this control.

Security Groups with management ports not restricted from the internet

Connectors

Alibaba CloudAWSMicrosoft Azure

Covered asset types

SecurityGroup

Expected check: eq []

{
  securityGroups(
    where: {
      rules_SOME: {
        direction: "Inbound"
        action: "Allow"
        AND: [
          {
            OR: [
              { sources_INCLUDES: "cidr:0.0.0.0/0" }
              { sources_INCLUDES: "cidr:::/0" }
              { sources_INCLUDES: "tag:Internet" }
              { sources: [] }
            ]
          }
          { 
            OR: [
                { destFromPort_LTE: 22, destToPort_GTE: 22 }
                { destFromPort_LTE: 3389, destToPort_GTE: 3389 }
              ]
          }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}

Firewalls with management ports not restricted from the internet

Connectors

Google Cloud

Covered asset types

Firewall

Expected check: eq []

{
  firewalls(
    where: {
      rules_SOME: {
        direction: "Inbound"
        AND: [
          {
            OR: [
              { sources_INCLUDES: "cidr:0.0.0.0/0" }
              { sources_INCLUDES: "cidr:::/0" }
              { sources: [] }
            ]
          }
          {
            OR: [
              { destFromPort_LTE: 22, destToPort_GTE: 22 }
              { destFromPort_LTE: 3389, destToPort_GTE: 3389 }
            ]
          }
        ]
      }
    }
  ) {
    ...AssetFragment
  }
}

Ensure management ports are restricted from the internet

Overview

Remediation guidance

AWS

Azure

Google Cloud

Alibaba

Multiple Remediation Paths

AWS

Google Cloud

Azure

References for Service-Wide Patterns

Operational Rollout Workflow

1. Contain at Service-Wide Scope First (Recommended)

2. Remediate Existing Affected Assets

3. Validate and Prevent Recurrence

Query logic

Platform

Use Cases

Industries

Compare

Resources

Company