Skip to main content

πŸ“ Azure Network Security Group allows public access to SSH port 🟒

  • Contextual name: πŸ“ Security Group allows public access to SSH port 🟒
  • ID: /ce/ca/azure/virtual-network/security-group-allows-unrestricted-ssh-traffic
  • Located in: πŸ“ Azure Virtual Network

Flags​

Our Metadata​

  • Policy Type: COMPLIANCE_POLICY
  • Policy Category:
    • SECURITY

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
βœ‰οΈ dec-x-4c15a09f2

Logic​

Description​

Open File

Description​

Ensure that Azure Network Security Groups are not configured to allow unrestricted inbound access to the Secure Shell (SSH) port (TCP 22). SSH is widely used for remote management of Linux-based systems. Leaving SSH ports open to the public internet increases the risk of brute-force attacks, credential theft, and unauthorized system access.

Rationale​

Restricting SSH access through NSGs is a critical step in reducing the attack surface of Azure Network Security Groups (VMs). Public exposure of SSH enables malicious actors to attempt automated attacks, exploit misconfigurations, or leverage stolen credentials. Access to SSH should be limited to trusted IP ranges or secured through bastion hosts or private connectivity methods.

Impact​

Blocking public access to SSH may disrupt workflows that involve direct internet-based remote management. It is important to transition to secure access alternatives, such as VPN tunnels or Azure Bastion, to maintain administrative capabilities without exposing sensitive management ports to external threats.

... see more

Remediation​

Open File

Remediation​

Modify or Remove Insecure NSG Rule​

Review the security rules associated with the relevant Network Security Group (NSG) and determine whether they are required. Take appropriate action based on necessity and scope:

  • If the rule is not required: Remove the rule entirely.

  • If the rule is required but overly permissive: Update the rule to narrowly scope access, restricting the source IP range to only what is strictly necessary.

Azure CLI​
  1. Delete the rule:

    az network nsg rule delete \
    --resource-group {{resource-group-name}} \
    --nsg-name {{nsg-name}} \
    --name {{rule-name}}
  2. Restrict the rule:

    az network nsg rule update \
    --resource-group {{resource-group-name}} \
    --nsg-name {{nsg-name}} \
    --name {{rule-name}} \
    --source-address-prefixes {{trusted-cidr}}

    Replace placeholders with the appropriate values. Use space-separated values for multiple source prefixes or destination ports (e.g., --source-address-prefixes "1.2.3.4/32 5.6.7.8/32").

... see more

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlags
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 36c deployment and environment management β€”development, test and production environments are appropriately segregated and enforce segregation of duties;23
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 36d access management controls β€”only authorised users, software and hardware are able to access information assets (refer to Attachment B for further guidance);1314
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 36e hardware and software asset controls β€”appropriate authorisation to prevent security compromises from unauthorised hardware and software assets;1516
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 36f network design β€” to ensure authorised network traffic flows and to reduce the impact of security compromises;2628
πŸ’Ό APRA CPG 234 β†’ πŸ’Ό 45 An understanding of plausible worst case scenarios can help regulated entities identify and implement additional controls to prevent or reduce the impact of such scenarios. One example is malware that infects computers and encrypts data, both on the infected computer and any connected storage, including (corporate) networks and cloud storage. Such attacks reinforce the importance of protecting the backup environment in the event that the production environment is compromised. Common techniques to achieve this include network segmentation, highly restricted and segregated access controls and network traffic flow restrictions.3235
πŸ’Ό CIS Azure v1.1.0 β†’ πŸ’Ό 6.1 Ensure that RDP access is restricted from the internet πŸ”΄12πŸ”΄ x1
πŸ’Ό CIS Azure v1.3.0 β†’ πŸ’Ό 6.1 Ensure that RDP access is restricted from the internet - Level 1 (Automated) πŸ”΄12πŸ”΄ x1
πŸ’Ό CIS Azure v1.4.0 β†’ πŸ’Ό 6.1 Ensure that RDP access is restricted from the internet - Level 1 (Automated) πŸ”΄12πŸ”΄ x1
πŸ’Ό CIS Azure v1.5.0 β†’ πŸ’Ό 6.1 Ensure that RDP access from the Internet is evaluated and restricted - Level 1 (Automated) πŸ”΄12πŸ”΄ x1
πŸ’Ό CIS Azure v2.0.0 β†’ πŸ’Ό 6.1 Ensure that RDP access from the Internet is evaluated and restricted - Level 1 (Automated) πŸ”΄12πŸ”΄ x1
πŸ’Ό CIS Azure v2.1.0 β†’ πŸ’Ό 6.1 Ensure that RDP access from the Internet is evaluated and restricted - Level 1 (Automated) πŸ”΄12πŸ”΄ x1
πŸ’Ό CIS Azure v3.0.0 β†’ πŸ’Ό 7.1 Ensure that RDP access from the Internet is evaluated and restricted (Automated) πŸ”΄2πŸ”΄ x1
πŸ’Ό Cloudaware Framework β†’ πŸ’Ό Public and Anonymous Access69
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-3 Access Enforcement (L)(M)(H)3546
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό AC-4(21) Physical or Logical Separation of Information Flows (M)(H)1138
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό CM-7 Least Functionality (L)(M)(H)31620
πŸ’Ό FedRAMP High Security Controls β†’ πŸ’Ό SC-7(5) Deny by Default β€” Allow by Exception (M)(H)18
πŸ’Ό FedRAMP Low Security Controls β†’ πŸ’Ό AC-3 Access Enforcement (L)(M)(H)46
πŸ’Ό FedRAMP Low Security Controls β†’ πŸ’Ό CM-7 Least Functionality (L)(M)(H)17
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-3 Access Enforcement (L)(M)(H)46
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό AC-4(21) Physical or Logical Separation of Information Flows (M)(H)38
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό CM-7 Least Functionality (L)(M)(H)320
πŸ’Ό FedRAMP Moderate Security Controls β†’ πŸ’Ό SC-7(5) Deny by Default β€” Allow by Exception (M)(H)18
πŸ’Ό ISO/IEC 27001:2013 β†’ πŸ’Ό A.9.4.1 Information access restriction1719
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 6.7 Remote working34
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 8.1 User end point devices710
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 8.16 Monitoring activities34
πŸ’Ό ISO/IEC 27001:2022 β†’ πŸ’Ό 8.22 Segregation of networks34
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties1534
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.DS-5: Protections against data leaks are implemented4150
πŸ’Ό NIST CSF v1.1 β†’ πŸ’Ό PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles (e.g. concept of least functionality)213
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties57
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected81
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected68
πŸ’Ό NIST CSF v2.0 β†’ πŸ’Ό PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected66
πŸ’Ό NIST SP 800-53 Revision 5 β†’ πŸ’Ό AC-4(21) Information Flow Enforcement _ Physical or Logical Separation of Information Flows3338
πŸ’Ό NIST SP 800-53 Revision 5 β†’ πŸ’Ό SC-7(5) Boundary Protection _ Deny by Default β€” Allow by Exception318
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.7710
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.57
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.7
πŸ’Ό PCI DSS v3.2.1 β†’ πŸ’Ό 1.3.5 Permit only β€œestablished” connections into the network.7
πŸ’Ό PCI DSS v4.0.1 β†’ πŸ’Ό 1.4.1 NSCs are implemented between trusted and untrusted networks.9
πŸ’Ό PCI DSS v4.0.1 β†’ πŸ’Ό 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.7
πŸ’Ό PCI DSS v4.0 β†’ πŸ’Ό 1.4.1 NSCs are implemented between trusted and untrusted networks.9
πŸ’Ό PCI DSS v4.0 β†’ πŸ’Ό 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.7
πŸ’Ό SOC 2 β†’ πŸ’Ό CC6.6-1 Restricts Access1515
πŸ’Ό UK Cyber Essentials β†’ πŸ’Ό 1.2 Prevent access to the administrative interface from the internet3336