TTechclick ⚡ XP 0% All lessons
Sophos · Next-Gen Firewall · WAFInteractive · L1 / L2 / L3

Sophos Firewall WAF — Reverse-Proxy Web Server Protection

The Sophos Firewall WAF protects the web servers you host — Exchange/OWA, intranet portals, line-of-business apps — by acting as a reverse proxy: external clients hit the firewall, which inspects every request and forwards only clean traffic to a back-end that is never exposed directly. This lesson shows how to publish a server with a Business Application Rule, what the Protection Policy actually blocks, and how to tune auth offload, path routing and TLS without breaking the app.

📅 2026-06-19 · ⏱ 16 min · 5 infographics · live request demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to the Sophos Firewall Web Application Firewall (WAF) in 2026: how it protects the web servers you host as a reverse proxy, how to publish a server with a Business Application Rule, the Web Server and Protection Policy objects, OWASP signature filtering (SQLi/XSS), URL/form/cookie hardening, antivirus and slow-HTTP protection, authentication offloading, path-based routing and TLS termination.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

What the WAF is

Reverse proxy for the servers you host, not outbound filtering.

 2

Publish a server

Business Application Rule + Web Server & Protection Policy.

 3

The protections

OWASP signatures, URL/form/cookie hardening, AV, slow-HTTP.

 4

Auth, routing & tuning

Auth offload, path routing, TLS, and the classic breaks.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Does the Sophos Firewall WAF protect your users browsing the internet?

Answered in What the WAF is.

2. Which object actually publishes a server to the outside?

Answered in Publish a server.

3. What catches a SQL-injection attempt before it reaches the server?

Answered in The protections.

Most engineers think…

Most people lump 'Sophos web protection' into one bucket and assume the WAF is just the web filtering that stops users reaching bad sites. That mix-up costs you marks in an interview and gets the wrong server exposed in production.

The WAF is the opposite direction. Web filtering protects your users browsing out; the Web Application Firewall protects the web servers you host from traffic coming in. It works as a reverse proxy: external clients connect to the firewall, which terminates the connection, inspects the request and forwards only clean traffic to a back-end server that is never exposed directly. Once you hold that distinction, the three building blocks — Web Server, Protection Policy and Business Application Rule — fall into place.

① What the Sophos Firewall WAF actually is — a reverse proxy for your servers

The single most important idea: the Sophos Firewall Web Application Firewall (WAF) protects the web servers you host — not your users browsing the internet. It works as a reverse proxy: an external client connects to a hostname published on the firewall, the firewall terminates and inspects the request, then forwards only clean traffic to the internal back-end. The real server is never exposed directly to the internet.

This is the mirror image of the outbound web filtering from lesson 7. Web filtering controls users going out to websites. The WAF protects your own public-facing or internal web servers from attacks coming in — Exchange/OWA, SharePoint and intranet portals, line-of-business web apps. Same vendor, opposite direction, completely different feature.

Figure 1 — The reverse-proxy path — client to clean back-end
An external request is terminated and inspected at the firewall WAF, then only clean traffic is forwarded to the hidden internal server.The reverse-proxy path — client to clean back-endClienthits published hostWAFterminate + inspectFilterOWASP + hardeningForwardclean to back-endResponsereturned via WAF
An external request is terminated and inspected at the firewall WAF, then only clean traffic is forwarded to the hidden internal server.
Figure 2 — WAF vs outbound web filtering
Two different features in opposite directions: the WAF protects servers you host, web filtering controls users browsing out.WAF vs outbound web filteringWAF (server protection)Protects servers you hostInbound traffic from clientsReverse proxy hides back-endOWASP / SQLi / XSS / hardeningWeb filtering (lesson 7)Protects users browsingOutbound traffic to internetCategory / URL policyStops risky sites and content
Two different features in opposite directions: the WAF protects servers you host, web filtering controls users browsing out.
Name the direction in an interview

Say it cleanly: the WAF protects the servers you host (inbound, reverse proxy); web filtering protects your users browsing out (outbound, category policy). Two features, opposite directions. Stating that distinction first is what tells the interviewer you actually understand Web Server Protection.

Quick check · Q1 of 10 · Understand

The Sophos Firewall WAF is best described as…

Correct: a. The WAF is reverse-proxy server protection: clients hit the firewall, which inspects and forwards clean traffic to a hidden back-end. Outbound web filtering (lesson 7) is the opposite direction — it controls users browsing out.
👉 So far: The Sophos Firewall WAF is reverse-proxy protection for the web servers you host — inbound traffic, with the back-end hidden. It is the opposite of outbound web filtering, which controls users browsing out.

② Publishing a server — the Business Application Rule and its objects

Everything lives under Web Server Protection, built from three objects. A Web Server defines the back-end — its host or IP, port, whether traffic to it is plaintext or encrypted, keep-alive and timeouts. A Protection Policy is a reusable security template that says which checks to run and how strict. A Business Application Rule is the publishing wizard that ties them together.

The wizard you must name

You create a Business Application Rule of type web server protection (‘Protect with web application firewall’), give it the public hostname or IP clients will reach, attach the certificate for the published service, point it at one or more Web Server objects, and apply a Protection Policy. That single rule is what exposes an internal app safely to the outside.

Figure 3 — Three objects under Web Server Protection
You build a published service from a Web Server (back-end), a Protection Policy (the checks) and a Business Application Rule (the publisher).Three objects under Web Server ProtectionBusiness Application RuleThe wizard: hostname, cert, ties it all togetherProtection PolicyReusable template of WAF checks and hardeningWeb Server objectThe back-end: host, port, plaintext or encrypted
You build a published service from a Web Server (back-end), a Protection Policy (the checks) and a Business Application Rule (the publisher).
🔁
Reverse proxy
tap to flip

The WAF sits in front of your server. Clients connect to it, it inspects the request and forwards only clean traffic to the hidden back-end.

🧩
Business Application Rule
tap to flip

The publishing wizard (‘Protect with web application firewall’) that exposes a server with a hostname, certificate, Web Server objects and a Protection Policy.

🛡️
Protection Policy
tap to flip

The reusable security template: OWASP signatures, URL/form/cookie hardening, antivirus scanning and slow-HTTP protection.

🔑
Authentication offload
tap to flip

Front-door login (e.g. against AD) and SSO done by the WAF before any request reaches the back-end. Exclude API paths that can't log in interactively.

Quick check · Q2 of 10 · Remember

Which object actually publishes an internal server to the outside?

Correct: b. The Business Application Rule is the publishing wizard. It sets the public hostname and certificate and ties together the Web Server object(s) and a Protection Policy. The Web Server object alone just defines the back-end.
👉 So far: Three objects under Web Server Protection: a Web Server (the back-end), a Protection Policy (the checks), and a Business Application Rule (the wizard that publishes it with a hostname and certificate).

③ The protections — what a Protection Policy actually blocks

The Protection Policy is where the security happens. At its core is OWASP Top-10 / signature-based common-threat filtering — it inspects requests for SQL injection (SQLi), cross-site scripting (XSS) and other common web attacks and blocks them before they reach the server.

Hardening and content checks

On top of signatures sit several hardening controls. URL hardening only allows known entry-point or signed URLs, so an attacker cannot jump to a deep URL or tamper with links. Form hardening protects web forms from manipulation of hidden fields. Cookie signing signs cookies so tampered or forged cookies are rejected. The policy can also run antivirus scanning on uploads and downloads, and slow-HTTP protection defends against slow-request (Slowloris-style) attacks that tie up server connections.

Figure 4 — Inside a Protection Policy
One policy bundles signature filtering with hardening, content scanning and slow-HTTP defence, then is reused across published apps.Inside a Protection PolicyProtection Policyapplied to a ruleOWASP / SQLi / XSSURL hardeningForm hardeningCookie signingAntivirus scanSlow-HTTP protection
One policy bundles signature filtering with hardening, content scanning and slow-HTTP defence, then is reused across published apps.
‘Just turn everything to strict’

Cranking URL hardening, form hardening and cookie signing to maximum on a real app like OWA or an LOB portal breaks legitimate behaviour and APIs. Start with OWASP signatures on, add hardening deliberately, and use exceptions for paths that genuinely need them. Over-strict hardening is the number-one false-block cause.

▶ Watch a request to /owa get inspected and forwarded

How one external request is handled end-to-end by the WAF. Press Play for the healthy path, then Break it to see the classic failure.

① RequestAn external user opens https://mail.meridian.example/owa; the request hits the hostname published on the firewall, not the Exchange server.
▼
② Terminate + inspectThe WAF terminates TLS with the published certificate and runs OWASP signatures plus cookie and URL hardening on the request.
▼
③ Auth offloadAuthentication offload prompts for the AD login; once the user authenticates, the request is allowed to continue.
▼
④ ForwardThe clean, authenticated request is re-encrypted and forwarded to the internal Exchange server, which returns the mailbox via the WAF.
Press Play to step through the healthy request path. Then press Break it.
Quick check · Q3 of 10 · Apply

An attacker sends a SQL-injection string in a login form. Which protection-policy feature stops it first?

Correct: c. SQLi and XSS are caught by the OWASP / signature-based filtering in the Protection Policy, which inspects request content before it reaches the server. Cookie signing, slow-HTTP and path routing solve different problems.
👉 So far: A Protection Policy bundles OWASP signature filtering (SQLi/XSS) with URL, form and cookie hardening, antivirus scanning of uploads/downloads, and slow-HTTP protection.

④ Authentication offload, path routing, TLS — and how to tune without breaking the app

Beyond inspection, the WAF can act as a front door. With authentication offloading (reverse-proxy authentication) it requires login — for example against Active Directory — and can do SSO before any request reaches the back-end, so the server never sees unauthenticated traffic. Path-based routing sends different URL paths on one hostname to different back-end servers, and distributes load across multiple back-ends.

TLS and the classic breaks

For HTTPS, the WAF terminates TLS using the published service's certificate, inspects in clear text, and can re-encrypt to the back-end. The failure modes everyone hits: over-aggressive hardening blocking legitimate app behaviour (tune exceptions), a certificate mismatch on the published service, and forgetting to exclude API/autodiscover paths from auth offload and URL hardening — the paths that can't do an interactive login.

Figure 5 — Auth offload to clean forward
The WAF can authenticate the user and terminate TLS before inspecting, then forward only an authenticated, clean request to the back-end.Auth offload to clean forwardTLS termdecrypt with certAuth offloadlogin vs AD / SSOInspectOWASP + hardeningPath routeto right back-endRe-encryptforward to server
The WAF can authenticate the user and terminate TLS before inspecting, then forward only an authenticated, clean request to the back-end.

Priya at Meridian Logistics in Kochi faces this

After publishing Exchange OWA through the Sophos Firewall WAF, staff can read mail in the browser but mobile/EWS clients fail to sync and large attachment uploads get blocked.

Likely cause

The Protection Policy has URL hardening and form hardening switched on aggressively, and authentication offload is applied to the whole site — including the API and autodiscover paths that mobile clients use but cannot complete an interactive AD login on.

Diagnosis

The WAF event log shows requests to /EWS/ and /Microsoft-Server-ActiveSync being dropped by URL hardening and rejected at auth offload, while the interactive /owa path works.

Web Server Protection ▸ Business Application Rule ▸ Protection Policy + Exceptions
Fix

Add the API/autodiscover paths to the exceptions list (skip URL hardening, form hardening and auth offload for them), confirm the published certificate matches the OWA hostname, and keep the strict checks only on the interactive /owa path.

Verify

Re-test: browser OWA is still inspected and protected, mobile/EWS clients sync again, and the WAF log shows the API paths passing while a test SQLi string on /owa is still blocked.

Prove it from the WAF log, not a hunch

Never close a ‘the app is broken’ ticket on a guess. The WAF event log shows the exact path, which check dropped the request, and whether auth offload rejected it. One read tells you whether to add an exception, fix the certificate, or leave the block in place because it was a real attack.

Quick check · Q4 of 10 · Analyze

After publishing OWA through the WAF, mobile/EWS clients can't sync. What is the most likely fix?

Correct: d. API paths can't complete an interactive login, so strict auth offload and URL hardening block them. Add those paths to the exceptions/skip list while keeping strict checks on the interactive path — don't disable protection or TLS.
👉 So far: The WAF can authenticate users (auth offload/SSO) and route by path before forwarding; it terminates and can re-encrypt TLS. The classic breaks are over-strict hardening, a cert mismatch, and missing API exclusions — tune exceptions.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Where in the Sophos Firewall is the WAF configured?

Correct: b. Web Server Protection is the area that holds Web Servers, Protection Policies and Business Application Rules — the building blocks of the WAF. Web Filtering is the outbound-browsing feature.
Q6 · Understand

Which protection-policy feature stops cross-site scripting (XSS) and SQL injection?

Correct: c. SQLi and XSS are common web attacks caught by the OWASP / signature filtering engine. Cookie signing stops tampering, slow-HTTP stops connection exhaustion, and path routing directs traffic — none of those is the SQLi/XSS control.
Q7 · Apply

You want users to log in against Active Directory before any request reaches the server. Which feature?

Correct: a. Authentication offloading (reverse-proxy authentication) has the WAF authenticate the user — e.g. against AD, with SSO — before traffic ever reaches the back-end. The others inspect or transform requests but don't perform the login.
Q8 · Analyze

Why can the WAF inspect an HTTPS request for SQL injection at all?

Correct: b. Because the WAF terminates TLS using the published service's certificate, it sees the request in clear text and can run signatures and hardening, then optionally re-encrypt to the back-end. Without termination it would only see encrypted bytes.
Q9 · Evaluate

An interviewer asks the difference between the WAF and web filtering. Best answer?

Correct: c. They run in opposite directions. Web filtering controls outbound user browsing; the WAF is reverse-proxy protection for the servers you host against inbound attacks. Stating the direction is the key.
Q10 · Evaluate

A valid app breaks right after you publish it with a strict policy. Strongest first move?

Correct: d. The WAF event log names the exact path and check that dropped the request. Add a scoped exception for legitimate paths (e.g. APIs) or fix a certificate mismatch — never disable protection wholesale just to make the symptom go away.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is the Sophos Firewall WAF called ‘server protection’ and how is it different from web filtering? Then compare with the expert version.

Expert version: Because the WAF protects the web servers you host, not your users. It works as a reverse proxy: external clients connect to a hostname published on the firewall, which terminates TLS, inspects every request against OWASP signatures and URL/form/cookie hardening, can authenticate the user first, and forwards only clean traffic to a back-end that stays hidden. Outbound web filtering is the opposite direction — it controls users browsing out to websites. You publish a server with a Business Application Rule that ties a Web Server object to a Protection Policy, and you tune exceptions when strict hardening or auth offload blocks a legitimate path.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Web Application Firewall (WAF)
A reverse proxy on the Sophos Firewall that inspects inbound HTTP(S) and protects the web servers you host from attacks like SQLi and XSS.
Reverse proxy
A server that fronts your back-end servers: clients connect to it, it inspects the request and forwards only clean traffic, keeping the real server hidden.
Web Server Protection
The Sophos Firewall area where Web Servers, Protection Policies and Business Application Rules are configured.
Web Server object
The definition of a back-end server (host/IP, port, plaintext or encrypted, timeouts) that the WAF forwards clean traffic to.
Protection Policy
A reusable template of WAF checks — OWASP signatures, URL/form/cookie hardening, antivirus scanning and slow-HTTP protection.
Business Application Rule
The wizard that publishes an internal app to the outside with a hostname, certificate and WAF protection.
OWASP Top-10
The standard list of the most common web-app risks (SQLi, XSS and more) that the signature engine guards against.
URL hardening
Restricting access to known or signed entry-point URLs so attackers can't jump to deep URLs or tamper with links.
Cookie signing
Signing cookies so the WAF rejects any tampered or forged cookie.
Authentication offloading
WAF-enforced login (e.g. against AD) and SSO done before any request reaches the back-end server.

📚 Sources

  1. Sophos — Sophos Firewall: Web Server Protection (WAF) overview. docs.sophos.com
  2. Sophos — Add a Business Application Rule (web server protection) & Web Server objects. docs.sophos.com
  3. Sophos — Protection policies: URL hardening, form hardening, cookie signing, slow-HTTP. docs.sophos.com
  4. Sophos — Authentication offloading / reverse-proxy authentication. docs.sophos.com
  5. Sophos Community — Publishing Exchange / OWA with the Sophos Firewall WAF (path exclusions). community.sophos.com
  6. Sophos — Sophos Firewall (XGS) datasheet — Web Server Protection module. sophos.com

What's next?

Got the WAF? Next, go the other direction with remote access and site links: site-to-site IPsec, SSL VPN, Sophos Connect and SD-RED — how Sophos Firewall stitches branches, partners and remote users together securely.

Next · All interview lessons → Practice on exam.techclick.in →