Chapter 89 · Security Advisory

Firewalls

Network-based firewalls and NGFWs as Layer 7 decision engines; firewall rules, ACLs, and implicit deny; screened subnets; and IPS signature-based and anomaly-based detection integrated into modern NGFWs.

FIREWALLS-2024-001
Network-Based Firewalls and Next-Generation Firewalls
Severity: High

Overview

A network-based firewall is an inline appliance that makes allow/deny decisions for traffic crossing network boundaries. Traditional firewalls operate on port numbers and protocols; next-generation firewalls (NGFWs) operate at the application layer, analyzing the actual application in the traffic stream rather than just the port it arrives on. Both firewall types add services beyond filtering: VPN termination, NAT, and Layer 3 routing are standard features at the network ingress/egress point.

Network-Based Firewall Functions

A network firewall sits inline at the ingress/egress point separating the internet from internal networks. Its core functions extend well beyond simple packet filtering:

  • Traffic filtering — allow or deny based on port numbers (traditional) or application identity (NGFW)
  • VPN termination — acts as VPN endpoint or concentrator for site-to-site tunnels and remote access VPN connections
  • Layer 3 routing — functions as a router; performs NAT (Network Address Translation) to translate private internal addresses to public addresses and supports dynamic routing protocols
  • Ingress/egress control — positioned where the outside network meets the inside network, inspecting all traffic in both directions

Because the firewall is the routing boundary, it can enforce policies on 100% of external traffic without requiring endpoint software.

Next-Generation Firewalls (NGFW)

An NGFW operates at OSI Layer 7 (the Application Layer), which is why it is sometimes called a Layer 7 firewall. Rather than making decisions solely on port numbers, it decodes traffic, identifies the specific application, and applies policy to the application itself. This creates much more granular and accurate enforcement:

  • A traditional firewall allows TCP/80 — it allows all HTTP traffic regardless of what application is using it
  • An NGFW identifies the application by name — it can allow a corporate web app while blocking a personal social media app, even though both use TCP/80

Alternative names for NGFW technology (all mean the same thing on the exam):

  • Application layer gateway — emphasizes the Layer 7 analysis capability
  • Stateful multilayer inspection — emphasizes that it tracks connection state across multiple OSI layers simultaneously
  • Deep packet inspection (DPI) — emphasizes that it reads inside the packet payload, not just the headers

The processing cost: Every packet flowing through an NGFW must be captured, decoded, categorized into its application, and evaluated against policy. This requires significantly more processing power than a traditional firewall, which only needs to read the IP header and transport header.

Traditional Firewall vs. NGFW: Port-Based Decisions

Understanding how the two firewall types express the same security intent highlights the difference in their approach:

  • Web server traffic: Traditional = TCP/80 and TCP/443; NGFW = "allow web server" (application name)
  • SSH: Traditional = TCP/22; NGFW = "allow SSH"
  • Microsoft Remote Desktop: Traditional = TCP/3389; NGFW = "allow RDP"
  • DNS queries: Traditional = UDP/53; NGFW = "allow DNS"
  • Network Time Protocol: Traditional = UDP/123; NGFW = "allow NTP"

NGFWs can use both approaches simultaneously: an NGFW policy can reference application names for supported applications and fall back to port-based rules for everything else, giving flexibility without sacrificing coverage.

Key Terms

  • NGFW — Next-Generation Firewall; Layer 7 application-aware firewall
  • Deep packet inspection — reading inside the packet payload to identify application and content
  • Stateful multilayer inspection — tracking connection state across multiple OSI layers
  • NAT — Network Address Translation; translates private IPs to public IPs at the firewall
  • Ingress/egress — the point where traffic enters (ingress) and exits (egress) the network
FIREWALLS-2024-002
Firewall Rules, ACLs, and Screened Subnets
Severity: High

Overview

Firewall rules define which traffic is allowed or denied. Rules are evaluated in order from top to bottom; the first matching rule determines the outcome. Most firewalls end with an implicit deny that drops any traffic not matched by an explicit rule. Rules are organized as Access Control Lists (ACLs). Screened subnets (sometimes called DMZs) use firewall architecture to separate publicly accessible services from sensitive internal resources.

How Firewall Rules Work

Top-to-bottom evaluation: The firewall reads rules starting at rule 1 and proceeds downward. The moment a packet matches a rule, that rule's action (allow or deny) is applied and evaluation stops. No further rules are checked for that packet.

Specific rules before general rules: Because the first match wins, specific rules must appear above broad rules. A rule allowing a specific IP address must appear above a rule that denies all traffic from a subnet, otherwise the broad rule matches first and the specific exception is never reached.

Implicit deny: Most firewalls include a hidden deny-all rule at the very bottom of the rule base. Traffic that does not match any explicit rule is automatically dropped. The implicit deny does not need to be written by the administrator — it is enforced even if absent from the visible rule list. This is the default-deny security model: everything not explicitly allowed is forbidden.

Access Control Lists (ACLs)

The firewall rule base is also called an Access Control List. Each ACL entry can filter on multiple parameters simultaneously:

  • Source IP address — where the traffic is coming from
  • Destination IP address — where the traffic is going
  • Port number — source and/or destination port (TCP or UDP)
  • Protocol — TCP, UDP, ICMP, or others
  • Application — NGFW only; identifies the application by name
  • User — NGFW with user authentication integration
  • Time of day — allow traffic only during business hours, for example
  • Web category / URL list — NGFW; blocks categories of websites

A practical rule example from an inbound ACL on a server firewall: Allow all remote IPs on TCP/22 (SSH); Allow all remote IPs on TCP/80 (HTTP); Allow all remote IPs on TCP/443 (HTTPS); Allow all remote IPs on TCP/3389 (RDP); Allow all remote IPs on UDP/53 (DNS); Allow all remote IPs on UDP/123 (NTP); Deny all remote IPs on ICMP (block ping); Implicit deny everything else.

Screened Subnets (DMZ)

A screened subnet is an additional network zone created by the firewall architecture that sits between the internet and the internal private network. It addresses a fundamental problem: some servers must be accessible from the internet (web servers, email servers, DNS servers) but placing them on the internal network exposes that network to internet traffic.

Architecture: The firewall connects to three networks: the internet, the screened subnet (public zone), and the internal network (private zone). Internet traffic is permitted to reach the screened subnet but cannot pass through to the internal network. The screened subnet contains publicly accessible services; the internal network contains sensitive systems and confidential data.

Security benefit: Even if an attacker fully compromises a server in the screened subnet, they are still blocked from reaching the internal network by the firewall. The breach is contained within the screened subnet.

A screened subnet is often called a DMZ (demilitarized zone) — the terms are interchangeable on the exam.

Key Terms

  • ACL — Access Control List; the firewall's ordered rule list
  • Implicit deny — default-deny rule at the bottom; drops all traffic not explicitly allowed
  • Screened subnet — isolated zone between internet and internal network hosting public-facing services
  • DMZ — Demilitarized Zone; synonym for screened subnet
  • Top-to-bottom evaluation — first matching rule wins; specific rules must precede general rules
FIREWALLS-2024-003
IPS Rules: Signature-Based and Anomaly-Based Detection
Severity: Medium

Overview

Intrusion Prevention Systems (IPS) are commonly integrated into NGFWs as a distinct rule engine that monitors traffic for malicious patterns beyond simple port/application filtering. An IPS can contain thousands of rules organized into groups, and uses two primary detection methods: signature-based (exact pattern matching against known attacks) and anomaly-based (behavioral deviation from a normal baseline). Managing IPS rules requires continuous tuning to balance security against alert noise.

IPS Integration and Architecture

The IPS is typically embedded within the NGFW rather than deployed as a separate device. It shares the same traffic stream but maintains its own rule base separate from the firewall ACL. While the firewall ACL decides whether traffic is allowed or denied by application or port, the IPS inspects the content of allowed traffic for malicious activity:

  • Firewall rule allows TCP/443 inbound
  • IPS then inspects the HTTPS payload for known exploit patterns, malware signatures, and anomalous behavior

This layered model means the IPS catches threats that pass through the firewall's allow rules — threats hiding inside legitimate protocols.

Signature-Based Detection

Signature-based detection compares network traffic against a database of known attack patterns. Each signature describes a specific sequence of bytes, headers, or behaviors associated with a known exploit or malware variant. If traffic matches the signature exactly, the IPS triggers its configured response.

Strengths: Extremely accurate against known threats; very low false positive rate for well-written signatures; immediate detection when a match occurs.

Limitations: Only detects what it has a signature for; new or modified attacks that do not match any signature pass undetected. This is the core weakness against zero-day exploits and novel malware variants.

Exam example: A signature written for the Conficker worm looks for a specific byte sequence in network traffic. When that exact sequence appears, the IPS can block it immediately. Modifying the worm even slightly may defeat the signature.

Anomaly-Based Detection

Anomaly-based detection establishes a baseline of normal network behavior, then flags deviations. Instead of matching known patterns, it asks: "Does this traffic look different from what we normally see?"

Strengths: Can detect previously unknown attacks, zero-day exploits, and malware that has no signature. Also effective against generic attack classes such as SQL injection attempts, port scans, and brute force patterns, even when specific signatures do not exist.

Limitations: Generates more false positives than signature-based detection because legitimate traffic sometimes looks anomalous. Requires a well-established baseline; a baseline built during an attack period will treat attack patterns as "normal."

The exam scenario: an IPS configured to recognize what "a generic database injection looks like" can block SQL injection attempts even without a specific CVE signature — that is anomaly-based detection.

IPS Rule Management and Tuning

Enterprise IPS systems contain thousands of rules. Managing them individually is impractical, so rules are organized into groups:

  • Groups are often pre-created by the IPS software vendor (database rules, web application rules, OS exploit rules, malware command-and-control rules)
  • Administrators can create custom groups or adjust group settings
  • A single policy decision — "block all database injection rules" — applies to thousands of rules simultaneously by targeting the group

The tuning challenge: Every IPS deployment requires ongoing tuning to find the right balance:

  • Too aggressive: legitimate traffic is blocked (false positives), causing business disruption and alert fatigue
  • Too permissive: real attacks are missed (false negatives), undermining security
  • Tuning is never complete — new traffic patterns, new applications, and new attacks require constant rule adjustments

When an IPS rule causes a false positive, the IPS can be reconfigured to exclude that specific traffic pattern while keeping the broader rule active — avoiding both the attack risk and the business disruption.

IPS Response Actions

When the IPS detects a match, it can take several actions depending on configuration:

  • Block — drop the packet and terminate the connection; most aggressive response
  • Allow — permit the traffic but log the event for later analysis
  • Alert — send a notification to the security team without necessarily blocking
  • Monitor — track the traffic pattern for additional analysis before taking action

Key Terms

  • IPS — Intrusion Prevention System; monitors and blocks malicious traffic inline
  • Signature-based detection — matches traffic against known attack patterns; accurate but misses unknowns
  • Anomaly-based detection — detects deviation from baseline; finds zero-days but generates more false positives
  • IPS rule groups — collections of rules managed with a single policy setting
  • False positive — legitimate traffic flagged as malicious; drives tuning effort
  • Tuning — ongoing process of adjusting IPS rules to balance security and operational noise