Network and Firewall Configuration
Back to Server Setup · OS Hardening · Dependency Mapping · Subnet Calculator
Only required ports open, internal services isolated from public-facing ones. Two separate ideas, and the second is the one that limits damage: the firewall decides what can get in, and the network layout decides how far an intruder gets once something does.
1. Default Deny, Then Justify Each Rule
The rule that matters is what you allow. A firewall built by blocking known-bad traffic is permanently incomplete; one that denies everything and permits a short, explicit list is complete by construction.
- Deny inbound by default, then allow named services from named sources. Each rule carries a comment saying what it is for and who asked for it — otherwise nobody will ever dare remove it.
- Narrow the source, not just the port. “Port 5432 from the application subnet” is a rule; “port 5432 from anywhere” is an exposure with a port number attached.
- Two layers where the platform offers them. A host firewall and a network-level control (security group, VPC rules, a physical firewall) protect against different mistakes, and one misconfiguration then does not expose the service.
- Build the rules from the dependency map, not from what is currently running. That is also how you avoid the classic failure: a correct rule set that blocks the quarterly job nobody knew about.
2. Tiers, So a Breach Does Not Become Everything
A flat network means that whatever is compromised can reach everything else. Separating tiers is what turns a compromised web server into a contained problem:
- Public tier — load balancers and reverse proxies. The only things reachable from the internet, and they should hold no data.
- Application tier — reachable only from the public tier, on the one port it serves.
- Data tier — reachable only from the application tier. A database should have no route to or from the internet at all, in either direction.
- Management — monitoring, backup and administrative traffic, kept separate so that administrative access does not depend on the tier that is currently on fire.
Addressing is worth planning rather than growing: a subnet scheme with room per tier and per environment makes rules readable and avoids renumbering later. Our subnet calculator is useful for laying that out.
3. Outbound Traffic Counts Too
Most firewall effort goes on inbound, and most of what an intruder needs is outbound: fetching a payload, reaching a command channel, sending data out. Restricting egress is more work and is frequently the control that turns a compromise into a failed one.
- Allow outbound to what the workload genuinely needs — package repositories, a payment provider, an email relay — and deny the rest.
- Route what you can through a proxy, so there is a log of what was requested.
- Start in log-only mode. Watch what is actually attempted for a few weeks, then enforce. Turning on egress filtering from a guess breaks things nobody remembered.
4. Administrative Access Is Not a Public Service
SSH and remote desktop should not be reachable from the internet. The options, in order of preference: a VPN into the management network, a provider's own access service, or a single bastion host that is hardened, logged and the only thing exposed. Where an exception is genuinely unavoidable, restrict it by source address and require key-based authentication — covered under security settings.
5. Rules Are Code, and They Rot
Firewall rules accumulate. Someone opens something for a migration, the migration ends, the rule stays for six years. Two habits prevent it: keep the rule set in version control alongside everything else — see infrastructure as code — so changes are reviewed and reversible; and review the whole set periodically against the dependency map, removing what nothing uses. A rule with no comment and no owner is a finding.
Finally, test from outside. The only trustworthy answer to “is that port open?” comes from scanning the host from an external network, not from reading the configuration you just wrote.
What You Get
- A default-deny rule set, every rule commented with its purpose and source.
- A tiered network layout and addressing plan, with the data tier unreachable from outside.
- Egress policy, introduced in log-only mode first.
- Administrative access off the public internet, with a documented route in.
- Rules in version control, and an external scan confirming what is actually exposed.