Reviewing an inherited firewall config: what to look for and what to fix first

Most small-office firewalls are inherited. The person who set it up left, the notes are gone, and the rules have been piling up for years. You don’t have to understand every line on day one, but you do need a safe way to read the config, spot the rules that matter, and tighten things without breaking the phones or the line-of-business app.

This guide is for the lone IT person or MSP tech who just got handed a firewall. It is vendor-neutral: the labels differ between FortiGate, SonicWall, Palo Alto, pfSense, Ubiquiti, and the rest, but the questions are the same.

Start with a backup and a baseline

Before you change anything, export the configuration and store it somewhere other than the firewall. NIST’s firewall guidance says rulesets should be backed up regularly, and that if the firewall can save them in more than one format (a restorable binary one and a human-readable one), you should keep both.

Then write down the basics:

• Firmware version, and whether the vendor still supports it
• Every interface and what network it connects to
• Whether the firewall’s management page is reachable from the internet side
• Who has admin accounts, and whether each one still belongs to a real person

If the firmware is out of date, patching comes first. Exploited firewall flaws are a regular feature of this site’s alerts, for example the FortiOS flaw covered here, and a clean ruleset doesn’t help if the device itself can be taken over.

Read the rules in this order

Work from the outside in. Rules that face the internet matter far more than rules between your own networks.

1. Inbound rules from the internet. Every inbound allow (port forward, NAT rule, or “WAN to LAN” policy) should map to something you can name: a mail server, a phone system, a camera NVR. If you can’t name it, find out what it points to before you touch it.
2. Rules with “any” in them. Look for any source, any destination, or any service on an allow rule. Sometimes they are legitimate, but each one needs a reason.
3. Remote administration. Check whether the firewall’s own web or SSH admin is allowed from the WAN. If it is, restrict it to a VPN or a short list of known addresses.
4. Outbound rules. Many small offices allow all outbound traffic. That is common, but note it. At minimum, know which servers and devices actually need to reach the internet.
5. Rules between internal networks. Check what guests, phones, cameras, and building controls can reach. If they can reach servers, see getting building automation off your office network.
6. The last rule. Confirm that traffic not matched by any earlier rule is blocked. NIST describes a correct ruleset as one where traffic the policy allows is permitted and everything else is blocked.

Rule order matters. NIST notes that some vendors have restrictions or suggestions about rule order, so check your vendor’s documentation on how rules are evaluated before you move or delete anything.

Signs a rule is a problem

• A rule with no hit count or no recent traffic. Most firewalls show a hit counter or let you log matches. A rule that has matched nothing for months is a removal candidate, but see the next section first.
• Rules named “test,” “temp,” or with a person’s name. Temporary rules tend to become permanent.
• Duplicate or shadowed rules. A broad rule above a narrow one means the narrow one never fires.
• Rules for services you no longer run. An old VPN, a retired server, or a vendor remote-access rule that outlived the contract.
• Port forwards to the phone system or a server that should only be reachable from a few places. If you run an on-prem PBX, locking down an internet-exposed phone system covers what to restrict.
• Disabled rules left in place. They clutter the review and can be turned back on by accident.

Change things safely

Don’t delete a suspicious rule outright. Use this routine instead:

1. Turn on logging for the rule, or disable it rather than deleting it, and note the date.
2. Wait through a full business cycle, ideally including month-end, so rare jobs have a chance to show up.
3. Ask the people involved whether anything broke or stopped working.
4. If nothing complains, delete it and record why.

Make one change at a time, keep your console session open, and use your firewall’s rollback or scheduled-revert feature if it has one, so a mistake doesn’t lock you out.

NIST also recommends managing firewall rulesets through a formal change-control process and testing periodically that the rules do what you expect. For a small shop that can be as simple as a shared change log: date, what changed, why, and who approved it.

About ICMP (ping)

Blocking all ICMP often causes diagnostic and performance problems. NIST’s guidance is to block ICMP at the network perimeter except for the types and codes you deliberately permit, and notes that IPv4 ICMP type 3 messages should not be filtered because they support network diagnostics. If you use IPv6, filtering is more nuanced. NIST points to RFC 4890 for details.

Leave behind a short document

When you are done, write down what each remaining inbound rule is for, who asked for it, and when it was last reviewed. NIST says rulesets should be reviewed periodically, and a one-page list makes the next review take an hour instead of a week. Schedule it, for example every six months and after any major change. If you are subject to CJIS, FFIEC, or similar requirements, confirm review frequency and documentation expectations with your CJIS Systems Agency, examiner, or counsel.

Sources

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy (NIST): backups of rulesets in multiple formats, ruleset verification and periodic review, change control, rule order, and ICMP guidance