Firewalls -- Tricks

Trick 1 NGFW Has Four Names — All Mean the Same Thing

The exam uses all four names interchangeably. If a question describes any of these, it is describing an NGFW:

Next-Generation Firewall (NGFW) — the primary term
Application layer gateway — emphasizes Layer 7 operation
Stateful multilayer inspection — emphasizes cross-layer state tracking
Deep packet inspection (DPI) — emphasizes payload reading vs. header-only

The decision rule for NGFW vs. traditional firewall questions: If the scenario requires distinguishing between applications that use the same port, the answer is always NGFW. A traditional firewall makes decisions at the port level only — it cannot tell YouTube from a corporate web portal if both use TCP/443. When the answer requires per-application control, NGFW is correct.

Memory hook: DPI = reads inside the packet (not just the label). Stateful multilayer = tracks the whole conversation across all layers. Application layer gateway = decides at the application, not the port.

Rule: If a question names any of these four — NGFW, application layer gateway, stateful multilayer inspection, deep packet inspection — they all describe the same technology. If per-application control is needed, the answer is NGFW.

Trick 2 Implicit Deny Catches What You Forgot, Not What You Blocked

The exam has a consistent trap: a scenario shows a firewall with several allow rules but no explicit deny at the bottom, then asks what happens to traffic that does not match any rule. The answer is always: the implicit deny drops it. The implicit deny does not need to be written — it is enforced automatically.

The companion trap: A broad allow rule placed above a specific deny rule silently overrides the deny. The implicit deny only helps for traffic that reaches the bottom of the rule list. If an overly broad allow rule at the top captures traffic that was supposed to be denied by a rule below, the implicit deny never comes into play. The mistake is the allow rule ordering, not the absence of a deny.

Key facts to memorize:

Implicit deny = drop anything not explicitly allowed; present in virtually all firewalls
Top-to-bottom evaluation = first match wins; rules below the first match are irrelevant for that traffic
Specific before general = the most granular rules go at the top
ICMP has no port number — ICMP rules cannot reference TCP or UDP ports

Rule: Implicit deny drops everything not explicitly allowed. But a misplaced broad allow rule prevents specific deny rules below it from ever running. Both mechanisms are tested: implicit deny AND rule order.

Trick 3 Screened Subnet Limits Blast Radius — It Does Not Prevent Compromise

The exam tests whether candidates understand what a screened subnet does and does not do. The screened subnet does NOT prevent an attacker from compromising the public-facing server. It DOES prevent a compromised public server from becoming a launchpad into the internal network.

The exam trap: A question describes an attacker who compromised a web server in the DMZ and asks what security control "prevented access to the internal database." The answer is the screened subnet architecture (firewall rules blocking DMZ-to-internal traffic), not the web server's security configuration.

What goes where:

Screened subnet / DMZ: web servers, email servers, public DNS servers, any service that must accept internet connections
Internal network: databases, file servers, internal applications, confidential data, employee workstations

The firewall rule model: Internet → DMZ is allowed for specific ports (TCP/80, TCP/443). DMZ → internal is blocked except for the minimum required (e.g., TCP/3306 from web server to database only). Internal → DMZ management traffic is allowed as needed.

Rule: Screened subnet contains the blast radius after compromise. It does not stop the initial breach. Public services go in the DMZ; private data stays internal. A compromised DMZ server cannot reach internal systems.

Trick 4 Signature vs. Anomaly: Zero-Day = Anomaly; Known Attack = Signature

The exam tests whether candidates can match the IPS detection scenario to the correct detection method. The decision is mechanical once you know the rule:

Known attack with existing signature → signature-based detection
New / zero-day / novel attack with no signature → anomaly-based detection
Legitimate traffic flagged as malicious → false positive (from anomaly-based, usually)
Real attack missed → false negative (from signature-based missing unknowns)

The exam scenario pattern: "The IPS detected an attack even though no signature had been published for it yet." → Anomaly-based. "The IPS compared traffic to a database of known attack patterns." → Signature-based. "The IPS established a baseline of normal behavior and flagged deviations." → Anomaly-based.

Why both are needed: Signature-based is fast and accurate for known threats. Anomaly-based catches unknowns but generates false positives. Running both together means known threats are caught by signatures (low false-positive cost), and zero-days get a second chance through anomaly detection.

Rule: Zero-day or "no signature exists" = anomaly-based. Known malware or "matched a pattern" = signature-based. False positives come from anomaly over-sensitivity. False negatives come from missing signatures.

Practice Scenarios

Scenario A: A company's security policy states that employees may use LinkedIn for business development but may not use Facebook, Instagram, or Twitter during work hours. All four platforms use HTTPS (TCP/443). The network engineer needs to implement this policy at the perimeter firewall. What type of firewall is required, why does a traditional firewall fail, and what specific capability does the solution use?

Answer: An NGFW (Next-Generation Firewall) is required. A traditional firewall fails because all four platforms — LinkedIn, Facebook, Instagram, and Twitter — use TCP/443. A traditional firewall rule can only allow or deny TCP/443 as a whole. Blocking TCP/443 would block LinkedIn along with the others and break all HTTPS business traffic. Allowing TCP/443 allows all four platforms. There is no port-based rule that distinguishes between them. An NGFW solves this with application-layer awareness (deep packet inspection / Layer 7 analysis). The NGFW decodes the HTTPS traffic, identifies the specific application by name, and applies the policy to the application rather than the port. The rule set becomes: allow LinkedIn (application name); deny Facebook, Instagram, Twitter (application names); allow all other HTTPS. The NGFW enforces this even though all four use the same TCP/443 port.

Scenario B: A firewall administrator reviews an ACL and finds these rules: (1) Deny TCP/22 from 10.0.0.0/8; (2) Allow SSH from 10.10.1.50; (3) Allow TCP/443 from any; (4) Implicit deny. A security audit finds that a specific management workstation at 10.10.1.50 cannot SSH to the firewall even though rule 2 explicitly allows it. What is the problem, and what is the fix?

Answer: The problem is rule order. Rule 1 denies all TCP/22 traffic from the entire 10.0.0.0/8 network. The management workstation 10.10.1.50 is within the 10.0.0.0/8 range (10.x.x.x). When the workstation attempts SSH, the firewall evaluates rules top to bottom: Rule 1 matches (10.10.1.50 is in 10.0.0.0/8, TCP/22) and denies the connection. The evaluation stops. Rule 2 (allow SSH from 10.10.1.50) is never reached because Rule 1 already matched. The fix: swap Rule 1 and Rule 2 so the more specific rule (allow from 10.10.1.50) appears first. The corrected order: (1) Allow TCP/22 from 10.10.1.50; (2) Deny TCP/22 from 10.0.0.0/8; (3) Allow TCP/443 from any; (4) Implicit deny. Now when 10.10.1.50 connects via SSH, Rule 1 matches and allows it. When any other 10.x.x.x address attempts SSH, Rule 1 does not match (wrong source), Rule 2 matches and denies it. Specific rules must always appear before general rules that would swallow the exception.

Scenario C: An organization's IPS has been running for six months with a well-tuned signature database and an anomaly-based engine using a four-month behavioral baseline. On a Monday morning, two alerts fire simultaneously: Alert 1 identifies traffic matching a Conficker worm signature on an internal workstation. Alert 2 flags unusual outbound traffic from a different workstation — 800 MB sent to an external IP at 2 AM, 400 times the baseline average. No signature matches Alert 2's traffic. What detection method generated each alert, what does each alert most likely represent, and what should the incident response team do first?

Answer: Alert 1 was generated by signature-based detection. The Conficker worm has a well-known signature in the IPS database; the traffic matched the specific byte pattern associated with the worm. This workstation is actively running or propagating Conficker. Alert 2 was generated by anomaly-based detection. No signature matched the traffic, but the behavioral deviation — 800 MB outbound to an external IP overnight vs. a baseline of under 2 MB — triggered the anomaly engine. This pattern is a strong indicator of data exfiltration: large volume, unusual timing (2 AM), unfamiliar destination. The incident response team should address both simultaneously but prioritize Alert 2 if resources are limited. Conficker is a known, containable threat — the signature-based detection means the IPS is already blocking propagation. The anomaly alert represents a potential active exfiltration in progress: if data is still being transferred, immediate action (isolating the workstation and blocking the external IP) can stop the exfiltration mid-transfer. For Alert 1, quarantine the infected workstation, scan for additional infections, and apply the relevant patches. For Alert 2, isolate the workstation, preserve forensic artifacts, and investigate what data may have left the network.

Firewalls — Exam Tricks