What Is Firewall?

A firewall enforces which traffic may pass between networks. The foundational capability is stateful inspection — tracking connections so that return traffic for a permitted outbound session is allowed, while an unsolicited inbound connection is not.

The technology is mature and the failures are almost never technical. They are rule sets nobody maintains.

Rule decay is the actual problem

Firewall rules accumulate. A rule is added to unblock a project, the project ends, the rule remains. Ten years later the rule base contains hundreds of entries, a meaningful share permitting access nobody can justify, and any broad rule near the top silently makes the specific rules below it irrelevant.

Reviewing them is unpopular because removing a rule risks breaking something nobody can identify in advance. The practical approach is to use hit counters: rules with no traffic over a long period are candidates for removal, and disabling before deleting gives a safe rollback.

Documenting why each rule exists, with an owner, prevents the problem recurring — and is the part invariably skipped when the rule is added under pressure.

Any-any is where estates fail

The rule permitting any source to any destination on any port, added temporarily during a migration or an incident, is the single most common serious finding. It defeats the device entirely and it is invisible unless someone reads the rule base.

Equally common is the reverse: a default-allow outbound policy, which is the normal configuration in most organisations. It means a compromised host can reach any external service, which is exactly what command-and-control requires.

Change control is what keeps the rule base honest

Rules are added under pressure, frequently during incidents or go-lives, and that is precisely when documentation is skipped. The accumulated result is a configuration nobody can reason about.

The discipline that works is lightweight: every rule carries a requester, a business reason, and an expiry date where the need is temporary. Temporary rules that genuinely expire are the single biggest contributor to a maintainable rule base, because most permanent problems started as temporary permissions.

Periodic recertification closes the loop — asking rule owners annually whether the access is still required. It is unpopular and it is considerably less painful than an unreviewed rule base a decade later.

Rule ordering deserves specific attention during review. A broad permit near the top silently overrides every more specific rule beneath it, so a rule base can contain carefully written restrictions that have never once been evaluated. Most management tooling can identify shadowed rules automatically, and the results are frequently uncomfortable reading.

A common mistake worth avoiding

Where to start

Ask for a report of firewall rules with zero hits in the last ninety days, and for any rule permitting broad access. Both lists are produced in minutes and both usually contain something surprising.

See next-generation firewalls for what application awareness adds. GuardsArm runs security program reviews.