Firewall Penetration Testing: Validate Rules and Network Paths

Firewall penetration testing asks whether an actual network path enforces the intended access policy. A configuration review shows what the rules say; a probe shows what happened from one source at one time. A defensible result connects both to the destination service and the relevant enforcement logs. A timeout by itself does not establish that the firewall blocked the connection.

NIST SP 800-115 treats technical testing and examination as complementary assessment techniques. Apply that distinction directly: review the policy and configuration, then test representative allowed and denied paths. Record the source, destination, protocol, identity, and evidence needed to explain each outcome.

Define the boundary before choosing tools

A firewall assessment can involve an internet edge, a host firewall, a cloud security group, or an internal segmentation boundary. Name the control being tested and the traffic direction it governs. Do not silently expand a network-filter assessment into a web application firewall evaluation or a full application penetration test; those require different acceptance cases.

Use a policy matrix as the test plan. Each row should state who needs to reach which service and why. Include explicit deny cases alongside allowed business flows. The examples below describe a fictional environment, not observations about a real customer network.

Add the actual IPv4 and IPv6 addresses, NAT translation, interface or zone, approved test window, and owner to the working matrix. A hostname can resolve to several destinations, and a cloud workload may leave through a different source address than the one shown in its local configuration. Preserve the address observed at the enforcement point so the tested path can be reconstructed.

Map the forward and return paths

The useful unit of testing is a path through controls, not a port number in isolation. A load balancer can accept a connection while the backend is unavailable. A host firewall can block traffic that the perimeter allowed. A route error can stop a packet before it reaches either firewall. These outcomes require different fixes.

NIST’s firewall policy guidance provides a basis for reviewing firewall placement and policy. For the assessment, annotate the actual path with the controls that can allow, deny, translate, or terminate traffic. Include the return direction and the evidence location for each relevant decision.

Interpret port states without overstating them

Les Nmap port-state reference distinguishes open, closed, filtered, and ambiguous states. Open means an application accepts connections for the tested protocol and vantage point. Closed means the port is reachable but no application is listening. Filtered means Nmap cannot determine whether the port is open because filtering prevents a conclusive observation. Some scan techniques report combined states such as open|filtered.

Treat those labels as observations from a particular probe. A closed administrative port is not proof that the firewall enforces a deny rule: the service might simply be stopped. Likewise, a failed TCP connection cannot establish that every UDP path or IPv6 route is blocked. Match the conclusion to the protocol, source, and destination actually tested.

For an authorized small TCP test, an illustrative command is shown below. The address is loopback, so it does not contact an external target. A production assessment should substitute only approved destinations and agreed ports; the command itself cannot establish which device enforced a policy.

nmap -sT -Pn -p 8443,9443 --reason -oA loopback-control 127.0.0.1

A local control that exposes a common reporting error

This Python example creates one listening loopback endpoint and reserves another local port without listening. It performs two TCP connection attempts and closes the resources. It makes no firewall changes and does not simulate a filtered path. Its purpose is to demonstrate why “connection refused” and “blocked by policy” are different conclusions. Save it as local_probe.py and run python3 local_probe.py.

"""Loopback connectivity control, not a firewall simulation."""
import socket
from http.server import ThreadingHTTPServer, SimpleHTTPRequestHandler
from threading import Thread


def probe(port):
    try:
        with socket.create_connection(("127.0.0.1", port), timeout=2):
            return "connected"
    except ConnectionRefusedError:
        return "refused"
    except TimeoutError:
        return "timeout: investigate the path"


server = ThreadingHTTPServer(("127.0.0.1", 0), SimpleHTTPRequestHandler)
Thread(target=server.serve_forever, daemon=True).start()
reserved = socket.socket()
reserved.bind(("127.0.0.1", 0))  # Bound, but deliberately not listening.
try:
    open_result = probe(server.server_port)
    control_result = probe(reserved.getsockname()[1])
    print({"listening": open_result, "not_listening": control_result})
    assert open_result == "connected"
    assert control_result == "refused"
finally:
    reserved.close()
    server.shutdown()
    server.server_close()

In the Linux authoring environment, the listening endpoint returned connected and the non-listening control returned refused; both assertions passed. The Nmap command above is illustrative and was not executed for this article. This local exercise proves no production firewall property. A real deny test needs evidence from the actual enforcement path.

Correlate probes with enforcement and destination evidence

Assign a case ID to each approved test. Record a precise time window, observed source and destination tuple, protocol, and result. Compare that with firewall or flow logs and a destination-side observation. If NAT changes the tuple, keep the mapping rather than trying to join logs on the client’s original address alone.

Absence from one log is not a universal proof that traffic never arrived. Establish whether the logging configuration captures the relevant rule and whether the destination observation covers the same test window. If those prerequisites are missing, preserve an inconclusive result rather than forcing a pass or fail.

Retest stateful controls with fresh connections

State can make a rule-change test misleading. Amazon EC2 documents security groups as stateful and notes that changing a rule does not immediately interrupt tracked connections. Response traffic is treated differently from a new connection. An existing session continuing after a rule change therefore does not, by itself, prove the new rule is ineffective.

Create a new connection for the post-change case and record whether the old session is being tested separately. Where connection tracking matters, document timeout and platform behavior instead of assuming one vendor’s behavior applies everywhere. Coordinate any session termination with the owner; an assessment should not casually disrupt an operational connection to make a test simpler.

AWS network ACLs operate at the subnet boundary and can allow or deny inbound and outbound traffic. Distinguish their role from security groups when mapping the path. The combined result can be correct even when the rule under review never made the decisive decision; logs should identify which control actually acted.

Deliver a finding an owner can fix and retest

Report the intended policy, observed path, control responsible, evidence, and smallest appropriate change. Identify whether the problem is a broad rule, unexpected source translation, an alternate address family, an unreviewed route, or insufficient logging. Avoid prescribing “block the port” when the requirement is to permit the service only from one approved workload.

After the change, repeat both the denied case and its permitted business-flow control. Preserve the new connection tuple and configuration revision. A deny-only retest can hide an outage; an allow-only retest can hide an overbroad exception. The owner should be able to reproduce the same distinction without the original tester present.

When evaluating an automated assessment workflow such as Penligent, require this same case matrix and evidence quality. The useful acceptance criterion is whether it can distinguish an observed connection result from a verified policy violation, and whether a human can inspect and repeat the conclusion.

Firewall penetration testing FAQ

Is a ruleset review enough? It explains configured intent and can reveal unnecessary access, but testing representative paths checks deployment behavior. Use both and reconcile differences.

Does filtered mean secure? It describes the observation from that scan. It does not establish coverage of other sources, protocols, address families, or application paths.

What belongs in the final evidence? Keep the policy case, vantage point, translated tuple where relevant, service availability control, enforcement decision, configuration revision, and post-change retest. Those details support a bounded conclusion an owner can act on.