Firewall Rules and Security Groups: A Configuration Guide

Your firewall is only as good as its worst rule

October is Cybersecurity Awareness Month, and most of the advice you will read this month is about phishing and passwords. That advice matters. But in cloud environments, a quieter problem causes a large share of exposure: network rules that were opened "temporarily" and never closed.

A single rule allowing SSH from anywhere, or a database port reachable from the internet, undoes every other control you have. Attackers do not need to break your firewall. They scan for the gaps you left in it.

This guide walks through how firewall rules and security groups work together in a private cloud, how to design them so they default to deny, and how to audit what you already have. If you only do one security task this month, review your network rules.

Firewalls and security groups are two different layers

The terms get used interchangeably, but they protect different things. A strong setup uses both.

In an OpenStack private cloud, security groups are managed by Neutron, the networking service. Two behaviors matter most:

• They are stateful. If you allow inbound traffic on port 443, the response goes back out without a matching egress rule. You only write rules for the direction a connection starts.
• They are allow-lists. There are no deny rules. Anything not explicitly allowed is dropped. That makes the default behavior safe, and makes every allow rule a decision someone should be able to justify.

Think of the perimeter firewall as the building's front door and security groups as the locks on each room. A visitor who gets past reception should still not be able to walk into the server room.

Start from deny, then earn every rule

Good rule design follows three principles.

1. Default deny inbound. Nothing reaches an instance unless a rule says so. Security groups already work this way; your perimeter firewall should too.
2. Least privilege per rule. Each rule should name the narrowest source, the specific port, and the protocol. "TCP 22 from 203.0.113.10/32" is a rule. "All TCP from 0.0.0.0/0" is an incident waiting to happen.
3. Restrict egress, too. OpenStack's default security group allows all outbound traffic. That is convenient, and it is also how compromised servers reach command-and-control hosts or exfiltrate data. For sensitive workloads, remove the default egress rules and allow only the destinations the workload needs, such as package mirrors, DNS, and specific APIs.

A useful test: for every rule, you should be able to answer who asked for it, what breaks if it is removed, and when it was last reviewed. If nobody can answer, the rule is a candidate for removal.

A configuration pattern for a three-tier application

The most practical way to use security groups is to create one group per role and reference groups from each other, instead of hard-coding IP addresses. Neutron supports this through a rule's remote group: "allow traffic from any instance that belongs to group X." When you scale the app tier from three servers to ten, the database rules keep working with no edits.

A few habits make this pattern hold up over time:

• Use a bastion host or VPN for admin access. SSH and RDP should never be open to the internet, even with key-based login.
• Name and describe every group and rule. Neutron lets you add descriptions. "Allows app tier to reach Postgres, requested by platform team" saves hours during an audit.
• Keep rules in code. Define security groups in Terraform, Heat, or Ansible so changes go through review and you have a history of who opened what.
• Avoid the default group for real workloads. Create purpose-built groups so nothing inherits permissions by accident.

The misconfigurations that show up most, and a 30-minute audit

Most exposure comes from a short list of mistakes:

• Management ports (22, 3389) open to 0.0.0.0/0
• Database or cache ports (3306, 5432, 6379, 27017) reachable from outside the app tier
• "Temporary" debugging rules that became permanent
• Wide port ranges opened to save time
• Unrestricted egress on servers that handle sensitive data
• Orphaned security groups still attached to instances nobody owns

Use this checklist for a Cybersecurity Awareness Month review:

• Export every security group and rule in each project (openstack security group list and openstack security group rule list)
• Flag every ingress rule with a source of 0.0.0.0/0 or ::/0 and confirm each one is intentional
• Confirm SSH and RDP are reachable only through a bastion or VPN
• Confirm database ports accept traffic only from the application tier's group
• Review egress on instances that process customer or payment data
• Delete unused groups and rules with no description or owner
• Check the perimeter firewall for rules broader than the security groups behind it
• Schedule the next review, quarterly at minimum