6.6 Network Access Control Analysis & Firewall Rule Base Review

6.6 Network Access Control Analysis & Firewall Rule Base Review

Two syllabus items combine here. B10 (Network Access Control Analysis) asks you to review firewall rule bases and network access control lists. B6 (Filtering Avoidance Techniques) asks you to understand the importance of egress and ingress filtering, including the risks associated with outbound connections.

This is white-box work. Rather than inferring the policy by scanning through it — which section 6.4 covered — you are handed the configuration and asked what it actually permits. A rule base review routinely finds exposures that no amount of black-box scanning would reveal, because it shows you the rules that are there but not currently exercised.

---

1. Anatomy of a Rule Base

Whatever the vendor, a rule reduces to the same fields:

Two processing rules govern everything:

1. Top-down, first match wins. Evaluation stops at the first rule whose selectors match. A permissive rule high in the list makes every more restrictive rule below it irrelevant for that traffic.
2. Implicit deny at the end. Anything not matched is dropped. On Cisco IOS the implicit deny ip any any is real but never shown by show access-list, which is a classic source of misreading.

---

2. Cisco Access Control Lists

! Standard ACL - matches SOURCE address only
access-list 10 permit 10.20.30.0 0.0.0.255
access-list 10 deny   any log

! Extended ACL - matches protocol, source, destination and port
access-list 110 permit tcp 10.20.30.0 0.0.0.255 host 10.50.1.10 eq 443
access-list 110 permit tcp any host 203.0.113.25 eq 80
access-list 110 permit tcp host 203.0.113.25 any established
access-list 110 deny   ip any any log
!
interface GigabitEthernet0/1
 ip access-group 110 in

Points that are regularly examined:

• Numbering ranges. Standard ACLs use 1–99 and 1300–1999; extended ACLs use 100–199 and 2000–2699. Named ACLs (ip access-list extended OUTSIDE-IN) avoid the numbering entirely and are preferred because entries can be edited by sequence number.
• Wildcard masks are inverted subnet masks. 0.0.0.255 matches a /24; 0.0.0.0 matches a single host (equivalently written host x.x.x.x); 255.255.255.255 matches anything (equivalently any). Reading 0.0.0.255 as if it were a subnet mask is the single most common beginner error.
• Placement convention. Standard ACLs match only the source, so they are applied close to the destination to avoid blocking traffic that should reach other destinations. Extended ACLs match the full tuple and are applied close to the source to drop unwanted traffic as early as possible.
• The established keyword permits TCP segments whose ACK or RST flag is set — that is, anything that looks like a reply. It is not stateful: it inspects flags, not connection state, so a crafted packet with the ACK bit set passes straight through. Finding established used as a substitute for a stateful firewall is a genuine finding. The modern equivalent, ip inspect / Zone-Based Firewall / ASA access-list with stateful inspection, tracks real connection state.
• log and log-input. Without a log keyword on the final deny, a drop leaves no record, so the client has no evidence of attempted intrusion. log-input additionally records the ingress interface and source MAC address.

---

3. The Standard Catalogue of Rule Base Findings

These are what a review is looking for, roughly in order of severity:

1. any / any / any / accept — the "temporary rule" that was never removed. Search for it first, every time.
2. Overly broad service groups. A rule permitting an object group called WEB-SERVICES that has quietly accumulated SSH, RDP and SQL over five years of changes.
3. Overly broad network objects. A group named PARTNER-VPN containing 0.0.0.0/0, or INTERNAL containing all RFC 1918 space.
4. Rules above the clean-up rule that bypass it. A permissive rule placed at position 3 during an incident and never moved.
5. Shadowed (redundant) rules. A rule that can never match because an earlier rule already covers all of its traffic. It is not directly exploitable, but it proves the rule base is not being reviewed, and it hides the effect of later changes.
6. Orphaned rules. Rules referencing decommissioned hosts, expired projects or departed third parties. Address reuse turns these into live exposures when the IP is reallocated.
7. Management access from user subnets. SSH, HTTPS-admin, SNMP or IPMI reachable from ordinary workstation VLANs.
8. Missing logging on the deny rules, or on high-value permits.
9. No documented owner or review date. Without them the rule base cannot be maintained, and every finding above recurs.
10. Unrestricted egress — dealt with in its own section below.

A practical review technique is to expand every object group into explicit addresses and ports before reasoning about the policy. Rules that look tight at the object level are frequently wide open once expanded, and automated configuration auditing tools exist precisely to perform that expansion and flag any-any conditions, shadowed rules and unused objects.

---

4. Ingress Filtering

Ingress filtering controls what may enter a network. Beyond the obvious "only publish the services you intend to publish", the specific concept the syllabus expects is anti-spoofing.

BCP 38 / RFC 2827 states that a device should drop inbound packets whose source address could not legitimately have arrived on that interface. Concretely, on an internet-facing interface you should drop inbound packets sourced from:

• your own internal address space (a packet claiming to be from inside, arriving from outside, is spoofed);
• RFC 1918 private ranges (10/8, 172.16/12, 192.168/16);
• loopback 127/8, link-local 169.254/16, multicast 224/4 and the documentation ranges.

ip access-list extended ANTISPOOF-IN
 deny   ip 10.0.0.0 0.255.255.255 any log
 deny   ip 172.16.0.0 0.15.255.255 any log
 deny   ip 192.168.0.0 0.0.255.255 any log
 deny   ip 127.0.0.0 0.255.255.255 any log
 deny   ip 169.254.0.0 0.0.255.255 any log
 permit ip any any

Cisco's Unicast Reverse Path Forwarding (uRPF) automates this: ip verify unicast source reachable-via rx drops a packet unless the routing table says the best path back to its source address is the interface it arrived on. Widespread BCP 38 deployment is what would eliminate most reflection and amplification DDoS, which is why its absence is worth reporting even though the direct victim is somebody else.

---

5. Egress Filtering and the Risk of Outbound Connections

This is the part candidates most often underestimate, and the syllabus calls it out explicitly.

Most organisations filter inbound traffic carefully and permit outbound any to any because it is convenient. That single decision is what converts a minor foothold into a full compromise:

   Without egress control                With egress control
 ------------------------------------------------------------------
 Compromised host opens a reverse     Reverse shell on TCP 4444 is
 shell to attacker:4444        --->   dropped at the boundary
 Beacon to C2 over any port/proto     Only proxied HTTP/HTTPS with
                               --->   authentication leaves; beacons
                                      must survive inspection
 Bulk data copied out over FTP/SSH    Non-proxied protocols blocked;
                               --->   large transfers are visible
 Tool download from the internet      Blocked; attacker must stage
                               --->   tooling through the initial
                                      channel, which is noisier

Specific outbound risks to test and report:

• Arbitrary outbound TCP/UDP allows reverse shells, C2 beaconing and tunnelling on any port.
• Direct outbound DNS from clients (rather than forwarding through internal resolvers only) enables DNS tunnelling, which survives most egress policies because port 53 is almost always open.
• Outbound ICMP enables ICMP tunnelling for the same reason.
• Outbound SMTP from arbitrary hosts allows a compromised host to send mail directly, bypassing gateway logging and DLP, and makes the estate a spam source.
• Unfiltered NTP, and outbound access to arbitrary NTP servers, enables time manipulation and reflection abuse.
• Uninspected TLS means an outbound HTTPS permit is effectively an outbound any, because anything can be tunnelled inside it.

Testing Egress in Practice

The reliable method is to stand up a listener you control on the internet and attempt outbound connections from inside on every port:

# On the tester's internet-facing host: catch anything that arrives
sudo nc -lvnp 53
sudo iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port 1234   # funnel all ports

# From inside the client network: walk the port range outward
for p in 21 22 23 25 53 80 443 445 1433 3389 4444 8080 8443; do
  timeout 2 bash -c "echo probe > /dev/tcp/198.51.100.10/$p" 2>/dev/null \
    && echo "EGRESS OPEN: tcp/$p"
done

# Or drive it with Nmap from the inside, outward:
nmap -Pn -sT -p- --max-retries 1 198.51.100.10

Record exactly which ports and protocols escaped, whether the traffic was proxied or direct, and whether TLS was intercepted. That evidence is what justifies the egress recommendation, and it is the kind of finding that materially changes a client's incident-response posture.

Recommendations That Actually Work

• Default-deny outbound, with an explicit allow list of destinations and services per zone.
• Force web traffic through an authenticated, inspecting proxy; block direct outbound 80/443 from client VLANs at the firewall so the proxy cannot be bypassed.
• Allow DNS only from designated internal resolvers, and allow those resolvers to query only their configured forwarders.
• Log and alert on denied egress. A workstation repeatedly attempting outbound connections on unusual ports is one of the highest-fidelity compromise indicators an organisation has.
• Segment server egress separately. Servers rarely need general internet access at all; restricting them to patch and update sources removes most of the exfiltration surface.