ZIA Security Controls Deep-Dive: Firewall, DNS, File Type & IPS

Why all four matter — one is never enough

Most network engineers arrive at Zscaler thinking "firewall = security". In a perimeter box that is roughly true. In a cloud proxy with full SSL inspection, it is wrong by a factor of four.

A real attack chain has at least four touch-points and ZIA inspects each one with a separate engine:

• A user clicks a phishing link → DNS Control resolves (or blocks) the lookup.
• The browser opens a TCP session to the resolved IP → Cloud Firewall permits or denies the 5-tuple, the application, and the user.
• The page tries to push an HTML smuggled .iso down to the laptop → File Type Control inspects the real MIME and extension and stops it.
• Hidden inside an allowed download is a CVE-2024-XXXX exploit payload → IPS Control matches the signature in the decrypted stream and drops the connection.

Disable any one of these and the chain completes. This is why Zscaler runs all four in a single SSE proxy hop with shared state — not as four serial appliances. Get the ordering wrong and a "permit" in one family silently overrides a "deny" in another.

The ZIA policy pipeline — where each control sits

Before we open any single rule, look at the whole pipeline. This is the order every TCP/UDP flow walks through inside a ZIA Service Edge:

Three properties of this pipeline matter for every rule you write:

1. First-match-wins inside a family. Each control family evaluates its own rules top-down. The first matching rule with an action (Allow / Block / Caution) wins for that family — but the flow still continues to the next family.
2. Any single Block ends the flow. A Block at any one family terminates the connection immediately. You do not need the same Block restated four times.
3. Allow is not the same as Bypass. An Allow in Cloud Firewall still hands the flow to DNS Control, URL Filtering, IPS, and so on. A Bypass (in SSL inspection policy or in DNS Control) actually removes the flow from later inspection — that is a much bigger commitment.

Section A — ZIA Cloud Firewall

The Cloud Firewall sits at the front of the pipeline and is the only family that can act on a flow before SSL inspection. That makes it the right place for two things: 5-tuple decisions (which IPs / ports talk to whom) and application-aware allow/deny (Teams audio vs Teams file-share).

What it inspects

• 5-tuple — source/destination IP, source/destination port, protocol.
• Network Application — Zscaler maintains an application library (~3,000+ entries) that classifies flows by behavior, not just port. A custom client running TLS on port 8443 will still be classified as "Generic TLS" until you write a signature.
• Network Service — bundles of ports/protocols (e.g. "HTTPS", "DNS", "SMTP") so you don't have to list ports raw.
• User / Group / Department — pushed from the IdP (Okta, Entra ID, etc.). Lets you write "Finance team can talk to Bloomberg Terminal" instead of "subnet x.x.x.x can".
• Location / Sub-location — the company office or VPN exit that the flow appeared from.
• Time window — only allow outbound SSH 09:00-19:00 weekdays, etc.

Rule order and the implicit default

Cloud Firewall rules live in Policy → Cloud Firewall Control → Firewall Filtering Policy. They are numbered, top-down, first-match. The very last rule in every tenant is the system-default "Default Firewall Filtering Rule" — Allow Any/Any. Most engineers leave it as Allow because ZIA's other layers will catch the rest. Some banks flip it to Block and write explicit Allows for every permitted protocol — far more work, lower blast radius.

Rule Name      : Block-SMB1-Outbound
Order          : 5
Rule Status    : Enabled
Locations      : All Branches
Users          : Any
Network Service: SMB (TCP 445), NetBIOS (TCP 139)
Network App    : SMB
Source IP      : Any
Dest IP / FQDN : Any
Action         : Block / Drop
Send ICMP rst  : No (silent drop)
Logging        : Full
Description    : SMB1 deprecated CY24, leaking creds — block at edge.

NAT, DNS-Tunnel control and the "Enable IPS Control" toggle

Two often-missed Cloud Firewall features:

• NAT control — at the firewall rule level you can choose source NAT (default — flows leave the Service Edge using the public IP of the data center), or a customer-provided dedicated egress IP if you bought one. Important for SaaS apps that allowlist by IP.
• "Enable IPS Control" checkbox on each firewall rule — even after the IPS module is licensed and turned on globally, you can selectively turn it off per firewall rule. Useful for an Allow rule that carries known-safe machine-to-machine traffic where IPS would chew CPU and add latency for no benefit. Default = on.

# 1) Confirm the rule applied
#    Admin Portal → Analytics → Insights → Firewall Insights → filter on the user + last 1 hour

# 2) Trigger the rule from the user side
nc -zv 198.51.100.5 445       # expect immediate "Connection refused" or "operation timed out"
                              # if you get a TCP handshake, the rule did not match — re-check criteria

# 3) Confirm the policy decision in the log
#    The Firewall Insights row must show:
#      Action = Blocked  ·  Rule Name = Block-SMB1-Outbound  ·  Reason = Match on Network Service

Section B — DNS Control

DNS Control is the smallest, fastest, and most under-used family. A modern attack starts with a domain lookup. If you stop the lookup, you stop the attack — without paying for SSL inspection or IPS CPU cycles on the same traffic.

What it inspects and where it sits

DNS Control runs before SSL inspection because DNS is its own protocol over UDP/53 (and increasingly TCP/853 DoT, TCP/443 DoH). The control:

• Categorizes the queried domain using Zscaler's URL Database (Malware, Phishing, Newly Registered Domain, Adult, etc. — same categories used by URL Filtering).
• Decides which DNS resolver to use (Zscaler's Trusted Resolver, your enterprise resolver, a public resolver like 8.8.8.8, or a custom DNS Gateway).
• Can detect and block DNS Tunneling — encoded data inside TXT or NULL records used by malware C2 (Cobalt Strike, dnscat2 family).
• Optionally blocks the use of DoH / DoT to unauthorized resolvers (so a browser cannot silently bypass your DNS policy).

DoH / DoT clarification: DNS Control inspects plaintext UDP/53 directly. For DoH (HTTPS / 443) and DoT (TLS / 853), it falls back to resolver-based blocking — it allows or denies based on the resolver hostname/IP, because it cannot read the encrypted query payload. DNS-tunnel detection heuristics (anomalous TXT/NULL volume, entropy spikes) only fire on plaintext DNS. That's why a DoH bypass needs Cloud Firewall + DNS Control together — DNS Control restricts which DoH resolvers can be used, Cloud Firewall blocks TCP/853 to unapproved hosts.

Rule recipe — block newly registered domains and known C2

This is the single rule that catches the most low-hanging-fruit malware. Newly Registered Domains (NRD) are domains less than 30 days old. Legitimate businesses rarely use them; phishing kits and malware C2 use them constantly.

Rule Name        : Block-NRD-and-C2
Order            : 1
Status           : Enabled
Locations        : All
Users / Groups   : Any
Application      : Any
Source IP        : Any
Protocols        : DNS over UDP, DNS over TCP, DoH (port 443), DoT (port 853)
URL Categories   : Newly Registered Domains, Command and Control,
                   Cryptomining, Malware Sites, Phishing
DNS Application  : Any
Action           : Block (Return NXDOMAIN)
Logging          : Full

DNS Gateway vs Trusted Resolver vs Custom Resolver

Section C — File Type Control

File Type Control runs after SSL inspection (because the file is inside the HTTP/S body) but before IPS scans the payload for known exploits. It is your blunt instrument: stop a category of files at the door no matter what is inside them.

Extension vs True File Type — the key distinction

An attacker renaming payload.exe to invoice.pdf is the oldest trick in the book. ZIA inspects two attributes:

• File extension — the literal characters after the last dot in the filename in the HTTP request.
• True file type — the actual format detected from the file's magic bytes (the first 4-16 bytes of the file body — 4D 5A = PE/EXE, 25 50 44 46 = PDF, 50 4B 03 04 = ZIP/Office, etc.).

Always block on True File Type, not extension. A rule that only blocks *.exe will let invoice.pdf through even when the bytes say it is a Windows PE.

Direction matters — Download vs Upload

Every File Type Control rule must specify direction:

• Download (Inbound) — files coming to the user. Block: executables (.exe, .dll, .scr, .msi), disk images (.iso, .img, .vhd — common phishing payload wrapper since CY22), scripts from the web (.ps1, .vbs, .js, .hta).
• Upload (Outbound) — files leaving the user to the internet. Block: source code, database exports (.bak, .sql), Office macros (.xlsm, .docm) being posted to consumer file-share, archive types you don't allow sharing externally.

Rule Name         : Block-Container-Downloads
Order             : 2
Status            : Enabled
Locations         : All
Users / Groups    : Any  (Exception group: IT-Engineering allowed)
URL Categories   : Any  (or restrict to "Web-based Email", "File Sharing" if narrower)
Cloud Applications: Any
File Types        : ISO, IMG, VHD, VHDX  (selected from Container category)
Detection         : True File Type (not extension)
Min File Size     : 0
Max File Size     : (unlimited)
Direction         : Download (Inbound)
Action            : Block User from Downloading
End User Notify   : Yes — show branded block page
Logging           : Full

Caveat — encrypted archives

If a user downloads a password-protected ZIP, ZIA cannot read the contents (it does not have the password). It will see the outer ZIP magic bytes and the entry filenames in the central directory but cannot inspect bytes inside the protected entries. The right defense: a File Type Control rule that blocks Password-Protected Archives (a specific selectable type) for general users, and only allows them for groups that have a business reason.

Section D — IPS Control

IPS Control is the deepest of the four — it inspects the bytes inside the decrypted HTTP/S payload looking for known exploit patterns. Think of it as the "match the attack to its CVE" layer.

How ZIA IPS differs from a perimeter IPS

An on-prem IPS appliance (Palo Alto Threat Prevention, Fortinet IPS, Suricata) lives on the wire and inspects whatever flows through. ZIA's IPS is built into the same proxy that already decrypted the SSL — so it sees clear-text payload for every TLS-encrypted site with no extra cost, no SSL appliance, no third-party broker.

The signature set is curated by Zscaler's ThreatLabz team and pushed to every Service Edge globally on a continuous push, typically hourly cadence via the Trust Pool config-push channel (the same plane that distributes URL category updates). You do not write your own Snort rules in the same way you would in Suricata — instead you choose which categories of ThreatLabz signatures to enforce, what action (Block / Allow / Reset), and whether to enable the IPS Control on a particular firewall rule.

IPS rule structure

An IPS Control rule lives under Policy → Advanced Threat Protection → IPS Control in the modern UI (older builds had it under Cloud Firewall Control → IPS Control Policy — both paths show the same engine) and looks like this:

Rule Name        : Block-High-Severity-Exploits
Order            : 1
Status           : Enabled
Locations        : All
Users / Groups   : Any
Source IP        : Any
Dest IP / FQDN   : Any
Network Service  : HTTP, HTTPS
Threat Category  : Web Exploits, Buffer Overflow, SQL Injection,
                   Cross-Site Scripting, Malware Callback
Severity         : Critical, High
Action           : Block
Log Capture      : Full PCAP (first 64 KB) — store for forensics
Logging          : Full

Severity, Threat Category and the trade-off

ZIA classifies every signature by severity (Critical / High / Medium / Low) and by threat category (Web Exploits, SQL Injection, XSS, Command and Control, Malware Callback, etc.).

The common pattern in production tenants:

• Critical + High — Action: Block. These are confirmed exploits with high precision. False positives are rare.
• Medium — Action: Block in normal mode, Allow in initial rollout for one week to gather false positives.
• Low — Action: Allow but Log. These are noisy and tend to fire on legitimate scanners and pen-test traffic.

# 1) Trigger a harmless test signature.
#    Visit the EICAR HTTP test file from a controlled lab host:
curl -v https://secure.eicar.org/download/eicar.com

#    Expected: connection drops, ZIA returns a branded block page,
#    Web Insights log shows Threat Name = "EICAR-Test-File", Action = Blocked.

# 2) For an IPS-specific signature, use a known harmless SQLi probe URL
#    against a Zscaler-provided test site (not a real production app):
curl "https://test-malware-categories.zscaler.com/sqli?id=1' OR '1'='1"

# 3) Confirm in Analytics → Insights → Web Insights
#    Filter: Threat Class = IPS Signature, Last 15 minutes
#    Must show your user, the signature ID, severity, and Action = Blocked.

ATP vs IPS — they are TWO separate policy families

This trips up new ZIA engineers and shows up in ZDTA exam questions. IPS Control and Advanced Threat Protection (ATP) live under the same menu in the modern UI (Policy → Advanced Threat Protection) but they are different engines configured per-rule:

• IPS Control = signature-based detection. CVE-mapped exploit attempts in the decrypted payload — buffer overflows, SQL injection signatures, known XSS payloads, web-exploit kits. Pattern matching.
• Advanced Threat Protection (ATP) = behavioral detection. Botnet C2 callbacks, cryptomining traffic, suspicious DNS patterns, fraud / scam indicators, anonymizer use, browser exploits. Heuristics and reputation, not just signatures.

Both write to Web Insights. Both can Block. But a ZDTA exam question that asks "which engine catches a Cobalt Strike beacon calling home over HTTPS" wants ATP, not IPS — the beacon doesn't carry a CVE exploit signature, it just behaves like a known C2 family. Conversely, a question about "a CVE-2024-XXXX Apache log4j payload in a POST body" wants IPS — that's a signature match on a known exploit string.

Risk Score — the cross-cutting condition

Risk Score is a 0–100 score ZIA computes for every connection, derived from the destination's category, ThreatLabz threat intel, the user's recent behavior, and device posture (from ZCC). It's been GA for 18+ months and shows up across rule families — you can use it as a condition in URL Filtering, Firewall, and DLP rules ("Block when Risk Score > 80", "Caution when Risk Score > 60"). Expect ZDTA exam questions on it. The whole point is one knob that combines multiple signals instead of you maintaining separate threshold rules per signal.

How the four controls actually interact — the order matters

The single most important takeaway: a Block in any family terminates the flow. But an Allow in one family does not promote the flow past the others. Here is the worked example that catches new ZIA engineers:

1. User clicks a link to cdn.fake-update.tld/installer.exe.
2. DNS Control — domain is 4 days old → matches "Newly Registered Domains" → action: Block → NXDOMAIN returned, user sees "site cannot be reached", connection never happens.
3. Steps 3-7 (Firewall, URL, SSL, File Type, IPS) never execute. Logging is in DNS Insights only.

Compare to a second flow where DNS is allowed:

1. User downloads invoice.pdf from a freshly compromised but reputation-clean site.
2. DNS Control → Allow (no category match).
3. Cloud Firewall → Allow (port 443 to public IP).
4. URL Filter → Allow (category = Business).
5. SSL Inspection → decrypts the response.
6. File Type Control — extension says .pdf but magic bytes say 4D 5A (PE/Windows EXE). True-Type detection fires → action: Block.
7. IPS / Sandbox / DLP never run.

This is what "defense in depth" actually looks like in ZIA — each family covers blind spots of the others.

Configuration order — what to enable first

If you are bringing up a new ZIA tenant or hardening an existing one, this is the order that gives the highest security per hour of work:

1. SSL Inspection policy — without it, three of the four controls are blind. Decrypt everything except a small allowlist (banking, healthcare, employee personal mail).
2. DNS Control rule — block Newly Registered Domains, C2, Phishing, Malware, Cryptomining. Highest signal-to-effort ratio.
3. Cloud Firewall default-allow with explicit deny for risky protocols — block SMB, RDP, Telnet, LDAP-cleartext outbound to internet.
4. File Type Control — block container types (ISO, IMG, VHD), HTA, password-protected archives on inbound.
5. IPS Control — enable Critical + High severity in Block mode, Medium in Allow+Log for one week, then promote to Block.
6. Sandbox for unknown PE files — handed off automatically by File Type Control / URL Filter.
7. DLP for outbound — separate lesson.

Real-world scenario — "Microsoft Teams stopped working at one branch"

A common Day-2 ticket: only one branch is complaining that Teams audio crackles and screen-share drops, but the same Teams client works fine at HQ and over home VPN. Walk it through the four families:

1. DNS Insights for that user — confirm *.teams.microsoft.com and *.skype.com resolve cleanly, no Block hits, latency <30ms. ✓ Rule out DNS.
2. Firewall Insights — filter on Network App = "Microsoft Teams". Look for any Block hits. None? Now look at Allow hits and check the matched rule. Aha — a forgotten "Block UDP 3478-3481 outbound" rule from an old XBox-Live cleanup hit the Teams audio media stream.
3. Fix: add an Allow rule above the Block, scoped to Network App = Microsoft Teams.
4. Verification: have the user rejoin, watch Firewall Insights in real time, confirm the new Allow rule matches.

The diagnostic discipline — start at the front of the pipeline and walk forward — works for almost every ZIA complaint.

Logging and where each family writes

Quick reference cheat-sheet