Skip to content
Kloudle Logo
← All terms
Glossary

Security Groups: Virtual Firewalls for Cloud Resources

Cloud security groups are virtual firewalls controlling inbound and outbound traffic to resources. Common misconfigurations like 0.0.0.0/0 on SSH are a leading breach vector.

Akash Mahajan
#security-group #cloud-misconfiguration #networking #firewall #cspm #aws

What is a Security Group?

A security group is a virtual firewall that controls inbound and outbound network traffic to cloud resources. In AWS, every EC2 instance, RDS database, Lambda function (in a VPC), and load balancer is associated with one or more security groups that define which traffic is allowed to reach it.

GCP uses “firewall rules” and Azure uses “network security groups (NSGs)” — the concept is identical: stateful packet filtering at the resource level. Security groups are the most fundamental network security control in any cloud environment.

Why It Matters

Security group misconfigurations are among the most common and most dangerous cloud security findings. They’re simple to get wrong and immediately exploitable:

  • 0.0.0.0/0 on port 22 (SSH) — Your instance is accessible to every IP address on the internet. Automated bots scan for this continuously.
  • 0.0.0.0/0 on port 3389 (RDP) — Same problem for Windows instances. Ransomware groups actively scan for open RDP.
  • 0.0.0.0/0 on database ports — PostgreSQL (5432), MySQL (3306), MongoDB (27017) exposed to the internet.
  • Overly broad egress rules — Allow all outbound traffic, enabling data exfiltration if the instance is compromised.

The 2019 Capital One breach exploited a misconfigured security group (among other issues). Open security groups appear in virtually every cloud breach post-mortem.

How It Works / Key Concepts

Security Group Basics

Security groups operate on rules:

  • Inbound rules — What traffic can reach the resource (source IP/range, port, protocol)
  • Outbound rules — What traffic the resource can send (destination IP/range, port, protocol)
  • Stateful — If inbound traffic is allowed, the response is automatically allowed (no explicit outbound rule needed)
  • Default deny — All traffic is denied unless explicitly allowed by a rule

Common Misconfigurations

MisconfigurationRiskCorrect Configuration
SSH (22) open to 0.0.0.0/0Brute force, credential stuffingRestrict to VPN/bastion IP range
RDP (3389) open to 0.0.0.0/0Ransomware entry pointRestrict to corporate IP range
All ports open to 0.0.0.0/0Full network exposureAllow only required ports and sources
Database ports internet-facingDirect data accessAllow only application subnet CIDRs
Unused security groupsConfusion, accidental attachmentDelete or document

Best Practices

  1. Principle of least access — Allow only the specific ports and source IPs required
  2. Use security group references — Instead of IP ranges, reference other security groups (e.g., “allow traffic from the web tier security group”)
  3. Separate by function — Web tier, application tier, and database tier should have distinct security groups
  4. No management ports to the internet — SSH and RDP should never be open to 0.0.0.0/0; use bastion hosts, VPN, or Session Manager
  5. Regular review — Security groups accumulate rules over time. Review quarterly.

Security Groups vs NACLs

AWS has two network controls: Security Groups (stateful, resource-level) and Network ACLs (stateless, subnet-level). Security groups are the primary control; NACLs provide defense-in-depth at the subnet boundary.

How Kloudle Helps

Kloudle checks security group configurations across AWS, GCP, Azure, and DigitalOcean — detecting open management ports, overly broad ingress rules, and unused groups. These are among the highest-severity findings in Kloudle’s 1,890 checks because they’re directly exploitable. Sovereign deployment ensures your network topology data stays within your infrastructure.

Scan Your Cloud Free →