Stop Using `0.0.0.0/0` in Your Security Groups

The "I'll Just Open It To Debug" Incident

A few years ago, I was helping a junior dev troubleshoot why a microservice couldn't reach a legacy database instance. The logs showed a timeout. Without thinking, they updated the Security Group to allow inbound traffic from 0.0.0.0/0 on port 5432 "just to see if it works." It did. They went to lunch.

They forgot to revert the change.

Three weeks later, our AWS GuardDuty alerts went wild. A botnet had discovered the open Postgres port and was running a dictionary attack against our database credentials. We weren't breached, but we spent the next 48 hours rotating every single secret in our environment and auditing every database log line for unauthorized queries. That "temporary" fix cost us two days of production engineering time and a massive amount of unnecessary stress.

Allowing traffic from 0.0.0.0/0 is the digital equivalent of leaving your house keys in the front door lock and hoping nobody notices.

The Danger of Overly Permissive Rules

Security Groups are stateful firewalls. When you add a rule that allows 0.0.0.0/0, you are explicitly telling AWS: "I do not care who reaches this resource." In a cloud environment, your infrastructure is reachable from every corner of the planet.

Why `0.0.0.0/0` is a ticking time bomb:

Automated Scanners: There are thousands of bots scanning AWS IP ranges 24/7 for open ports like 22 (SSH), 3306 (MySQL), 5432 (Postgres), and 6379 (Redis).
Lateral Movement: If one of your services is compromised, an open security group makes it trivial for an attacker to move horizontally across your VPC.
Audit Failure: If you are subject to SOC2, ISO, or HIPAA compliance, having an ALLOW ALL rule in your ingress is an immediate audit finding.

Most engineers use 0.0.0.0/0 because they don't know the exact IP address of their ingress point or their NAT Gateway. But in AWS, you rarely need to guess.

Reference Security Groups are Your Best Friend

Instead of hardcoding CIDR blocks or using broad ranges, use Security Group Referencing. This allows you to say "only allow traffic from resources that belong to this specific Security Group."

If you have a Web Tier and a Database Tier, you don't need to know the IP address of the Web servers. You simply allow the Database Security Group to accept traffic from the Web Security Group ID.

# Example Terraform
resource "aws_security_group" "db_sg" {
  name        = "db-security-group"
  vpc_id      = var.vpc_id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.web_sg.id]
  }
}

When you scale your web tier from 2 pods to 200, you don't have to update your database rules. AWS handles the membership dynamically. This keeps your blast radius small and your configuration clean.

What I Actually Do / My Take

I treat 0.0.0.0/0 as a "stop-ship" item in code reviews. If I see it in a PR, I block it. Period.

Never Use It for Databases: Your database should never have an ingress rule for 0.0.0.0/0. Period. Use a Private Subnet and reference the Security Group of the consuming service.
Use Prefix Lists: If you absolutely must allow traffic from an external source (like a third-party API or a corporate office VPN), use an AWS Managed Prefix List. It’s easier to manage and update than hardcoding CIDR blocks across ten different security groups.
VPN/Bastion for SSH: If you are still opening port 22 to 0.0.0.0/0 for "management," stop. Use AWS Systems Manager Session Manager. It allows you to shell into instances without opening any inbound ports to the internet.
Least Privilege: Start with a "deny all" posture. Only open the ports required for the specific protocol between two specific security groups. If you don't know who needs to talk to the service, block it until you do.

If you aren't sure if a rule is being used, use VPC Flow Logs. Enable them, query them with Athena, and verify if any traffic is hitting that rule. If the logs are empty, delete the rule.

Closing / TL;DR

If you are using 0.0.0.0/0 in a production Security Group, you are just waiting for a breach to happen. Use Security Group Referencing to link your resources, Prefix Lists for external ranges, and SSM Session Manager for administrative access.

Your infrastructure should be a fortress, not a public plaza.

terraform plan is your first line of defense—use it to audit your ingress rules before they hit production.

Tags: AWS · Security · Security Groups · Infrastructure as Code · Terraform · VPC · Networking · DevOps · Cloud Security · Least Privilege