30 June 2026 · 7 min read
Firewall rule reviews: why stale allow-rules are how breaches walk in
Nothing is ever removed from a rule base. The permit written for a vendor's one-week job is still open three years later, and that is the door an attacker finds before you do.
Rule bases grow and never shrink
A rule opened so a vendor could reach an ERP server during a one-week commissioning job is still there three years later, still pointing at an internal address, still permitting the whole source range the vendor asked for. Nobody closed it because closing it was never anybody's task.
That is the shape of most break-ins that involve the network edge at all. No exotic exploit, no zero-day: an RDP port forwarded to a machine that was rebuilt two years ago, a VPN account belonging to somebody who left in March, and an any-to-any permit sitting at position four because an engineer put it there at 11pm to make something work and never took it out.
The rule base is also the only place where those three things are visible together. A monitoring dashboard will not show you a permit nobody uses, because an unused permit generates no traffic and therefore no alert.
What a quarterly review actually goes through
The review starts with an export of the running configuration and a hit-count report, then works down the rule base line by line: what does this rule permit, who asked for it, and has anything matched it recently. A rule with no hits in ninety days is either finished work or a mistake, and the only way to tell is to find the person who requested it.
Rule order is read at the same time, because it changes what the hit counts mean. A permissive rule sitting above a specific one means the specific rule never evaluates and reports zero matches, which looks identical to disuse. Delete on hit count alone and you remove the tight rule and keep the loose one, which is the opposite of the intended result.
- Every rule with no matches in ninety days, checked against whoever requested it
- Inbound rules where the source is still any rather than a named address object
- Port forwards pointing at internal addresses where no live host now answers
- Rules shadowed by a broader rule above them, so the tight rule never evaluates
- VPN and remote-access accounts belonging to people who have left
- Address and service objects that no remaining rule references
- Whether the management interface answers on the WAN side at all
- Firmware level, IPS signature date, and whether the model still gets updates
The three rules that turn up in almost every review
RDP on 3389 forwarded straight to a desktop, because somebody needed to work from home and it was quicker than configuring a VPN. SMB on 445 permitted between a branch and head office so a shared folder would open. An NVR published on ports 8000 and 554 so a manager could watch cameras from a phone.
Each of those has a replacement that does the same job without the exposure. Remote access belongs behind a VPN with a second factor on it. Branch traffic belongs in a site-to-site tunnel carrying only the two subnets that genuinely need each other, not the whole address range. Camera viewing belongs behind the firewall rather than as a port forward to a recorder that has not taken a firmware update since the day it was commissioned.
The recorder case is worth naming separately, because it is the one that keeps happening. Internet-reachable ONVIF devices are scanned continuously, they very often still hold the credentials printed on the sticker, and they are on your internal network by definition. A camera system is a way in as well as a way to watch.
Logging is what makes the next review possible
Log the deny at the bottom of the rule base as well as the permits. Denied traffic is what tells you which of your own systems are trying to reach something they should not, which is usually how a misconfigured backup agent or a forgotten integration surfaces.
Send the logs off the box. Local storage on a firewall rotates in days under real traffic, so the log covering the week you actually need is gone by the time anyone asks for it. A syslog target with its own retention costs very little and is the difference between an investigation and a shrug.
Set NTP on the firewall, the recorder and the servers to the same source. Correlating a firewall log against a camera timestamp and a door-access record is guesswork if the three clocks are minutes apart, and they drift apart quietly.
Six questions for your current provider
You do not need to read the rule base yourself to find out whether anyone else has. Ask these and the answers tell you what you need to know.
- When was the rule base last exported, and can we have a copy of it?
- How many rules have not matched a packet in the last ninety days?
- Is the management interface reachable from the internet, and from which addresses?
- Who holds the admin credentials, and are they recorded somewhere we control?
- Is there a change log showing who added each rule, when, and why?
- What firmware are we running, and when does this model stop receiving updates?
Also asked
Follow-up questions
Can a firewall rule review be done without downtime?
- Yes — reading and analysing a rule base changes nothing, and removals are staged rather than immediate. A candidate rule is disabled instead of deleted, left for a fortnight, and removed once nothing has broken. Only a re-ordering of the rule base needs a maintenance window.
What is a shadowed rule, and why does it matter?
- A shadowed rule sits below a broader rule that already matches the same traffic, so it never evaluates and reports zero hits. It matters because a review that deletes zero-hit rules blindly will remove the tight rule and leave the permissive one in place.
Our firewall has not been touched since installation. Where do we start?
- Start with a configuration export and a hit-count report, because you cannot review what you cannot read. That pair alone usually surfaces the open port forwards, the leavers' VPN accounts and whether the management page is answering from the internet.