Firewall Hardening with CIDR: Moving Beyond 0.0.0.0/0

The most dangerous firewall rule is also the most common: 0.0.0.0/0 allowing inbound access on a sensitive port. It opens your resource to every address on the public internet — every scanner, every bot, every attacker. Hardening that rule to a specific CIDR block reduces your exposure to a tiny fraction of the internet. Our firewall rules and CIDR guide covers the principles; this article focuses on the practical hardening steps.

Start with an Audit

List every firewall rule that uses 0.0.0.0/0 as the source. For each one, ask: does this service genuinely need to accept connections from any IP on the internet? HTTP/HTTPS on a public load balancer — yes. SSH on a database server — no. Most 0.0.0.0/0 rules exist because they were the path of least resistance during initial setup, not because they were intentional.

Replace with /32 for Known Sources

For administrative access — SSH, RDP, management APIs — replace 0.0.0.0/0 with the specific IP addresses or CIDR blocks of your office, VPN exit nodes, or jump hosts. A /32 for each known IP is ideal. If your office has a dynamic IP that changes monthly, use a /28 or /24 that covers the ISP's typical allocation range. This is a dramatic improvement over 0.0.0.0/0.

Use Cloud Service IP Ranges

If your service receives traffic from specific cloud services — a payment gateway, a monitoring platform, a CI/CD system — those providers publish their outbound IP ranges. Add those specific CIDR blocks rather than allowing the entire internet. Browse the AWS IP ranges if you need to allowlist traffic from AWS Lambda, CloudFront, or other AWS services sending to your on-premises infrastructure.

Internal Traffic: Use VPC CIDR, Not 0.0.0.0/0

For traffic that should only flow within a VPC or between specific subnets, use the VPC or subnet CIDR as the source. If your application server needs to talk to your database, the database's security group should allow port 5432 from the application server's subnet CIDR, not from the internet. 10.0.2.0/24 → 10.0.3.0/24 is infinitely better than 0.0.0.0/0 → anywhere.

The /0 as a Last Resort

There are legitimate cases for 0.0.0.0/0: a CDN origin should only accept connections from the CDN's edge nodes, but if you do not know those ranges, you might temporarily allow all traffic while you research. Treat any 0.0.0.0/0 rule as a technical debt item with a ticket attached — document why it exists and when it will be tightened. The 0.0.0.0/0 calculator page shows exactly what "all addresses" means in concrete terms.