Your Firewall Is Running. But Are Its Rules Still Protecting You?

A firewall can be working exactly as configured and still allow access your business no longer needs.

Perhaps a supplier needed remote access for an installation. An application required a temporary exception during troubleshooting. An old server was replaced, but the rules allowing access to it were never removed.

Each change may have had a reasonable explanation at the time. Months or years later, however, those permissions can remain in place long after the original need has disappeared.

For a business, the consequences could include unnecessary exposure to attackers, access to sensitive systems and greater disruption if an account or device is compromised.

The question is therefore more useful than simply asking whether you have a firewall:

Does your firewall allow only the access your business actually needs today?

What do firewall rules actually do?

Firewall rules control which network connections are permitted or blocked. They can consider factors such as where traffic comes from, where it is going and which service it is trying to reach.

For example, a business might need to allow customers to reach its public website while preventing them from accessing internal file storage.

Inside the organisation, staff may need access to a particular application without needing access to the server’s management interface.

The NCSC describes firewalls as part of a wider approach to network security, using rules to control permitted communications. Their effectiveness depends on how those controls are designed and maintained.

Buying a capable firewall is a useful starting point. Keeping its configuration appropriate as the business changes is an ongoing responsibility.

How unnecessary access builds up

Firewall configurations rarely become complicated overnight. They grow through everyday operational decisions.

A new application goes live. A supplier changes its connection requirements. Staff begin working remotely. A problem needs resolving quickly.

Under pressure, allowing broader access can seem like the easiest way to get things working. Once the immediate problem is resolved, narrowing that permission may slip down the priority list.

Consider a supplier that needs to connect to one server for maintenance. A tightly scoped rule would limit access to the required source, destination and service. A broader rule might allow that supplier to reach an entire network.

Both may let the supplier complete the work. The broader rule also creates access that the business has no reason to permit.

Repeated across years of changes, these decisions can leave a substantial gap between the intended security policy and the access the firewall actually allows.

Five weaknesses worth looking for

1. Temporary rules that became permanent

A temporary exception should have an owner, a documented purpose and a removal or review date.

Without those controls, troubleshooting access can remain available indefinitely.

An old rule does not automatically mean a vulnerability exists. It does mean someone should be able to explain why the permission is still necessary.

2. Permissions that are broader than necessary

Rules that allow large address ranges, entire networks or all services deserve scrutiny.

Sometimes broad permissions have a legitimate operational purpose. The review should establish whether that purpose still applies and whether a narrower rule could achieve the same result.

For example, an application needing one connection between two servers does not automatically justify unrestricted communication between their networks.

3. Unnecessary exposure to the internet

Some services need to be publicly accessible. Many administrative and internal services do not.

A review should examine which systems can be reached from the internet, why they are exposed and what restrictions protect them.

Particular attention should go to remote administration, supplier access and forgotten development or test systems.

Allowing a connection through the firewall does not, by itself, compromise the destination. It can nevertheless give an attacker an opportunity to target a service that could otherwise have remained inaccessible.

4. Rules that do not have the intended effect

A rule can look reassuring in isolation while having little effect within the wider configuration.

Depending on the firewall, rule order, priority, policy inheritance and other processing behaviour can determine which action applies. Microsoft’s Azure Firewall documentation, for example, explains that different rule types have a defined processing order.

A review therefore needs to consider how the particular product evaluates traffic, rather than simply checking whether a restrictive rule appears somewhere in the list.

5. Internal networks with excessive access to each other

The boundary between your business and the internet is only part of the picture.

Where firewalls control traffic between internal networks, their rules can help limit access between staff devices, servers, guest networks and sensitive systems.

If those connections are overly permissive, a compromised device may be able to reach more of the business than necessary.

Effective separation can help contain an incident. It needs to be enforced by the actual network configuration, rather than assumed from network names or a diagram.

What about outbound traffic?

It is easy to focus on connections coming into the business. Connections leaving it also deserve attention.

Servers, for example, may need access to specific update services or external applications. They may have little reason to communicate freely with every destination on the internet.

Appropriate outbound restrictions can help limit some unwanted communications from compromised systems. They cannot guarantee that malicious traffic will be blocked: attackers may use services or destinations that the business legitimately permits.

The aim is to remove unnecessary freedom while preserving the connections required for normal work.

Would a vulnerability scan identify these problems?

A vulnerability scan can help identify exposed services and known weaknesses in reachable systems. It does not necessarily establish whether every firewall permission has a valid business purpose.

An external scan may show that a service is accessible from the internet. It may not tell you that access was intended only for one supplier, or that the service should have been retired six months ago.

A firewall rules review examines the configuration and its purpose. Penetration testing can then assess what an attacker could achieve through accessible systems.

These activities provide different evidence and can complement each other.

What should a firewall rules review involve?

A useful review should connect technical permissions to business requirements.

It should establish:

• Which systems and network boundaries the firewall protects.
• Which connections are permitted, including relevant internet, internal and remote access.
• Whether permissions are limited to the sources, destinations and services required.
• Whether rules have clear purposes and accountable owners.
• Whether temporary, obsolete or duplicate rules need attention.
• Whether rule processing produces the intended restrictions.
• Whether logging provides useful visibility into relevant traffic.
• Which changes would reduce risk, and how those changes should be introduced safely.

Automated analysis can help highlight patterns and potential problems. Business context remains essential: a tool cannot reliably decide whether an unfamiliar connection supports a critical monthly process or an application nobody uses any more.

Review regularly—and after significant changes

The right review frequency depends on the environment, its exposure and how frequently it changes.

Reviews are particularly useful after significant infrastructure changes, application migrations, supplier changes or the introduction of new remote access.

They should also form part of ongoing configuration management. The NCSC recommends maintaining control over configurations and using checks to help prevent vulnerabilities being introduced through changes.

Avoid removing unfamiliar rules without investigating them first. Some services run infrequently, and a lack of recent traffic does not prove that a permission is unnecessary.

Changes should be documented, tested and introduced with a suitable rollback plan.

A practical checklist for your next IT meeting

You do not need to understand every firewall setting to ask useful questions:

• Can we explain why each internet-facing service needs to be accessible?
• Are any temporary exceptions still enabled?
• Is supplier access limited to the systems and services required?
• Are broad permissions justified and documented?
• Are sensitive systems appropriately separated from everyday staff and guest devices?
• Can we identify who owns each important rule?
• When was the configuration last reviewed against our current business needs?

Unclear answers are a reason to investigate.

Make sure your firewall reflects the business you run today

Your firewall may have been configured appropriately when it was installed. Since then, your people, systems, suppliers and ways of working may have changed.

Reviewing its rules helps you identify unnecessary access before it becomes part of an incident. It also gives your IT team a clearer, more manageable configuration to maintain.

If you are unsure whether your firewall rules still reflect your business needs, contact Plainsight Security to discuss a firewall rules review and practical steps to reduce unnecessary exposure.