A useful firewall policy describes which systems may communicate, for what purpose, and who owns each exception. Start with required business traffic and deny the rest. Buying a larger appliance will not fix an undocumented rule set.
Identify the zones before writing rules
Separate employee devices, servers, guest Wi-Fi, connected equipment and administration where the architecture supports it. Traffic between these zones must pass through a filtering device for its rules to apply. A VLAN label alone does not prove isolation.
The administration network should reach management interfaces through approved administrator devices or access paths. Ordinary user devices and visitors should not have the same access.
A minimum traffic matrix
This is a policy worksheet, not a configuration to paste into a firewall. Replace each destination with the required addresses or supported service objects, and identify the protocol and ports.
| Source | Destination | Intended policy | Detail to establish |
|---|---|---|---|
| Employee devices | Approved Internet services | Permit required use | Web applications, update services and required cloud endpoints |
| Internal devices | Approved DNS and time servers | Permit required services | Resolver and NTP addresses; avoid arbitrary destinations |
| Guest Wi-Fi | Internet | Permit agreed guest use | Prevent access to internal and management networks |
| Guest Wi-Fi | Internal networks | Deny | Verify each relevant internal zone |
| Employee devices | Business servers | Permit specific applications | Server, protocol and port for each application |
| Administration devices | Management interfaces | Permit approved administration | Named access path and administrators |
| Internet | Published VPN or application gateway | Permit that service only | Exposed destination, authentication and maintenance owner |
| Internet | Other internal destinations | Deny | Confirm that no older publication bypasses the policy |
HTTPS, DNS and NTP have different purposes. Allowing those protocol names everywhere is broader than identifying the destinations that actually need them. Vendor cloud services can require maintained endpoint lists; document how those lists will be updated.
Stateful firewalls normally track return traffic for established connections. Check your product's behaviour before adding broad reverse rules. Also inspect rule order, address translation and IPv6: a correct IPv4 rule does not demonstrate that another path is filtered.
Make every exception reviewable
For each permitted flow, record the source, destination, protocol, ports, business purpose, owner and review date. Give temporary access an expiry date and a removal owner. A note saying "needed by accounting" is insufficient if nobody can identify the application.
When a server is retired, search for its addresses, aliases and related translation rules. Remove obsolete access after confirming the dependency has ended. Keep a versioned export of the known working configuration.
Test the rule, including the traffic it should reject
Before deployment, reproduce the change in a suitable test environment when possible. For a production change, agree a maintenance window, an authorised recovery access method and a rollback procedure. Avoid relying on the very remote connection you are about to filter as your only way back in.
Use two checks for each important rule:
- From an authorised source, perform the actual operation: open the application, save a file or establish the approved VPN session.
- From an authorised test device in a restricted zone, attempt the corresponding forbidden connection and inspect the firewall log. A page that fails to load could also indicate a DNS or application problem.
Record the source device, destination, time and observed decision. Review both working traffic and denied traffic after the change; an unexpectedly quiet log can indicate that traffic bypasses the firewall. This testing approach follows the NIST firewall policy guide.
Logs that someone can use
Prioritise VPN connections, sensitive inter-zone access, published services and relevant denials. Establish where the logs go, how timestamps are synchronised, who reviews alerts and what action they take. Collecting every routine packet without a review process can hide useful signals in noise.
A firewall does not replace application updates, secure authentication or backups. An allowed connection can carry an attack against a vulnerable application. For the next checks, see our network audit method, business Wi-Fi guide and MFA priorities.
Sources
- ANSSI: defining a network filtering policy, in French.
- NIST SP 800-41 Rev. 1: firewall policy, testing and management.
- CIS Controls.
View sources (3)
Support available on this topic
Initial Infra handles these topics for SMBs and mid-size companies. A short call is enough to identify priorities and the right scope of intervention.