NexusSec.Ask to see a firewall rule base that has been in production for three years and you will usually find a long list, a good share of it some form of “any to any” on a port, and nobody who can say what most of the rules are for. That is not carelessness. It is what happens when rules are added one ticket at a time with no structure to hang them on. Zones are that structure.
What a zone is
A zone is a group of interfaces, VLANs or VPN tunnels that share a level of trust and a purpose. The firewall writes policy between zones rather than between individual addresses: traffic that stays inside a zone is left to the switches, and traffic that crosses a zone boundary is where the firewall decides.
Most next-generation firewalls are built around zones under one name or another. Firewalls that write rules per interface, such as pfSense and OPNsense, can be planned the same way by grouping interfaces. The vendor matters less than the plan.
A starting set of zones
| Zone | What goes in it | What it should reach |
|---|---|---|
| Staff | Employees' desktops and laptops | The internet through inspection; named applications in the server zone; nothing in management |
| Servers | File server, ERP, domain controllers, internal applications | Updates, backups and named partners. Rarely anything in the staff zone |
| DMZ | Anything reachable from the internet: web server, mail relay, reverse proxy | Inbound on published ports only; into internal zones only by named exception |
| Guest | Visitor Wi-Fi | The internet, rate-limited. Nothing internal |
| IoT | CCTV recorders, attendance terminals, printers, building systems | Their own recorder or vendor cloud, and nothing else |
| Management | Admin interfaces of the firewall, switches, hypervisors and storage | Reached only from administrators' machines or a jump host |
| VPN users | Remote staff on the remote-access VPN | The same as the staff zone or narrower, never broader |
A small office does not need all seven on day one. Guest, IoT and management give the most for the least effort, because they hold the devices nobody looks after and the interfaces most worth protecting. We go through the device side of that in guest Wi-Fi, cameras and printers.
Default deny between zones, one rule per direction
The rule that does most of the work is the last one: anything not explicitly allowed between two zones is dropped and logged. Every allowed flow then gets its own rule, in its own direction. Staff to Servers for the ERP is one rule. Servers to Staff is a separate question, and the answer is usually no. Writing direction explicitly is what stops a compromised server from becoming access to every desktop.
Where the firewall can identify applications and users, write rules for those rather than for ports and IP addresses: “Accounts team, Staff to Servers, ERP” says what it is for, and keeps working when an address changes.
Naming that explains itself
- Name rules after the flow they allow. “Staff to Servers - ERP for Accounts”, not “Rule 47” or “temp-allow”.
- Record an owner and a reason in the rule comment, with a date or ticket number. A rule nobody owns is a rule nobody will ever remove.
- Never use “any” for source, destination and service at once. A rule that needs all three is not a rule, it is a hole.
- Keep temporary rules temporary. Use a schedule or expiry where the firewall supports one, and a review date in the comment where it does not.
Keeping it clean
Most firewalls can show how often each rule has matched and when it last did. Review that every quarter: rules with no hits for months are candidates for removal, and a rule hidden beneath a broader one above it never matches at all. Our firewall audit and rule review is this exercise done independently.
When the business changes, with a new SaaS tool, a branch or a vendor that needs remote access, add the flow to the zone pair it belongs to rather than to whichever rule sits nearest the top.
Moving an existing firewall to zones
You do not need to rebuild the policy to get most of the benefit. Three changes, in this order, do the bulk of it:
- Move guest Wi-Fi and IoT devices into their own zones with internet-only or device-specific rules.
- Put management interfaces in a management zone reachable only from administrators' machines.
- Between staff and servers, write rules for the flows you know about, put a logging allow rule beneath them for a week to see what else crosses, then turn that last rule into a deny.
If the network is flat today, one laptop should not reach everything covers why this matters, and network segmentation is how we phase it so nothing breaks.
A note on NXSgate
NXSgate, the firewall NexusSec is building, is designed around exactly this model: zones, a default deny between them, and a rule for each direction. It has not been released yet. Everything above applies to whichever firewall you run today.
