Illustration of a firewall rejecting most connections and allowing one, with a public tier in front of a private tier unreachable from outside

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.

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:

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.

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