7.1 Proxy Policies & Proxy Actions

7.1 Proxy Policies & Proxy Actions

Quick Answer: Fireware proxy policies enforce Layer 7 security using a dual-connection architecture: the Firebox terminates the client's TCP connection, decodes and inspects protocol syntax and payloads against security subscriptions, and opens an independent TCP connection to the destination server. Unlike packet filters that only inspect 5-tuple headers at wire speed, proxies enforce strict RFC conformance, prevent buffer overflows, and strip sensitive server headers. Predefined Proxy Actions (e.g., HTTP-Client.Standard) are permanently read-only to protect baseline security; administrators must clone them into custom proxy actions to enable subscription engines, restrict HTTP methods (e.g., blocking PUT/DELETE), enforce MIME type validation, and block executable file extensions.

---

Dual-Connection Proxy Architecture in Fireware

At the foundation of WatchGuard Fireware's application-layer defense lies the dual-connection proxy model. In conventional stateful packet filtering, a firewall monitors the TCP three-way handshake and allows IP packets to traverse between client and server directly, modifying only IP and port headers when Network Address Translation (NAT) is applied. In contrast, an application proxy terminates direct communication entirely.

+---------------------------------------------------------------------------------------------------+
|                         FIREWARE DUAL-CONNECTION PROXY ARCHITECTURE                               |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|   [Client Workstation]                                                        [Remote Web Server] |
|      10.0.1.50:49210                                                             203.0.113.80:80  |
|             |                                                                           |         |
|             |  TCP Connection 1 (Client <-> Firebox)                                    |         |
|             +=======================> [Firebox Proxy Engine]                            |         |
|                                       | - Terminate TCP Handshake                       |         |
|                                       | - Protocol Conformance (RFC)                    |         |
|                                       | - Reassemble TCP Streams                        |         |
|                                       | - Security Subscriptions:                       |         |
|                                       |   * Gateway AntiVirus                           |         |
|                                       |   * Intrusion Prevention                        |         |
|                                       |   * APT Blocker & IntelligentAV                 |         |
|                                       |   * WebBlocker Categorization                   |         |
|                                       | - Header Sanitization                           |         |
|                                       |                                                 |         |
|                                       |  TCP Connection 2 (Firebox <-> Server)          |         |
|                                       +================================================>+         |
|                                                                                                   |
|   * RESULT: The client and server NEVER exchange raw IP packets directly at any point.            |
+---------------------------------------------------------------------------------------------------+

The Operational Sequence of a Proxy Session

When a client behind a Firebox initiates an outbound connection governed by an application proxy policy (such as HTTP-proxy or HTTPS-proxy):

1. Client Connection Termination (Connection 1): The Firebox intercepts the client's initial TCP SYN packet and completes the three-way handshake with the client on behalf of the destination server. The client believes it is communicating directly with the external host, but the TCP socket terminates inside the Firebox proxy daemon.
2. Protocol Parsing & Syntax Validation: The proxy engine reads the incoming data stream, parsing application-layer commands, headers, and encoding formats. It verifies that the traffic strictly complies with official Internet Engineering Task Force (IETF) Request for Comments (RFC) standards for that protocol.
3. Stream Reassembly & Buffer Inspection: Fragmented packets are reassembled in memory buffers. This allows deep inspection engines to reconstruct entire files, MIME types, and scripts. The reassembled payload is submitted to active security subscriptions, including Gateway AntiVirus (GAV), IntelligentAV, Intrusion Prevention Service (IPS), and APT Blocker.
4. Server Connection Initiation (Connection 2): If the application data passes all security checks and policy rules, the Firebox initiates an entirely separate TCP three-way handshake to the destination server using its own external IP address (or the appropriate NAT address).
5. Sanitized Payload Forwarding: The Firebox transmits the validated, sanitized application request to the server. When the server replies, the return stream undergoes identical deep inspection in reverse before the Firebox packages the response and transmits it across Connection 1 to the client.

---

Comparison: Packet Filters vs. Application Proxy Policies

To pass the WatchGuard Network Security Essentials exam, administrators must understand the technical and operational differences between packet filters and proxy policies across all layers of the OSI model.

Why Packet Filters Cannot Stop Modern Application Attacks

Stateful packet filters are engineered for high-velocity traffic forwarding based on state tables. If an attacker crafts an HTTP GET request containing an SQL injection attack (' OR '1'='1) or delivers a zero-day ransomware payload across TCP port 80, a packet filter evaluates only the Layer 3 and Layer 4 headers. Because TCP port 80 is permitted, the packet filter passes the malicious payload straight through to the web server or workstation. Only an application proxy with active subscription services can disassemble the payload, identify the malicious signature or heuristic pattern, and drop the connection.

---

Built-in Proxy Policy Types in Fireware

Fireware OS provides a comprehensive library of protocol-specific application proxies. Each proxy is engineered around the specific state machine, syntax rules, and RFC standards of its respective protocol.

+---------------------------------------------------------------------------------------------------+
|                                 FIREWARE BUILT-IN PROXY POLICY TYPES                              |
+-------------------+---------------+---------------------------------------------------------------+
| PROXY POLICY TYPE | DEFAULT PORT  | PRIMARY PROTOCOL INSPECTION CAPABILITIES                      |
+-------------------+---------------+---------------------------------------------------------------+
| HTTP-proxy        | TCP 80        | URL paths, HTTP methods, MIME types, file extensions, headers |
| HTTPS-proxy       | TCP 443       | SNI domain filtering, TLS handshake validation, DPI bridge    |
| SMTP-proxy        | TCP 25        | Email commands (HELO, MAIL FROM, RCPT TO), spamBlocker, TLS   |
| FTP-proxy         | TCP 21        | Passive/Active mode negotiation, FTP commands (PUT, GET, DELE)|
| DNS-proxy         | UDP/TCP 53    | Query length, opcode checking, domain rules, DNSWatch security|
| POP3-proxy        | TCP 110       | Post Office Protocol email retrieval, spamBlocker, AV scanning|
| TCP-UDP-proxy     | Custom Ports  | Generic Layer 7 proxy for non-standard or proprietary traffic |
+-------------------+---------------+---------------------------------------------------------------+

Detailed Analysis of Core Proxy Types

1. HTTP-proxy (TCP Port 80)

Intersects standard unencrypted web traffic. It provides the most granular rule categories in Fireware, allowing administrators to filter on request methods, header values, URL paths, MIME types, and file transfers, while simultaneously coordinating with WebBlocker and Gateway AntiVirus.

2. HTTPS-proxy (TCP Port 443)

Manages encrypted Transport Layer Security (TLS) and Secure Sockets Layer (SSL) sessions. It operates in two modes: Server Name Indication (SNI) Domain Filtering (inspecting only the unencrypted domain header) or Deep Packet Inspection (DPI) (terminating the TLS tunnel, decrypting plaintext, passing it to an internal HTTP-proxy action, and re-encrypting).

3. SMTP-proxy (TCP Port 25)

Protects incoming and outgoing corporate mail transfer agents (MTAs). It inspects SMTP command verbs (such as HELO, EHLO, MAIL FROM, and RCPT TO), validates sender/recipient address syntax, restricts maximum message sizes, enforces STARTTLS encryption, and routes message attachments to Gateway AntiVirus, APT Blocker, and spamBlocker.

4. FTP-proxy (TCP Port 21)

Inspects File Transfer Protocol control channels and dynamically opens ephemeral data ports for Active and Passive FTP transfers. It restricts dangerous commands (e.g., blocking DELE or MKD while permitting RETR), validates filename formats, blocks malicious file uploads/downloads, and prevents FTP bounce attacks.

5. DNS-proxy (UDP/TCP Port 53)

Inspects Domain Name System queries and replies. It mitigates DNS tunneling, DNS cache poisoning, and amplification attacks by enforcing maximum query and response lengths, disallowing illegal resource record types, validating transaction IDs, and integrating with DNSWatch to redirect malicious domain queries to secure blackhole sinkholes.

6. POP3-proxy (TCP Port 110)

Secures legacy client email retrieval sessions, scanning incoming messages and attachments for malware before they land in user desktop email clients.

7. TCP-UDP-proxy (Custom Ports)

A versatile, generic proxy engine used to apply Layer 7 inspection rules to applications that utilize non-standard port numbers or proprietary protocols. It enables administrators to enforce byte patterns, connection timeouts, and basic protocol anomalies without requiring a dedicated protocol parser.

---

Predefined vs. Custom Proxy Actions

Every proxy policy in Fireware is paired with a Proxy Action. While the proxy policy defines who can connect to what (the From and To rules, schedule, and port binding), the Proxy Action contains the actual Layer 7 inspection rule book.

+---------------------------------------------------------------------------------------------------+
|                         PREDEFINED vs CUSTOM PROXY ACTION WORKFLOW                                |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  [Predefined Proxy Action]                                                                        |
|  Name: HTTP-Client.Standard                                                                       |
|  Status: LOCKED / READ-ONLY                                                                       |
|  Purpose: Guaranteed secure baseline; cannot be edited or modified directly.                      |
|                                                                                                   |
|           |                                                                                       |
|           | 1. Clone Action (Policy Manager or Web UI)                                            |
|           v                                                                                       |
|                                                                                                   |
|  [Custom Proxy Action]                                                                            |
|  Name: HTTP-Client.Corporate_Secure                                                               |
|  Status: UNLOCKED / EDITABLE                                                                      |
|  Modifications:                                                                                   |
|  • Enable Gateway AntiVirus, APT Blocker, WebBlocker                                              |
|  • Block HTTP Request Methods: PUT, DELETE, TRACE                                                 |
|  • Block MIME Types: application/x-msdownload, application/x-dosexec                              |
|  • Block File Extensions: .exe, .bat, .ps1, .vbs, .iso                                            |
|  • Strip Response Headers: Server, X-Powered-By                                                   |
|                                                                                                   |
|           |                                                                                       |
|           | 2. Bind to Proxy Policy                                                               |
|           v                                                                                       |
|                                                                                                   |
|  [HTTP-proxy Policy]                                                                              |
|  From: Any-Trusted  --->  To: Any-External  --->  Proxy Action: HTTP-Client.Corporate_Secure      |
+---------------------------------------------------------------------------------------------------+

Why Predefined Proxy Actions Cannot Be Edited Directly

When an administrator opens Policy Manager or the Fireware Web UI, Fireware presents several built-in predefined actions, such as HTTP-Client.Standard, HTTP-Server.Standard, HTTPS-Client.Standard, and SMTP-Incoming.Standard.

• Locked Architectural Integrity: Predefined proxy actions are hardcoded templates designed to adhere to standard industry practices. They are strictly read-only.
• Protection Against Configuration Drift: If administrators could alter predefined actions directly, an inadvertent misconfiguration could compromise multiple policies across the firewall or leave the system without a reliable reference configuration.
• The Cloning Workflow: To implement custom inspection rules, administrators must clone a predefined action:
  1. Open the proxy policy properties and navigate to the Proxy Action selection menu.
  2. Select the predefined action (e.g., HTTP-Client.Standard) and click Clone.
  3. Assign a meaningful name (e.g., HTTP-Client.Finance or HTTP-Client.Branch).
  4. The newly created custom proxy action is now editable, unlocking all configuration tabs, subscription toggles, and pattern tables.
  5. Save the policy and save the configuration to the Firebox.

Rule Hierarchy and Action Outcomes Inside Proxy Actions

Within a proxy action, rules are organized across functional tabs (e.g., HTTP Request Methods, Path, MIME Types). Within each tab, Fireware evaluates rules in a hierarchical, first-match order:

• Exact Match First: Exact strings or explicit definitions take precedence over wildcard patterns.
• Wildcard Expressions: Fireware supports standard wildcards: * represents zero or more characters, while ? represents a single character.
• Configurable Action Outcomes: When incoming traffic matches a rule, the administrator can assign one of several actions:
  • Allow: The request or response is permitted to pass without modification.
  • Drop: The packet or connection is silently discarded without notifying the client, exhausting attacker timeouts.
  • Block: The connection is severed immediately, and the remote host's IP address can optionally be added to the Firebox Auto-Block list.
  • Strip (Headers): Removes the matching header from the HTTP stream while allowing the remainder of the payload to pass.
  • Quarantine (Email): Available in the SMTP proxy; places suspicious attachments or messages into the Quarantine Server database for administrative review.

---

Granular Content Filtering Rules in HTTP-Proxy

The HTTP-Client proxy action provides the most common real-world content filtering controls tested on the certification exam.

1. HTTP Request Methods (Verbs)

HTTP defines methods that specify the desired action to be performed on a resource (RFC 7231). In a standard web browsing environment, clients primarily require read and submission capabilities:

• Permitted Safe Methods: GET (retrieve web resources), POST (submit web forms and data), and HEAD (retrieve header metadata).
• High-Risk Methods: PUT (upload files to a web server), DELETE (remove resources from a web server), TRACE / TRACK (echo client requests, vulnerable to Cross-Site Tracing attacks), and OPTIONS (query server capabilities, often used for reconnaissance).
• The CONNECT Method: Used to establish a two-way tunnel through an unencrypted HTTP proxy, commonly leveraged to tunnel TLS or non-HTTP traffic. In an HTTP-Client action, CONNECT is typically denied to prevent users from bypassing port restrictions; TLS traffic should traverse the dedicated HTTPS-proxy instead.
• Default Action for Undefined Methods: Administrators can set an explicit action (e.g., Block or Drop) for any method not specifically listed in the table, protecting against non-standard or malformed HTTP verbs used in exploit payloads.

2. URL Path and Query String Matching

The Path tab allows administrators to inspect and filter the uniform resource identifier (URI) path following the domain name (e.g., in http://example.com/downloads/setup.exe, the path is /downloads/setup.exe):

• Blocking Malicious Endpoints: Administrators can define wildcard path rules, such as */admin/*, *.php?id=*, or */wp-login.php, to prevent internal users from accessing unauthorized management portals or to shield internal web servers.
• Case Sensitivity: Fireware allows administrators to configure whether URL path matching is case-sensitive or case-insensitive, ensuring that requests for /PAYROLL/ and /payroll/ are evaluated consistently.

3. MIME Type Filtering

MIME (Multipurpose Internet Mail Extensions) types define the media format of content transmitted across HTTP, conveyed through the Content-Type header (e.g., text/html, image/png, application/pdf).

• Detecting Disguised Payloads: Attackers frequently disguise dangerous executable files by appending benign file extensions (such as naming a trojan quarterly_report.pdf or photo.jpg). However, when the web server transmits the file, its web daemon sends the actual MIME type application/x-msdownload or application/octet-stream.
• Content-Type Inspection: The Firebox HTTP proxy inspects the Content-Type header of inbound HTTP responses. If the MIME type matches a blocked entry (e.g., application/x-dosexec), the Firebox terminates the download immediately, regardless of what file extension was requested in the URL.
• Magic Byte Stream Verification: When Gateway AntiVirus is active, the proxy also reads the initial bytes of the file stream ("magic numbers," such as MZ for Windows PE binaries or PK for ZIP archives) to verify that the payload content matches the declared MIME type.

4. File Extension Blocking

Under the Transfer Encoding > File Extensions tab, administrators define rules based on the filename extension requested in the HTTP session:

• Common Blocked Categories: Executable files (.exe, .com, .scr, .pif, .msi), script files (.bat, .cmd, .vbs, .ps1, .js), disk images (.iso, .vhd, .img), and dynamic libraries (.dll, .so).
• Dual-Extension Defense: Fireware evaluates the entire filename string, defeating evasive naming techniques such as document.pdf.exe or invoice.docx.vbs.

5. HTTP Header Sanitization & Information Disclosure Prevention

Both request and response headers can be inspected, stripped, or modified:

• Inbound Server Banners: Web servers automatically broadcast software information in HTTP responses using the Server header (e.g., Server: Apache/2.4.41 (Ubuntu)) and application framework headers like X-Powered-By: PHP/7.4.3 or X-AspNet-Version: 4.0.30319. Attackers use these banners to identify vulnerabilities for targeted exploitation. In an HTTP-Server proxy action, administrators configure Fireware to strip or replace these headers with generic values.
• Client Header Scrubbing: For outbound traffic, the proxy can strip sensitive client information, such as stripping internal IP addresses from Via or X-Forwarded-For headers, or enforcing standardized User-Agent strings to prevent endpoint profiling.

Proxy Action Configuration Matrix

The following table summarizes the primary configuration tabs within a custom HTTP-Client Proxy Action: