4.2 Firewalls, security groups and network rules
Describes cloud networking as of August 2026
What this is and why it exists
The network layout decides what is possible; the rules decide what is permitted. This topic is where you say "port 443 from anywhere, port 5432 only from the application tier, nothing else" and can then prove it. It is also where the industry's most common bad habit lives — opening a port to the entire internet because it was quicker — and the point of the lesson is to make the correct thing quick enough that the habit never forms.
The vocabulary
- Security group — a rule set attached to a machine or interface. Amazon calls them Security Groups, Azure calls them Network Security Groups, Google calls them VPC firewall rules.
- Network ACL — a rule set attached to a subnet, evaluated before anything inside it; Amazon's NACLs are the common example.
- Stateful — a rule set that remembers connections, so a reply to an allowed request is automatically allowed back.
- Stateless — a rule set that judges every packet alone, so you must permit the return traffic explicitly.
- Ingress — traffic arriving; egress is traffic leaving.
- Least privilege — allowing exactly what is needed from exactly where it is needed, and nothing else.
- 0.0.0.0/0 — the CIDR block meaning every address on the internet.
- Effective rules — what actually applies to a machine once every overlapping layer has been combined.
The mental model
Two layers, and they behave differently on purpose. The machine-level rule set is stateful: allow inbound 443 and the replies flow back without a second rule, because the system remembers the connection. The subnet-level rule set is stateless: it examines each packet on its own, which means allowing inbound 443 without also allowing the outbound reply gives you a connection that arrives and never answers. That asymmetry is the source of a specific and maddening symptom — traffic that reaches the machine and dies silently — and recognising it saves an afternoon.
Least privilege takes one sentence to state and a small amount of structure to actually keep. The structure is to write rules in terms of other rule sets rather than addresses wherever the provider allows it: the database's rules permit traffic from the application tier's group, not from a range of numbers. That way the rule stays correct when machines are added, replaced or moved, and it says out loud what it means. A rule listing addresses is a rule that will be wrong within a month and will not tell you.
Then 0.0.0.0/0, which deserves naming as the habit it is. It appears because something did not work, opening everything made it work, and nobody came back. Two of its forms cause almost all the damage: administrative access — SSH or remote desktop — exposed to the whole internet, where automated scanning finds it within minutes of the machine existing; and a database port opened to everyone so that a laptop could connect once. There is a legitimate use of 0.0.0.0/0, and it is the public port of a public service, usually 443, usually on a load balancer. For anything else, ask what the source really is and write that. Where you genuinely need to reach a machine from anywhere, the answer is a bastion or an identity-aware access service, not an open port.
Egress is the half people skip, and it is the half that matters after something has already gone wrong. Inbound rules stop an attacker getting in; outbound rules limit what happens next. A compromised machine that can open connections to anywhere can send your data anywhere, fetch further tools, and join a botnet. A machine restricted to the few destinations it genuinely needs can do very little with the same foothold. It is more work — you have to know what your systems talk to, which is itself a useful thing to learn — and it converts a breach into a contained incident.
Finally, reading effective rules when layers overlap. The order to hold in your head is: subnet-level rules are evaluated at the subnet boundary, machine-level rules at the interface, and traffic must be permitted by every layer it crosses. A deny at any layer wins; an allow at one layer does not override a deny at another. Most providers offer a tool that answers "can this reach that", and using it is far better than reasoning about four rule sets by hand. When a connection unexpectedly fails, walk the path in order and check each layer rather than guessing — and when a connection unexpectedly succeeds, do exactly the same, because that is the more alarming discovery.
What you should now be able to explain or do
Say which layer is stateful and which is stateless, and describe the symptom the difference produces. Write a rule set for a three-tier application in plain words, referring to groups rather than addresses. Name the two dangerous uses of 0.0.0.0/0 and give the correct alternative for each. Explain what egress rules buy you and why they are worth the work. Diagnose a blocked connection by walking the layers in order.
Check yourself
You allow inbound traffic on a port at the subnet level and the connection still fails silently. What have you probably forgotten?
The outbound rule for the reply. Subnet-level rules are stateless — each packet is judged alone — so the return traffic needs its own permission.
Why write a database rule as "from the application tier's group" rather than as a list of addresses?
Because the group stays correct when machines are replaced, added or moved, and it states the intent. An address list is quietly wrong within a month.
Where is 0.0.0.0/0 legitimate, and where is it a mistake?
Legitimate on the public port of a public service, usually 443 on a load balancer. A mistake on administrative access or a database port — automated scanning finds those within minutes.
What do egress rules protect you from that ingress rules do not?
What happens after a foothold. Restricting outbound destinations limits data leaving, tools being fetched, and the machine being used for something else — it turns a breach into a contained one.
A connection you expected to fail actually works. What do you do?
Walk the layers in order — subnet rules, then interface rules — and find which one permits it. An unexpected success is more alarming than an unexpected failure, because it is the one nobody investigates.
Go deeper
We haven't checked most of these for screen reader use yet.
Back to Firewalls, security groups and network rules: work through the checklist