Cloud Security Groups: AWS, GCP, Azure — Common Misconfigurations and How to Audit Them

Cloud security groups are the most commonly misconfigured component of new cloud deployments

Every major cloud breach of the past decade has a recurring pattern: legitimate cloud infrastructure, incorrectly configured network rules, a database or storage service exposed to the internet. AWS Security Groups, GCP Firewall Rules, and Azure NSGs are the tools that prevent this — but their defaults are permissive in ways that catch teams off guard.

AWS Security Groups: stateful rules

AWS Security Groups are stateful — if you allow inbound traffic on port 443, the corresponding outbound response is automatically allowed without a separate rule.

Key concepts:

• Security Groups are applied at the instance level (or ENI level)
• Only allow rules exist — there's no "deny" rule; all non-matching traffic is implicitly denied
• Rules are evaluated as a collection — if any rule matches, the traffic is allowed
• Multiple Security Groups can be attached to one instance; their rules are additive

The default Security Group problem: new AWS accounts include a default VPC with a default Security Group that allows all outbound traffic and all inbound traffic from instances in the same Security Group. This seems harmless until all your resources are accidentally in the same Security Group — now any compromised instance can reach any other.

Principle of least privilege for Security Groups:

# Bad: allow all inbound
0.0.0.0/0  :  0 - 65535  (allows everything)

# Better: allow only specific ports from specific sources
203.0.113.0/24  :  22   (SSH from your office IP range only)
10.0.0.0/8      :  3306 (MySQL from VPC internal only)
0.0.0.0/0       :  443  (HTTPS from anywhere)

GCP Firewall Rules: stateful, with priority

GCP Firewall Rules work at the VPC level rather than the instance level. Key differences from AWS:

• Priority-based: rules are processed from lowest number (highest priority) to highest. The first matching rule is applied; others are ignored.
• Tags and service accounts: rules can target specific instances by network tag or service account rather than IP range, enabling fine-grained control without knowing specific IPs.
• Default deny: GCP VPCs have an implied deny-all at priority 65535. Explicitly allow rules must be created for needed traffic.

Default rules to know:

default-allow-internal: allow all traffic within the VPC network (priority 65534)
default-allow-ssh: allow TCP 22 from 0.0.0.0/0 (priority 65534)
default-allow-rdp: allow TCP 3389 from 0.0.0.0/0 (priority 65534)

The default-allow-ssh and default-allow-rdp rules in new GCP projects allow SSH and RDP from the entire internet. These should be replaced with rules that restrict source IPs or removed in favour of SSH via Identity-Aware Proxy (IAP).

Azure Network Security Groups

Azure NSGs can be attached to subnets or individual network interfaces (NICs). Subnet-level NSGs apply to all instances in the subnet; NIC-level NSGs add per-instance rules.

Priority ranges:

• 100–4096: user-defined rules
• 65000: allow VNet inbound (traffic within the VNet)
• 65001: allow Azure Load Balancer inbound
• 65500: deny all inbound (implicit default)

Like GCP, lower priority number = higher precedence.

Default inbound rules added to every NSG:

• AllowVnetInBound (priority 65000): allows inbound from the VNet address space
• AllowAzureLoadBalancerInBound (priority 65001): allows health probes from Azure Load Balancer
• DenyAllInBound (priority 65500): denies everything not explicitly allowed

The most common cloud firewall misconfigurations

1. Database ports open to 0.0.0.0/0

The most dangerous single misconfiguration. Finding MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379), or Elasticsearch (9200/9300) accessible from the internet is an immediate critical vulnerability. Data breaches from open cloud databases number in the thousands.

The fix: database ports should only be accessible from the application subnet CIDR or specific security group IDs — never from the internet.

2. SSH open to 0.0.0.0/0 permanently

SSH should be restricted to your organisation's known IP ranges. For team environments or when IPs aren't static, use a VPN or bastion host architecture. Cloud providers offer additional options:

• AWS: EC2 Instance Connect, AWS Systems Manager Session Manager (no SSH needed)
• GCP: Identity-Aware Proxy SSH tunneling
• Azure: Azure Bastion

3. Overly broad inbound rules during testing that never get removed

"I'll open port 8080 to 0.0.0.0/0 temporarily to test the API" — and three months later, it's still open. Tagging temporary rules with expiry dates and reviewing security groups periodically catches these.

4. Using 0.0.0.0/0 for all egress

Allowing all outbound is common and often necessary for internet-dependent applications. But it also means a compromised instance can reach any internet host — useful for data exfiltration or C2 communication. Restricting egress to known required destinations limits the blast radius of a compromise.

Port scanning your own cloud infrastructure

Running regular port scans against your own cloud infrastructure is standard security practice. It answers: "What does my infrastructure look like from the internet's perspective?"

Tools:

• nmap: nmap -sT -p 1-65535 your-server-ip (TCP connect scan, all ports)
• Masscan: faster for broad scans
• Port scanner tools like sadiqbd.com's Port Scanner for quick targeted checks

Process:

1. Scan before launch: confirm only intended ports are open
2. Scan after any infrastructure changes: verify no unintended ports were opened
3. Periodic scheduled scans: catch drift from expected configuration

How to use the Port Scanner on sadiqbd.com

1. Enter your server's IP or domain
2. Select common ports or specify a range
3. Check results against your intended exposure:
   • Web: ports 80, 443
   • SSH: port 22 (should only be accessible from known IPs — if it appears open to all, check your rules)
   • Databases: should not appear open to the internet
   • Admin/management ports: should not appear open to the internet

Frequently Asked Questions

Is it legal to port scan my own cloud instances? Yes, with caveats. Major cloud providers require notification or permit scanning of instances you own. AWS allows scanning your own resources without prior approval but prohibits scanning other customers' resources. Check your provider's penetration testing policy before scanning — some providers require pre-approval.

Should I use a Web Application Firewall (WAF) in addition to security groups? WAFs and security groups protect different layers. Security groups protect at the network layer (which ports are accessible). WAFs protect at the application layer (what HTTP requests are processed). Both are valuable and complement each other.

Is the Port Scanner free? Yes — completely free, no sign-up required.

Cloud security groups and firewall rules are the first defence layer for any cloud deployment. Getting them right during initial setup and auditing them periodically costs little time and prevents the class of breaches that make headlines.

Try the Port Scanner free at sadiqbd.com — verify which ports are actually accessible on any host from the internet's perspective.