Firewall audit and clean-up
Firewall rule bases grow for years. An exception someone needed, a supplier who once needed in, a test that worked and was never undone: they all stay in the rule base long after anyone remembers why.
We review an existing firewall rule by rule, along with who can manage it, how people connect to it, what it’s running and what it records, then tidy it up without replacing the hardware.
A rule base, marked up
Each problem on it is one we look for on every audit.
- 11 Allow InternetOffice, admin VPN → Firewall admin HTTPS, SSH Today Restrict. The admin login answers to the whole internet. Limit it to known sources. Firewall management, from the office and the admin VPN only.
- 24 Allow Internet → Terminal server RDP Today Flag. Remote desktop open to the internet, and in use. Closing it means giving those people another way in, so it’s a decision for you and the client. FlaggedRemote desktop for staff. Exposure raised in the findings report.
- 3 Allow Internet → 10.0.1.15 HTTPS None in 90 days Remove. Publishes a server that was retired. Nothing answers on that address any more.
- 43 Allow Guest Wi-Fi → AnyInternet Any Today Reorder. Sits above the rule meant to keep guests off the office network, and its destination is anywhere at all. Guest Wi-Fi, internet access only.
- 52 Deny Guest Wi-Fi → Office LAN Any Never Shadowed. It never matches, because rule 4 lets the same traffic through first. Guests can reach office devices. Keeps guest devices off the office network. Now ahead of the guest internet rule.
- 6 Allow VPN “temp supplier” → Office LAN Any 14 months ago Disable. Full network access for a supplier the client no longer uses. Confirm, then disable rather than delete.
- 7 Allow (off) Internet → 10.0.1.30 FTP Disabled Remove. Switched off years ago and kept “just in case”. Rules like this get switched back on by mistake.
- 8 Allow Office LAN → 10.0.5.0/24 Any Today Merge. The same traffic as rule 9, written against a raw address instead of the named object.
- 95 Allow Office LAN → Branch office Any Today Keep. Rule 8 folds into this one. Site-to-site traffic to the branch office.
- 106 Allow Office LAN → Internet Any Today Flag. Outbound traffic is wide open. Narrowing it is a design decision, not a clean-up item. FlaggedOffice internet access. Outbound filtering raised in the findings report.
- 117 Deny Any → Any Any Not logged Log. The final deny records nothing, so blocked traffic leaves no trace. Default deny, with logging on.
Eleven rules as found, with the reviewer’s notes in the margin.
The audit covers more than the rules
A tidy rule base doesn’t help much if anyone can log in to the firewall, the firmware is old and nothing is logged. So the audit covers four other areas as well.
-
Who can manage it, and from where
We look at every account that can change the configuration, how each one signs in, and every place management is reachable from: the WAN interface, the vendor’s cloud portal, a forgotten SNMP community. Most of the serious findings come from here.
A typical findingOne shared admin login, known to staff who left years ago, with management open on the internet-facing interface.
-
VPN and remote management
Remote access settings age badly. Protocols and ciphers that were fine when the VPN went in, pre-shared keys that have never changed, accounts that outlived the people they belonged to, and remote management connections nobody remembers turning on.
A typical findingLocal VPN accounts for former staff, still able to connect, on a tunnel using settings the vendor now advises against.
-
Firmware and licensing
Internet-facing devices are a common way in for attackers, and firewall vendors publish fixes often. We check the firmware against the vendor’s current releases and advisories, and whether the hardware and its firmware branch are still supported. Then the licences: when a security subscription lapses, the policy can still say a feature is on while the firewall has stopped doing it.
A typical findingWeb filtering applied to every outbound rule. The subscription lapsed, so nothing is actually being filtered.
-
Logging and alerts
Logs held only on the device roll over in days, and alerts that go to nobody might as well not exist. We set up logging and alerts so the events worth knowing about, such as admin sign-ins, configuration changes and VPN failures, are kept and reach someone. We check the clock too, because logs with the wrong time are hard to use when they matter most.
A typical findingLogs kept only on the box, overwritten within the week, with the clock several minutes out.
Changing a firewall people depend on
A zero hit count doesn’t prove a rule is unused
A rule with no hits might carry the quarterly upload to the bank, or a supplier who connects once a year. On some platforms the counters also reset on a reboot or upgrade, so “never” can mean “since the last restart”. We weigh hit counts against the client’s list of services that must keep working, and ask before removing anything we can’t explain.
Disable first, delete later
When a rule’s purpose can’t be confirmed, we disable it rather than delete it, and list it in the report. If something turns out to need it, it’s one switch to bring back, not a rule to rebuild from memory.
Everything is reversible inside the window
The clean-up happens in a change window agreed with you. The configuration is backed up before the first change and every change is recorded as it’s made. If a service on the must-work list breaks and can’t be fixed in the window, it goes back the way it was.
Some findings aren’t ours to decide
Closing an exposed remote desktop or restricting outbound traffic changes how people work. Those calls belong to you and the client, not to a clean-up. They go in the findings report with a recommendation, ready for you to take to the client.
What you receive
Three things, written so the next engineer to touch the firewall, yours or the client’s, knows what’s there and why.
A cleaned-up rule base
Unused, duplicate, shadowed and overly broad rules dealt with, the rest in the order they need to be in, and each one named and commented with what it’s for.
A findings report
Every finding, why it matters and what was done about it. Items left for a decision sit in their own section with a recommendation, so you can raise them with the client under your own name.
As-built documentation
How the firewall is set up after the clean-up: interfaces and zones, address objects, the rule base, VPNs, administrative access, firmware and licence status, and where logs and alerts go.
When an audit isn’t the right project
-
If the firewall is out of support or can’t keep up, a clean-up tidies something that’s about to be replaced.
Firewall replacement and migration -
If the question is the whole network rather than one device, start wider.
Network health check and documentation -
If the audit shows remote desktop or an old VPN is how people get in, that’s a project of its own.
Remote access VPN and zero-trust access
Hand us the firewall nobody wants to touch
We work on Fortinet, Palo Alto Networks, Cisco, Meraki, SonicWall, WatchGuard, Sophos, Check Point, Juniper and Huawei firewalls.
Delivered remotely as a white-label project, under your brand or as your named specialist partner, at a fixed price for the agreed scope. You keep the client and the ongoing service.