Sophos Firewall WAF: Securely Publish Web Servers

With Web Server Protection or Web Application Firewall (WAF), you can publish internal or cloud-based web applications via the Sophos Firewall. The firewall acts as a reverse proxy: clients connect to the public address of the firewall, which checks HTTP or HTTPS traffic and forwards the request to the protected web server.

For the broader hardening context, use the hub Sophos Firewall Hardening: best practices for secure configuration.

A WAF rule does not automatically replace secure application development, patching, strong authentication, or server hardening. However, compared to simple port forwarding, it significantly reduces the attack surface because HTTP(S) traffic can be more precisely inspected, restricted, and logged.

WAF is still not automatically the right answer for every publication. The key is whether the application actually works cleanly over HTTP or HTTPS, whether the firewall should evaluate hostnames and paths, and whether the additional reverse proxy layer fits the application.

PHP2Shell — as of 24 October 2026: For CVE-2026-109618 and CVE-2026-109619, Sophos states in its advisory dated 22 October, version 4 that Sophos Firewall WAF provides no specific protection. Affected PHP runtimes on the backend must be updated; publishing through WAF does not replace that update. The IPS signatures available since 22 October detect exploitation attempts. Check separately whether a suitable IPS policy inspects the actual data path and which action it applies; the IPS guide explains these checks. An absence of alerts does not establish a secure patch level.

Decision Before Publishing

Before creating a WAF rule, establish whether WAF, DNAT, VPN, or ZTNA is suitable for the application. This decision is more important than the configuration screen itself, because it determines the attack surface, operation, and troubleshooting.

When WAF is More Suitable than DNAT

For simple TCP or UDP services, NAT and firewall rules are still used. For web applications, WAF is often the better choice.

• DNAT fits non-HTTP services, simple port forwarding, and special protocols. The firewall then primarily translates and allows the traffic.
• WAF / Web Server Protection fits HTTP and HTTPS applications when hostname, certificate, paths, protection profiles, authentication, or country rules are relevant.
• Reverse Proxy or ZTNA fits complex web platforms, identity integration, and private applications when access should be tightly controlled or not public at all.

If you just want to quickly make an internal web server accessible via port forwarding, the guide Publish Server via DNAT on Sophos Firewall can help. For public web applications, WAF should be considered first.

⚠️ WebDAV is not supported by Sophos WAF. Therefore, applications like Nextcloud should not be blindly published via WAF but planned with appropriate firewall and NAT rules or another publication architecture.

Decision: WAF, DNAT, or Private Access

The most important question is not how quickly a publication is set up, but whether it can later be operated securely, tested, and rolled back. This classification helps before technical implementation:

• Public website or simple HTTPS application: WAF is usually the suitable starting point. DNS, certificate, hostname, protection profile, logging, and backend reachability must be tested.
• Customer portal, partner portal, or admin interface: WAF with source restrictions and optional MFA can make sense. First clarify whether WAF-MFA, country rules, or fixed source networks are possible.
• Pure TCP or UDP service: DNAT is usually more suitable. Firewall rule, NAT rule, target server, return route, and logging must be checked together.
• Web application with WebDAV or special protocol: Do not automatically use WAF. Test supported functions, client behaviour, and alternative publication methods.
• Application only for internal users: Consider VPN, ZTNA, or heavily restricted WAF. Question whether public accessibility is necessary.

For private applications, a globally accessible WAF rule often presents too much of an attack surface. If only a few people need access, fixed source networks, VPN, ZTNA, or another private access architecture are often cleaner than a public web publication.

Planning and Prerequisites

A reliable WAF publication needs DNS, a certificate, backend reachability, logging, and a rollback plan. These points should be settled before configuration.

Prerequisites

Before the first WAF rule, clarify these points:

• Public DNS name, for example, portal.example.com
• Public IP address or alias on the WAN interface
• Certificate for the published hostname
• Internal IP address or FQDN of the web server
• Internal target port of the web server
• Decision whether HTTP is redirected to HTTPS
• Allowed source networks, countries, or user groups
• Suitable protection profile and optional IPS policy
• Enabled logging for later analysis
• External test access outside your own LAN

The public DNS name must point to the address used as the Hosted address in the WAF rule. For HTTPS, the certificate must match the published hostname.

The firewall also needs a web server object under Web server > Web servers. This defines the internal or external target server with host, protocol, and port. The host is an IP or FQDN host object. HTTP or HTTPS can be used for backends; standard ports are 80 and 443. If the backend web server delivers long responses or needs keep-alive, Keep alive and Timeout should be checked deliberately rather than inherited by chance.

The backend Timeout can range from 1 to 65,535 seconds; the default is 300 seconds. When it expires, WAF sends 502 to the client. Disable backend connection pooling forces a new backend connection for every request and can reduce performance. Use this option only for targeted troubleshooting and then restore the documented previous state.

In addition, consider the limits of Web Server Protection early. Sophos states, among other things, a limit of 60 WAF rules per firewall. That is enough for many environments, but can become relevant faster than expected with many customer portals, tenants, test systems, or separate hostnames. In that case, do not blindly build more individual rules; review the naming scheme, paths, virtual web servers, and alternative publication methods.

SFOS 22 does not support WAF rules over IPv6. An application must therefore not be planned as an IPv6 publication with this feature; the overview Sophos Firewall IPv6 support and limitations in SFOS 22 distinguishes WAF from the supported IPv6 rule and protection features. The Exchange templates are also not a blank cheque for modern Exchange environments: Sophos documents that WAF rules currently do not support Exchange versions after 2013.

The preconfigured templates come from an older Microsoft application landscape: Exchange Autodiscover, Outlook Anywhere, and Exchange General stop at this Exchange 2013 boundary; the other Sophos guides name Microsoft Lync, Remote Desktop Gateway or RD Web 2008/R2, and SharePoint 2010/2013. They are therefore not a current baseline for Microsoft 365, modern Exchange versions, Teams, or today’s RDS deployments. Before using one, compare the required paths, authentication methods, and protection profiles with the current Microsoft architecture; for a modern application, leave Preconfigured template at None when in doubt.

Create a Backend Object with a Clear Example

The public name and backend name serve different purposes. In the following example, users open portal.example.com; the firewall reaches the server via backend.example.com. Both names are placeholders and must be replaced with your own DNS names. From the firewall’s perspective, the backend name must resolve to the actual server, not back to its own public WAF address: otherwise, there is no meaningful path to the backend.

1. Under Hosts and services > FQDN host > Add, create an object named WAF_Backend_Portal with FQDN set to backend.example.com and save it. Alternatively, use an IP host object for a backend server with a fixed address. According to the product documentation, FQDN hosts offer broader server compatibility; DNS resolution and the target server must still be checked.
2. Under Web server > Web servers > Add, create a web server object named WAF_Portal_Server and select the backend object under Host.
3. Set Type and Port according to the actual backend listener: in the HTTPS example, HTTPS and 443; for an HTTP backend, HTTP and, for example, 80. The external listening port is only defined in the WAF rule and does not have to be identical to the backend port. For an HTTP backend, deliberately secure the unencrypted segment; an HTTPS frontend alone does not encrypt this segment.
4. Enable Keep alive only if the web server supports reused connections. Initially assess Timeout using the default of 300 seconds. This means the time spent waiting for data to or from the backend, not a blanket maximum total duration for every request: a response can take longer as long as data arrives in time. For 502 errors, therefore check backend logs and gaps in data transfer rather than immediately increasing the value.
5. In normal operation, do not enable Disable backend connection pooling as a performance optimisation. Save the object, check its assignment to the WAF rule or the SFOS 23 Protect path, and test a representative request to the backend.

Plan WAF Publication Before Configuration

A WAF rule should not be planned only in the interface. It must be clear beforehand whether the Sophos Firewall should only publish or also handle authentication, protection profiles, country rules, and logging.

These questions are important before publishing to production:

• Is it really an HTTP or HTTPS application? For other protocols, DNAT is usually more suitable.
• Does the application need to be publicly accessible? Private admin portals often fit better with VPN, ZTNA, or restricted source networks.
• Which hostname and certificate are used? DNS, SNI, certificate, and WAF domains must match.
• How many publications are planned? The WAF rule limit and ease of subsequent operation influence the design.
• Should the firewall authenticate users? For portals, WAF-MFA can be useful.
• Which protection profiles are active? Overly broad exceptions weaken the WAF; overly strict profiles can break applications.
• How is logging and testing done? Log Viewer, reverseproxy.log, and backend logs must be known before go-live.

For certificates, clarify early whether an existing certificate will be imported with its private key and CA chain, whether the firewall itself should create and renew a Let’s Encrypt certificate, or whether an externally generated certificate is needed. There is a separate guide for wildcard certificates: Create Let’s Encrypt Wildcard Certificate.

Configure WAF Rule

The WAF rule itself consists of the public address, hostnames, certificate, target server, allowed sources, and protection profile. These fields should be considered together, not as isolated options.

Basic Structure of a WAF Rule

A WAF publication consists of several components:

• Hosted address: Public IP address or alias where clients reach the application.
• Listening port: Public port, usually 80 or 443.
• Domains: Hostnames that should match the WAF rule.
• HTTPS certificate: Certificate for the published hostname.
• Web server: Previously created web server object with host, protocol, port, and connection settings.
• Allowed client networks: Source networks allowed to access.
• Blocked client networks / countries: Sources or countries to be blocked.
• Protection policy: WAF protection against typical web attacks.
• Authentication: Optional pre-authentication via the firewall.

Sophos creates WAF rules in the firewall rules section. The action is called Protect with web server protection.

Important: a WAF rule is not a normal firewall rule with NAT behind it. It creates a reverse proxy publication. Therefore, Hosted address, Listening port, Domains, certificate, Protected server, and Allowed client networks must fit together. If one of these fields does not fit, the error often looks like a certificate, DNS, or backend problem.

Create a WAF Rule

The menu path is:

Rules and policies > Firewall

Procedure:

New rules are enabled by default. For a publication that has been prepared but not yet cleared for go-live, explicitly check the rule status and leave the rule disabled until the planned go-live. Rule position offers Top or Bottom; Rule group assigns the rule to an existing group or one created using Create new. Automatic uses the first matching group based on the rule type and source/destination zones. Grouping is an administrative aid, not a substitute for checking access.

The following numbered procedure using Protected servers applies only to SFOS 22 and remains unchanged for that version. WAF rules support only IPv4. The outer rule action Protect with web server protection is not equivalent to the path-specific Action > Protect under Traffic routing in SFOS 23; for SFOS 23, use the separate instructions immediately after this procedure.

1. Select IPv4.
2. Open Add firewall rule.
3. Select New firewall rule.
4. Assign a descriptive rule name.
5. Set Rule position deliberately, especially if more general WAF rules or old publications already exist.
6. Choose Protect with web server protection for Action.
7. If no special template is needed, leave Preconfigured template at None.
8. Under Hosted server details, define the public address, listening port, HTTPS, certificate, and domains.
9. Under Protected servers, select the matching web server object or create it first under Web server > Web servers.
10. Set Allowed client networks deliberately. For public websites, Any IPv4 may be necessary; for portals, a restriction is usually better.
11. Set Blocked client networks or Blocked countries if needed.
12. Deliberately review Protection, Intrusion prevention, and Traffic shaping under the advanced policies.
13. Save the rule and test externally.

SFOS 23: Publish Paths Under Traffic routing

1. Under Rules and policies > Firewall, create or edit an IPv4 rule. Continue to select Protect with web server protection as the outer Action, and configure the public address, port, HTTPS certificate, and domains as appropriate. A new rule contains / with Block by default: without further routing configuration, requests are rejected, not published.
2. Under Traffic routing, use Edit or Add new path to edit or add the specific intended path. Explicitly select Protect for Action and assign the required backend objects from Web server > Web servers. Although a template creates paths with Protect, backend assignment is still required.
3. For each protected path, assign the intended Authentication Policy in the Authentication field and deliberately set Allowed client networks; do not leave it empty. Specifically review Blocked client networks, Blocked countries, and Block IP addresses of unknown country-origin; for unknown country origin, also consider the risk of locking yourself out.
4. If only specific paths should be published, deliberately retain / with Block as the fallback route. Set / to Protect only if the entire application should be published; explicitly check the backend, authentication, access restrictions, and the application parts made accessible as a result. Longer, more specific paths are evaluated first, not in table order.
5. Distinguish between the actions: Block rejects requests for the selected path and does not forward them to the backend. Protect applies the rule’s protection policy along with the configured authentication and access settings. Redirect sends the client a redirect to the configured destination instead of publishing a backend. Passthrough creates a tunnel to the backend without WAF inspection and without applying the protection policy. Protection applies only to paths with Protect.
6. After saving, externally test an intended allowed path, a deliberately blocked path, and a path without a specific match. If used, also test Redirect and Passthrough separately. Correlate the client result, Log Viewer, reverseproxy.log, and backend logs using the same request and timestamp.

The default path can be edited, cloned, or deleted. A clone does not inherit approval for its intended use: check the action, backend, authentication, and sources again for the new mapping. Do not accidentally remove / if it serves as the deliberately blocking fallback route.

Existing rules after the upgrade: According to Sophos documentation, existing WAF rules are automatically switched to Protect when upgrading to SFOS 23; existing path-specific routes are retained. This differs from the default /-Block setting for new rules and from the older SFOS 18 migration of ModSecurity Protection Policies. Nevertheless, after the upgrade, check the action, backend, authentication, access restrictions, and actual route for every path, and perform external acceptance testing; automatic migration does not replace acceptance testing.

Tutorial context: The Sophos tutorial on protecting a web server against attacks still uses the procedure with Protected servers and states IPv4 or IPv6, although the WAF rule reference limits WAF to IPv4. The tutorial is therefore not a complete SFOS 23 routing guide. For the current configuration, use IPv4 and the explicit path actions described above.

When the rule is saved, Sophos restarts the Web Server Protection rules. Existing live connections through these rules may be interrupted. Changes to production WAF rules should therefore be made during a maintenance window or at least with this impact in mind.

If Allowed client networks remains empty, the WAF rule does not work correctly; the browser can then receive a 400 Bad Request. For a public application, Any IPv4 is possible, but not automatically right. For admin portals, partner portals, or internal tools, first check fixed source networks, country restrictions, WAF-MFA, VPN, or ZTNA.

Port conflicts should be resolved before saving. WebAdmin and User Portal each require a unique port. WAF and VPN Portal both use TCP, so their Hosted address or WAN IP addresses must differ when they use the same port. WAF can differ from SSL VPN by WAN IP address, port, or protocol because SSL VPN supports TCP or UDP. A different FQDN or SNI name alone is not sufficient to separate these listeners. If another service or an old DNAT publication already listens on a public IP, the mapping must be tested per IP address, port, and protocol before go-live.

The default port for the User Portal is 4443; portal listeners and their limits are covered in the portal overview.

SFOS 23: Explicitly Configure Block and Redirect Responses

A routing action can group several entries under Paths if they all require the same handling. Under Traffic routing > Add new path, select the paths and action, complete the action-specific fields, and save the path entry. Use separate entries for different backends, access rules, or redirect destinations.

For Block, Response code determines the response. One example is /admin/ with Forbidden (403), while / remains set to Block as the fallback route. The documented selection includes 400 to 417 as well as 422, 423, 424, and 426. Choose the code according to the intended meaning: 403 indicates denied access, while 404 indicates content not found. Selecting a 401 code does not configure an Authentication Policy; the status code alone does not provide login protection. During acceptance testing, check the configured status and verify that no corresponding request reaches the backend.

For Redirect, the configuration includes Response code, Protocol, Host, Path, and Port, in addition to Paths and Action. Example: /old-portal/ with Temporary Redirection (307), Protocol HTTPS, an FQDN host for portal.example.com, Path /portal/, and Port 443. Replace the names and paths with those of your own target application. 307 denotes a temporary redirect that preserves the request method; this is suitable for a controlled pilot if the destination handles the same method. Still test browsers and API clients separately, particularly POST requests. The destination /portal/ must itself be reachable and protected, for example through a matching Protect path; a redirect alone does not create backend or access configuration there.

The available codes are 300, 301, 302, 303, 304, 305, 307, and 308. Not every code offered is an ordinary redirect to a new page: 304 describes cache validation. 305 is deprecated due to security concerns and is not recommended for public applications. Use 301 or 308 only when a permanent switch is intended, and account for client/cache behaviour when rolling back. The destination’s default ports are 80 for HTTP and 443 for HTTPS. Redirect performs no WAF inspection and does not send the request to a backend for this route; therefore, check the status and redirect destination on the client, then check the protection of the target application.

Adjust Host Headers, HTML, and Compression Selectively

The Advanced settings of a WAF rule help with specific reverse proxy problems. They are not options that should all be enabled indiscriminately:

• Pass host header forwards the host header requested by the client to the backend. Where several websites run on one server, this can select the correct virtual host. Configure the backend vHost to match the published name and check the access log to ensure that no other website responds.
• Rewrite HTML adjusts links in returned pages. For example, if an absolute link points to http://backend.example.com/ while the application is published under the public name, rewriting may be necessary. It is normally unnecessary if public hostnames already match or links are relative throughout. Processing applies to Content-Types text/* and *xml*; binary downloads must be served with the correct Content-Type, otherwise they risk being corrupted. Afterwards, test public links, downloads, and application functions separately.
• Rewrite cookies rewrites cookies in returned pages. If session problems occur, examine the cookies actually set, along with login and logout, rather than confusing cookie rewriting with Cookie signing: rewriting and tamper protection serve different purposes.
• Disable compression support is a targeted troubleshooting aid for incorrectly displayed pages or Content-Encoding errors. The firewall then requests uncompressed data from the backend and delivers it uncompressed regardless of the requested encoding. Document the previous state, repeat the same page request, and revert the option if it does not resolve the error.

Some ports are reserved for system services even when the respective service is not in use. The absence of an active listener alone does not make such a port available for WAF; the overview Reserved Ports on Sophos Firewall helps with planning. Traffic shaping assigns bandwidth and time-dependent prioritisation to the publication. This is an operational decision, not additional application protection; with the policy enabled, also test uploads and downloads under representative load.

Go-live and Acceptance

Saving the rule does not complete the publication. External tests, matching logs, and a clear rollback plan are needed to make the change ready for production.

Plan Go-live and Rollback

A WAF publication should not be considered complete simply because the rule has been saved. The key is whether DNS, certificate, hosted address, backend, protection profile, and logging work together. Especially where port forwarding already exists, treat the switch as a small deployment.

Before go-live, check:

• Document the current firewall configuration or at least the affected rule and certificate settings.
• Identify previous DNAT or firewall rules affecting the same port, public IP, or hostname.
• Deactivate old DNAT rules or clearly document why they do not compete with the WAF rule.
• Reduce DNS TTL before a switch if the public hostname changes from an old publication to the WAF.
• Provide external test access, rather than testing only from the internal LAN.
• Define test cases: homepage, login, upload, download, API path, WebSocket, logout, and error message.
• Define the expected log locations: Log Viewer, reverseproxy.log, backend access log, and backend error log.
• Define rollback criteria, such as login not possible, backend not reachable, wrong certificate, high error rate, or critical application components not working.

During the switch, only one publication should be active at a time. If an old DNAT rule and a new WAF rule use the same public IP and port, the behaviour is difficult to trace. Before switching to production, it should be clear which rule actually processes the traffic.

A simple rollback often involves deactivating the new WAF rule and reactivating the previous publication. If DNS was also changed, the DNS TTL must be considered. In cases of certificate or hostname issues, a rollback via DNS alone is often too slow; in such cases, it should be possible to reactivate the old rule on the same Hosted address, or alternative access should be available.

After go-live, the first accesses should be actively monitored. Important factors include not only successful HTTP status codes but also WAF blocks, backend errors, unexpected redirects, session problems and missing client IP information in the backend logs.

Acceptance Test After Go-live

A WAF test is only complete when the same request is traceable from three perspectives: client, firewall and backend. This helps identify more quickly whether a problem lies with DNS, the certificate, WAF matching, the protection profile or the application.

• External client: Check DNS resolution, the certificate, HTTP status, login and important paths. The application should open via the public hostname without a certificate warning.
• Sophos Firewall: Check Log Viewer, the WAF rule, reverseproxy.log and blocked signatures. The correct WAF rule should process the access, and logs should show allowed requests or requests blocked for a valid reason.
• Backend web server: Check the access log, error log, application session and X-Forwarded-For. The request should reach the correct vHost or path, and the client IP logic must be understood.

For production applications, at least these cases should be tested:

• Access via the correct hostname and via a non-matching domain.
• Login with a valid and an invalid user if the application or WAF handles authentication.
• Upload, download, API or WebSocket functionality if the application uses these functions.
• Access from an allowed source and, if possible, from a deliberately disallowed source.
• The behaviour of a known harmless WAF test request, to make logging and the blocking path visible.

If the application appears to work after go-live but no matching logs are visible, the test is not yet complete. Another publication may be matching, logging may be missing, or access may not be following the expected path.

Secure Protection and Access

For public web applications, WAF is only one layer of protection. Certificates, source restrictions, Threat Feeds, protection profiles and backend logging must be planned together.

Certificates and Hostnames

For HTTPS, the WAF rule must use a certificate that matches the public hostname. The certificate is imported or created under Certificates > Certificates and then selected in the WAF rule.

Important points:

• The DNS name must match the certificate.
• The selected HTTPS certificate can automatically populate the domain list in the WAF rule or overwrite existing domain entries.
• For multiple hostnames on the same IP, the firewall uses SNI.
• Wildcard certificates are possible but should be properly documented.
• Wildcard domains are only used after more specific domain rules. *. is only permitted at the beginning, for example *.example.com; multiple wildcard domains in one rule are possible.
• Underscores in the left-hand domain label do not form a proper DNS name and should be avoided for WAF domains.
• The backend can use a different internal name if the host headers and application can handle it.
• For problems with absolute links, Rewrite HTML may become relevant.

When multiple virtual web servers run on the same IP and port, the firewall decides which WAF rule matches based on SNI and the hostname for HTTPS.

The domains in the WAF rule should therefore match DNS and the certificate exactly. Wildcards can be helpful, but they should not replace a well-planned publication design. If several applications run under similar hostnames, clear rule and certificate documentation is needed; otherwise, it becomes difficult to trace which WAF rule actually matched. A test with a deliberately non-matching subdomain is useful: it shows whether the specific rule, a wildcard rule or no matching virtual web server responds.

The certificate object name may contain only alphanumeric characters from the US-ASCII character set; this is not the same as the DNS name in the certificate. After selection, check the automatically populated Domains and edit, add or delete entries as required. HTTPS makes the listener accessible over HTTPS, not additionally over HTTP. Redirect HTTP separately redirects access from port 80 to port 443; these listeners and potential port conflicts must therefore also be planned.

A non-matching subdomain name does not necessarily produce a graphical block page. The documentation shows, for example, 403 for a request to another subdomain. Therefore, check the HTTP status and reverseproxy.log, not just the appearance of the browser page.

Plan Client IP and Backend Logs

In WAF publications, the internal web server often does not see the real client IP as the direct source address. The Sophos Firewall acts as a reverse proxy and establishes the connection to the backend itself. Therefore, the firewall address may initially be visible to the application and in the web server logs.

If the application or backend needs the original client IP, check early whether X-Forwarded-For or a comparable header is evaluated. This is important for:

• Application logs and security analysis
• Rate limits or login protection at the application level
• Error analysis linked to a user or source IP
• SIEM or monitoring correlation
• Forensic analysis after an incident

The trust boundary is important: a backend should only treat such headers as trustworthy if the request really comes from the Sophos Firewall or a defined reverse proxy. Public clients must not be able to set X-Forwarded-For directly as proof for security decisions. In practice, the web server should therefore only trust the firewall IP and ignore or overwrite headers from other sources.

For troubleshooting, this means that Log Viewer, reverseproxy.log and the backend log must cover the same test time. If only the firewall IP is visible in the backend, this is not automatically a WAF error but often normal reverse proxy behaviour.

Restrict Client Access

Not every web application needs to be accessible worldwide. Access can already be restricted in the WAF rule.

Sensible restrictions:

• Allow only known source IP addresses or partner networks.
• Block unnecessary countries.
• Only block IP addresses of unknown country origin if the risk of locking yourself out has been assessed.
• For portals, additionally use WAF-MFA or pre-authentication.
• Block known malicious sources via Threat Feeds.

For country and malicious IP blocking, Sophos Firewall: Block Countries and Malicious IPs helps. For dynamic threat lists, Sophos Firewall Threat Feeds is relevant.

Plan Threat Feeds and Active Threat Response

For publicly accessible web applications, you should consider more than just the WAF rule itself. Since SFOS 22, Threat Feeds have also become more relevant for incoming, forwarded traffic such as WAF and DNAT publications. The firewall can check such matches against MDR Threat Feeds, NDR Essentials and Third-Party Threat Feeds.

For administrators, this means that WAF is the publication layer, while Threat Feeds and Active Threat Response can additionally block or make visible known malicious sources. However, this does not replace patch management, sound authentication or application hardening.

In practice, check:

• Is Active Threat Response sensibly configured in the environment?
• Are relevant Threat Feeds used and regularly checked?
• Are WAF events, Active Threat Response logs and backend logs visible during operation?
• Is there a process for false positives, allowlisting and emergency authorisations?
• Is it clear who responds to matches and whether they are only logged or actively blocked?

Especially for customer portals, admin interfaces or partner access, this check should happen before go-live. If a feed later blocks production traffic, the operations team must know where to see the match and how to make a sound decision: genuine attack, false positive or incorrectly published application.

Protection Profiles and Exceptions

A WAF rule should not only publish but also protect. For this, use Protection Policies, optional IPS Policies and exceptions.

Typical protection areas:

• Cookie Manipulation
• URL Hardening
• Form Hardening
• Cross-Site Scripting
• Application Attacks
• Antivirus Scanning
• Bad-Reputation Clients

Additional global Web Server Protection settings are under Web server > General settings, including TLS version control and protection against slow HTTP DoS patterns. These settings do not apply to only one rule. Changes should therefore be planned deliberately and coordinated with existing WAF publications.

SFOS 23: Adjust the Worker Profile Deliberately

Under Web server > General settings > Worker customization, the firewall calculates the default values based on the available CPU and RAM resources; they suit most installations. Higher values can negatively affect WAF performance and system resources. Enable Use custom worker profile only after confirming the need and assessing the impact. Beforehand, document the previous values and whether the profile is calculated or custom, create a configuration backup, and plan a maintenance window and rollback to that exact previous state. This adjustment does not change Maximum sessions.

• Start servers: Number of worker processes started when the web server starts.
• Server limit: Maximum number of worker processes that can run simultaneously.
• Minimum spare threads: Minimum number of idle threads kept available for new requests.
• Maximum spare threads: Maximum number of idle threads before excess threads are removed.
• Threads per child: Maximum number of worker threads per worker process.
• Asynchronous request worker factor: Controls the scaling of worker processes for asynchronous connections and requests.

For form-based reverse-proxy authentication, the global Maximum sessions field limits concurrent user sessions across all WAF rules that use this authentication method. The default is 25,000, with an allowed range of 100 to 100,000. When the limit is reached, the firewall closes old or expired sessions to allow new ones. This is therefore not capacity per rule; size it for concurrent logins across the affected applications, then verify login, logout and session switching after a change.

For Slow HTTP protection, Soft limit is the initial timeout allowed for receiving the request header. Hard limit sets the absolute upper limit. Extension rate defines how many additional received bytes extend the soft limit by one second. Test these three values together and with genuinely slow clients; one overly generous value can unnecessarily weaken the protection.

For Slow HTTP protection, limit exceptions to the smallest required IP address or network. Sophos supports IP and network host objects at this point, but not IP ranges or host lists. The Minimum TLS version is also global; before tightening it, test older clients and every published application through a real external connection.

As global TLS presets, SFOS offers options including TLS v1.2 (wide compatibility), TLS v1.2 (strict) and TLS v1.3. Change Custom protocol configuration and Custom cipher configuration only with documented and tested OpenSSL values; TLS 1.3 cipher suites are maintained separately. Invalid values can prevent the SFOS-managed Apache service and therefore Web Server Protection from starting. The change plan must include the previous values, a configuration backup, a maintenance window and alternative administrative access. Afterwards, test every WAF publication and check reverseproxy.log; if the service does not start, revert the most recent custom values instead of trying more variants in production.

For Protection Policies, the mode matters. Reject blocks and creates visible Log Viewer events for WAF rules. Monitor only logs, but these WAF messages do not necessarily appear in Log Viewer; in that case, reverseproxy.log must be checked. Monitor can be useful for a pilot phase, but production protection requires clarity on whether attacks are only observed or actually rejected.

The Common threat filter uses four filtering strengths. Level 1 is the most permissive and is not logged; from Level 2 onwards, matches appear in /log/reverseproxy.log, while the false-positive risk also increases. Exclude individual rules under Skip filter rules only by using the Rule ID confirmed in the log. Disabling an entire category or a higher level across the board is not a sound substitute for this analysis.

Static URL hardening is case-sensitive, accepts no wildcards, and does not help with URLs generated dynamically by JavaScript. Form hardening compares the form structure and supports forms up to 8,000 bytes. If binary content is incorrectly served as HTML or XML, both functions can corrupt it; correct the backend Content-Type first instead of broadly disabling protection.

For antivirus scanning, a size limit applies to the total upload volume of a request, not to each individual file. The additional Request size limit for the HTTP body ranges from 1 to 1,024 MB and defaults to 10 MB. HTTP Strict Transport Security adds the HSTS header only when the WAF rule uses Redirect HTTP; MIME-type sniffing protection sets X-Content-Type-Options: nosniff. Uploads, downloads, and headers must therefore be checked with the actual application.

IPS in a WAF rule should be assessed separately. Sophos only applies IPS for WAF when communication between the firewall and web server uses HTTP. If the backend is connected via HTTPS, do not automatically expect a selected IPS policy to have the same effect.

Exceptions should be narrowly scoped. If an application does not work because of a single path or a specific source, do not disable the entire protection profile. A targeted exception with a path, source, and clear justification is preferable.

⚠️ Every exception reduces protection. Document the path, source, reason, date, and review date so that temporary workarounds do not become permanent.

Create a Protection Policy and Understand Its Protective Effect

Under Web server > Protection policies > Add, assign a descriptive name, for example WAF_Portal_Protection, configure the required protection features, and select Save. Then select the policy in the WAF rule’s Protection field; under SFOS 23, it applies only to Protect paths. An existing default policy, such as one for Exchange Autodiscover, should only be used for its intended use case.

For a pilot deployment of your own application, first make a clear choice between Monitor and Reject. Monitor does not block and does not show the relevant WAF messages in Log Viewer; reverseproxy.log is required for these. The greater visibility provided by Reject must not be confused with application compatibility that has already been tested. Pass Outlook anywhere allows external Outlook clients to bypass web server protection for Exchange access. This option is not a general compatibility solution for modern portals and should remain disabled unless there is a justified legacy use case.

Understand Cookie, URL, and Form Protection

Cookie signing adds a second cookie to a cookie set by the server, containing a hash derived from the name, value, and a secret known only to the firewall. If the client does not return the matching pair, the cookie is discarded. This protects against tampering, but replaces neither secure application sessions nor correct backend cookie configuration. Test login, shopping cart, and other cookie-dependent workflows after enabling it.

With Static URL hardening, the firewall signs static links and uses the server response to determine which subsequent links are permitted. Entry URLs defines entry URLs that may be accessed without a hardening signature; for a simple website, / can be the entry point. This list is not a general routing list. Observe case sensitivity and do not enter wildcards. Applications with JavaScript-generated URLs or legitimate deep links require separate assessment. Form hardening signs the original form structure and rejects tampered forms. The existing limit of 8,000 bytes and the correct HTML/XML Content-Type remain crucial.

The documented simple attack-protection example uses Reject, Static URL hardening with / as the entry point, Form hardening, Antivirus, Block clients with bad reputation, and Common threat filter. Cookie signing, Pass Outlook anywhere, and Skip remote lookups for clients with bad reputation are disabled in that example. This is a test profile for that specific workflow, not a universal recommendation or evidence that the defaults suit every application. For a modern portal, assess each of these switches against actual application traffic. The Basic with passthrough setting mentioned there is not an MFA recommendation either; client mode, credential forwarding, and templates are explained in the linked WAF Authentication and MFA article.

Configure Antivirus and Reputation Settings Deliberately

Under Antivirus, Mode determines whether one or two scanning engines are used; for single scanning, select the engine. Direction specifies uploads, downloads, or both directions. Block unscannable content blocks, for example, encrypted or damaged files that cannot be scanned. This strengthens enforcement but can affect legitimate encrypted documents; define permitted business workflows and the support process beforehand.

Limit scan size limits the volume to be scanned; 0 or an empty field means there is no size limit for scanning. For example, with a 50 MB scan limit and files of 45, 5, and 10 MB in one upload, the last file is not scanned. A successful upload therefore does not prove that every file it contains has been scanned. Distinguish this scan limit from the Request size limit for the entire HTTP body: a larger body limit does not automatically make more content scannable. Choose limits based on the uploads actually required, resources, and security requirements, and test multi-file uploads and unscannable content in an authorised test environment.

Block clients with bad reputation uses RBL and GeoIP information: Sophos SXL for RBLs and MaxMind for GeoIP. Blocking is also documented for the classifications A1 (anonymous proxies or VPN services) and A2 (satellite ISP). This can affect legitimate partner access. Skip remote lookups for clients with bad reputation can improve performance, but changes assessment through remote queries; do not enable it without due consideration or equate it with a source allowlist.

Assess Common threat filter by Category and Strength

The categories address different issues and should be selected deliberately for the application:

• Application attacks: Detects, among other things, unauthorised path access and typical command execution attempts, including after a possible compromise.
• SQL injection attacks: Checks request arguments for embedded SQL commands and escape characters.
• XSS attacks: Checks inputs for embedded script tags and code.
• Protocol enforcement: Checks protocol compliance, typical headers such as Host and User-Agent, argument limits, and permitted HTTP usage. An unusual but legitimate client may therefore also be flagged.
• Scanner detection: Detects typical bot, crawler, and scanning patterns; intended search engine or monitoring access must still be tested.
• Data leakage: Prevents sensitive information from reaching the client, for example through server error messages. If Application attacks or SQL injection attacks is enabled, this category should also be reviewed because the detection areas overlap.

Filter strength defaults to Level 1 and produces the fewest false positives. Level 2 adds, for example, regular expressions for SQL/XSS injection and further code-injection keywords; Level 3 adds rules, keyword lists, and special-character limits; Level 4 restricts special characters even further and requires particularly thorough false-positive testing before go-live. The logging limitations described earlier still apply: Level 1 is not logged, while Level 2 and higher appear in /log/reverseproxy.log. Do not consider a higher strength accepted as safe simply because a homepage opens.

Check HSTS and MIME Protection Before Enabling Them

With HTTP Strict Transport Security and Redirect HTTP enabled, the firewall adds this header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 corresponds to one year. This affects more than just the entry point tested: includeSubDomains includes subdomains, and browsers can store the policy. Before enabling it, HTTPS, certificates, and all affected subdomains must work reliably on an ongoing basis; subsequently clearing the checkbox does not immediately undo policies already stored by browsers. The presence of preload in the header alone does not prove inclusion in a browser preload list. MIME-type sniffing protection adds X-Content-Type-Options: nosniff; correct incorrect MIME types on the backend rather than removing the header across the board. Check both headers from the external client.

Create Exceptions with the Narrowest Necessary Scope

Under Add new exception, specify Paths, Sources, Operation, and the specific checks to skip. Exception paths are case-sensitive and allow wildcards, for example /products/*/images/*. This distinguishes them from the wildcard-free Entry URLs in the Static URL Hardening Policy. For Operation, the Boolean relationship is crucial: matching both a path and a source is narrower than matching either a path or a source. Check the intended intersection before saving so that a partner source is not inadvertently exempted from protection for all paths.

IP addresses, ranges, lists, and networks are documented for an exception’s Sources. This must not be assumed to apply to other fields: for SFOS 22 Path-specific routing, and for the SFOS 23 Passthrough fields Allowed client networks and Blocked client networks, only the host types IP and Network are documented, not IP ranges or IP lists. Use individual IP or network objects in those fields for predictable access restrictions.

An exception’s switches skip checks including Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation, and selected Common threat categories. Two options require additional caution:

• Never change HTML during static URL hardening or form hardening prevents the HTML page from being rewritten, for example if the application depends on unchanged links. This does not automatically mean that unsigned links will be accepted; a targeted hardening exception may be required for that.
• Accept unhardened form data accepts form data without a hardening signature. A Form hardening exception alone does not do this. This additional allowance removes another check and is suitable only for a precisely scoped, justified workflow.

Beforehand, record the failing legitimate request, timestamp, and confirmed Rule ID. Afterwards, repeat the same request and cross-check a source or path that is not covered by the exception. The exception is only meaningfully scoped when the required workflow works and the remaining protection is retained; if in doubt, exclude a single confirmed Rule ID under Skip filter rules rather than an entire protection area.

Revalidate Migrated Protection Policies

Since SFOS 18, Web Server Protection has used the OWASP ModSecurity Core Rule Set 3.0. When older Protection Policies were migrated, previous categories were merged, rule IDs were remapped, and filtering strengths were introduced. If one of the merged categories was previously enabled, the new combined category can therefore be enabled even when another part was previously disabled.

After such an upgrade, comparing only the policy name is insufficient. Check the enabled categories, exceptions, and filtering strengths against the previous documentation. Then run controlled positive and negative tests with real application traffic and review Log Viewer and reverseproxy.log. The migrated policy is accepted only when legitimate requests continue to work and the expected test attacks are detected.

The following mappings are important for the old SFOS 18 migration: Protocol violations, Protocol anomalies, Request limits, and HTTP policy became Protocol enforcement; Generic attacks and Tight security became Application attacks; Bad robots became Scanner detection; Outbound became Data leakage. Rigid filtering migrates to Level 1 and must be deliberately reassessed. The Trojans category was removed; antivirus provides the corresponding protection. Previously excluded rules with a mapped new Rule ID remain excluded, whereas unmapped, removed, or merged IDs are removed from the skip list. Do not therefore copy the old exception list without checking it; compare it against the current policy and current logs instead.

Path-specific Routing, WebSocket, and Load Balancing

WAF can forward requests to different backend servers depending on the path. This is useful if an application has multiple components or a single hostname should be distributed across multiple internal services.

Examples:

• /api/ goes to an API server.
• /shop/ goes to a shop system.
• / goes to the default web server.

The firewall does not evaluate paths in table order; it prioritises longer and therefore more specific paths over the fallback route. This routing must be specifically tested. For SFOS 22 only: The WebSocket passthrough checkbox can be enabled for the required website path; WebSocket traffic is passed through without WAF protection because WebSocket data cannot be inspected like normal HTTP traffic. For SFOS 23: Under Traffic routing, configure only the required WebSocket path with Action > Passthrough and the intended backend. This tunnel operates without WAF inspection and without a protection policy; the other application paths remain on Protect. Never switch the entire portal to Passthrough as a workaround. Test the connection upgrade, data transfer, and reconnection separately. This does not establish anything about MFA enforcement with Passthrough; if authentication is required, clarify responsibility with the person responsible for authentication.

For SFOS 22 only: With the Protected servers procedure, the default path / forwards requests without a more specific match to the assigned default server. If this default route is removed, the firewall rejects such requests with 404 Not Found. For SFOS 23: Requests without a more specific match use the action for /; for new rules, this is Block by default. Deliberately retain this fallback route if only individual paths should be published. Protect for / makes sense only when publishing the entire application is intended and requires a review of the additional accessibility. No fixed 404 status is guaranteed for SFOS 23: the response from Block is configured through Response code.

With multiple backend servers, sticky sessions or hot standby are possible. This helps with simple high-availability or load-distribution scenarios but does not replace a complete application load-balancing design.

Without additional session affinity, requests are distributed across the selected web servers. Sticky session cookie binds the browser to a backend server; if that server fails, the cookie is updated and the session is switched to another server. This does not guarantee that application state is transferred: a shopping basket, for example, may require a shared session store.

Hot-standby mode initially sends all requests to the first selected server and uses the others as backups. When the primary server returns, sessions generally switch back; with Sticky session cookie enabled, the existing session remains on the backup. Therefore, separately verify the primary server, backup order, failure, recovery, and an actual stateful login or shopping-basket process during acceptance testing.

The Authentication field is also listed for Passthrough in the SFOS 23 table, whereas the feature overview assigns authentication to Protect. This inconsistency in the documentation is not resolved by assumptions. If WAF-MFA is required, base the protected part on Protect and an explicit policy; the scope distinctions and tests are covered in WAF authentication with MFA.

Reach remote WAF backends through SD-WAN

If the protected web server is not in the firewall’s local network, routing and SD-WAN should be checked especially carefully. For backends over inter-site links, MPLS, or route-based IPsec, a matching SD-WAN route may be needed so that the firewall reliably reaches the Protected Server and the return path is correct. With route-based IPsec, also note: WAF over route-based IPsec with Traffic Selectors for subnets is not supported by Sophos; Any-to-Any connections are the documented workaround.

The Sophos-documented design starts with a working WAF rule and a reachable route-based tunnel. Under Routing > Gateways, create a gateway object for the remote path with the peer IP address, the relevant XFRM interface, and a reliable monitoring host behind the peer. Only then create the targeted route for WAF proxy traffic under Routing > SD-WAN routes:

1. Create and save the gateway under Routing > Gateways > IPv4 gateway > Add. In the example, it is named gw6, with Gateway IP 10.12.13.2 and Interface xfrm1-10.12.13.1. Under Monitoring condition, use a host behind the gateway that responds reliably; the documented example uses 10.12.13.2. Replace these private addresses and the interface with the actual tunnel addressing and a suitable monitoring host.
2. Under Routing > SD-WAN routes, select IPv4 and Add, using a name such as SD-WAN_WAF_Portal. Under Destination networks, remove Any and select the public WAN interface or Hosted address through which the client reaches the WAF rule; in the example, this is #Port1. For this documented WAF route, this is not simply the private backend IP.
3. Under Services, remove Any and select the external Listening Port of the WAF rule; in the example, this is TCP 8080. If it differs from the internal backend port, the external port explicitly belongs here. The non-standard port must also be included in the external test request.
4. Under Link selection settings, select Primary and Backup gateways and set Primary gateway to the previously created XFRM gateway gw6. Save the route. If several publications use the same gateway, the same SD-WAN route can contain several public WAN addresses and Listening Ports. Separate routes are required for different gateways.

The SD-WAN procedure refers to a guide for route-based VPN with Traffic Selectors; however, the WAF rule reference explicitly excludes subnet-based Traffic Selectors. For this WAF use case, therefore, plan an Any-to-Any connection and do not interpret the linked guide’s heading as approval for subnet-selector configurations.

Acceptance testing then separates the layers: the external test must match the expected WAF rule; correlate the WAF rule, reverse-proxy errors, and timestamp in Log Viewer; the XFRM interface, gateway monitor, and SD-WAN route must be active on the firewall; and the backend server must receive the request and reply through the intended path. A green tunnel alone proves neither the SD-WAN match nor backend reachability.

Operation and Troubleshooting

In operation, what matters is whether the publication remains traceable: which rule matches, which logs are relevant, which exceptions exist, and how to proceed when problems occur.

Common Errors

• Public DNS name points to the wrong IP: The WAF rule is never reached.
• Certificate does not match the hostname: Browsers show certificate errors or SNI matching fails.
• Wrong Hosted address chosen: The firewall matches another rule or no WAF traffic.
• Allowed client networks empty: The rule does not work as expected.
• WAF rule limit not considered: Further publications can no longer be configured cleanly.
• Exchange version after 2013 planned with WAF template: The template does not fit the supported WAF limit.
• Port conflict with User Portal, VPN Portal, or another service: The application is not reachable or a firewall service responds.
• Backend is not reachable internally: External clients receive errors even though DNS and certificate are correct.
• Backend timeout set incorrectly: Long responses end in errors even though the application is basically reachable.
• Backend is over VPN or SD-WAN without a matching route: The WAF rule matches, but the Protected Server is not reliably reached.
• Route-based IPsec with Traffic Selectors to the backend: WAF over this path is not supported.
• WAF exception set too broadly: Protection is unnecessarily weakened.
• WebDAV application published via WAF: The application does not work reliably or is not supported.
• URL path contains %2F: The WAF returns 404 Not Found even though the resource is directly accessible on the backend. %2F is the URL-encoded form of a slash / and must be distinguished from a normal backend 404.
• Rule change without a maintenance window: Existing connections may break when WAF rules restart.
• Old DNAT rule and new WAF rule compete: It is unclear which publication processes the traffic.

Troubleshooting

If a WAF publication does not work, systematically check:

1. Does the public DNS name point to the correct public IP?
2. Is the correct Hosted address selected in the WAF rule?
3. Is the Listening Port free and not occupied by WebAdmin, User Portal, VPN Portal, or another publication?
4. Does the certificate match the requested hostname?
5. Is the internal web server reachable from the firewall?
6. Are Allowed client networks, Blocked client networks, and Blocked countries set correctly?
7. Is the Protected Server behind a route, SD-WAN route, or VPN connection that really fits from the firewall’s perspective?
8. Is there a more general WAF rule that matches first?
9. Is the access shown as allowed, blocked, or dropped in Log Viewer?
10. Are there any clues in /log/reverseproxy.log?
11. Is the Protection Policy set to Monitor or Reject?
12. Does the timeout of the web server object suit the application?

For initial analysis, the Log Viewer is useful. For deeper troubleshooting, the Web Server Protection logs on the firewall help. An overview of log files and services is available in Sophos Firewall Troubleshooting: Services and Logs.

WAF returns 404 for %2F in the path

A specific error occurs with URLs containing an encoded slash. A request such as https://portal.example.com/api/files/project%2Freport.pdf can return 404 Not Found through the Sophos WAF even though the resource exists when accessed directly on the backend. Sophos tracks this behaviour as NC-159041 and currently specifies neither a particular affected or fixed SFOS version nor a supported workaround.

To narrow down the cause, compare the same request through the WAF and directly on the backend under controlled conditions. The exact URL and test time are important:

1. Check whether the path actually contains %2F. A normal slash / or a missing default path is a different error condition.
2. Compare the timestamp in Log Viewer, /log/reverseproxy.log, and the web server access log.
3. If no matching entry for the request reaches the backend, it was probably rejected before reaching the web server. A direct backend test also rules out the resource itself being missing.

A broad WAF exception does not address this issue specifically and would unnecessarily weaken protection. Do not modify the Apache configuration managed by SFOS either: restrictive handling of encoded slashes helps prevent bypasses of path-based or access controls.

The cleanest solution is for the application or its vendor to generate URLs without encoded slashes. If that is not possible, deliberately weigh another publication method such as DNAT, a suitable reverse proxy, or private access against the loss of WAF protection. For applications that cannot be changed, Sophos Support should assess the specific SFOS build and use case. The forms project%2Freport.pdf and project/report.pdf are only a diagnostic pattern and are not automatically functionally equivalent.

Checklist for Production WAF Rules

• Rule name describes the application, hostname, and environment.
• Responsible person or system owner is documented.
• DNS, certificate, and Hosted address are checked.
• Backend reachability has been tested from the firewall.
• Previous publication and rollback are documented.
• Old DNAT or firewall rules do not compete with the WAF rule.
• External go-live tests are defined.
• Access is restricted to necessary sources or countries.
• Threat Feeds and Active Threat Response have been evaluated for public applications.
• Logging is active.
• Protection profile is not unnecessarily disabled.
• Exceptions are narrow, justified, and time-limited.
• Change has been tested externally.
• Expiry date or review date is documented.

Understanding WAF objects in the XML API

For automation, publishing, the backend and the protection policy belong together, but remain separate objects. FirewallRule with PolicyType HTTPBased contains HTTPBasedPolicy; RealServers describes the backend web server and ProtocolSecurity the protection policy. The WAF rule references these objects; it does not replace their configuration. Access, TLS verification, secrets, explicit write operations and interpretation of the XML status are explained in Safely restricting XML API access.

The following mappings explain the SFOS 22/23 references, but are not executable request templates. Before any write operation, compare the API help for the installed build with the existing object, prepare a backup and a rollback path, and first check a harmless read query. If the syntax, unit or action mapping is unresolved, do not write; arrange clarification with Support instead. This applies particularly after a version change.

Do not confuse publishing with access paths

Name identifies the FirewallRule; the reference allows a maximum of 60 characters, no commas and UTF-8. Position is mandatory and specifies Bottom, Top, After or Before; the last two options also require the named reference rule. For Status, the table lists a default of ON and the write values Disable and Enable: omitting it is not a safe way to prepare a disabled publication. According to the table, LogTraffic defaults to Disable; check logging explicitly. The shared FirewallRule contract also offers IPv6 for IPFamily, but HTTPBasedPolicy is explicitly limited to IPv4. Network and user rules are covered under Firewall rules, not adopted as WAF payloads.

In the WAF section, HostedAddress, ListenPort, HTTPS, HTTPSCertificate and Domains/Domain correspond to the public listener. The table lists HostedAddress, ListenPort, HTTPS and Domains as mandatory fields. ListenPort is an integer from 1 to 65535; the documented values are 80 when HTTPS is disabled and 443 when HTTPS is enabled. This is not the backend port. RedirectHTTP is the separate HTTP redirect. Check the public name, certificate and listener together after every change.

Path mappings are located under HTTPBasedPolicy/AccessPaths/AccessPath. Within this, backend references the web server objects; allowed_networks, denied_networks, blocked_countries and block_unknown_country describe client access. stickysession_status and hot_standby relate to session persistence and backend selection. A referenced authentication policy is explained in the WAF authentication article; the presence of a field alone does not enforce MFA for every action.

Version difference: The SFOS 22 table describes path as a single string and backend as a mandatory array. In SFOS 23, path is an array with multiple values, while backend is listed as optional. According to the table, path values are limited to 63 characters and must not contain commas. Optional does not mean here that a Protect or Passthrough path can usefully be published without an assigned backend: the current UI requires backend selection for these actions, while Block and Redirect do not publish a backend.

SFOS 23 adds the lower-case action with the permitted values 0, 1, 2, 3, as well as response_code, redirect_protocol, redirect_host, redirect_port and redirect_path. The reference does not map the four numbers to the UI actions. Do not construct a mapping from their order or from assumptions; a confirmed mapping for the installed build is a prerequisite for any automated change. The capitalised Action with Accept, Drop, Reject appears in the example under UserPolicy or NetworkPolicy, not in the WAF block. It replaces neither the outer UI WAF action nor AccessPath/action. The table literally lists http and https for redirect_protocol, 1 to 65535 for redirect_port, and a maximum of 8192 characters for redirect_path. response_code is described there only as an integer; the UI selection above remains authoritative for the specific configuration.

The example is not proof of the schema either: it mixes path and Path, contains empty references and placeholders, and does not show HTTPSCertificate or LogTraffic in full within the WAF block. SFOS 22 still shows websocket_passthrough; SFOS 23 uses the action model. Therefore, confirm spelling, nesting, required fields and logging in the build-specific contract rather than mechanically completing the example. ProtocolSecurity in the WAF block references the protection policy. The advanced switches PassHostHeader, RewriteHTML, RewriteCookies and CompressionSupport relate to the reverse-proxy adjustments explained above; do not reconcile conflicting example/table values into enums of your own.

The example also shows SourceNetworks/Network and ExceptionNetworks/Network, while its comment alternatively names Authentication, AllowFrom, BlockFrom or AccessPaths. Do not infer alias equivalence, a permitted combination or a precedence rule from this. For existing objects using this access representation, clarify the structure and effect in the installed build; if these remain unresolved, do not perform automated writes.

Exceptions have their own Exceptions/Exception block. Within it, path, source and op combine the conditions; the table literally lists and, or, AND, OR for op. skipcookie, skipurl, skipform, skipav and skipbadclients skip the respective checks. By contrast, skiphtmlrewrite prevents matching content from being modified, and skipform_missingtoken allows form data without a hardening signature in addition to the form exception. The corresponding table row swaps the description and default; do not infer a reliable default from it. The security implications of both options described above remain decisive. skip_threats_filter_categories uses different tokens from the protection policy, for example application_attacks and data_leakages. Do not confuse these exception tokens with the policy display names. The outdated description of earlier categories does not authorise the use of old tokens either. After a change, check the permitted path, blocked path, catch-all route and a request not covered by an exception separately.

The table describes path for site-path routes; the exception example, by contrast, shows multiple path elements within an Exception, without a clearly defined table contract of its own. Therefore, do not apply routing-path cardinality and limits to exceptions. Before making automated changes to exceptions, confirm the structure, count, and permitted values in the installed build; do not write if the contract is unclear.

Safely checking the backend contract and timeout

For RealServers, Name, Host, Port and TimeOut are documented as mandatory fields. Name allows a maximum of 60 UTF-8 characters without commas. Host is a reference to an IP or FQDN host object, not a freely interchangeable public WAF name. Port ranges from 1 to 65535, with an API default of 80; Type literally lists Plaintext (HTTP) or Encrypted (HTTPS). For an HTTPS backend, therefore, explicitly verify the actual listener and port rather than adopting the API port default.

The API describes TimeOut with a default of 300, a range of 1 to 65535 and a note that it applies only when Keep alive is enabled. The GUI, by contrast, explains Timeout as the waiting time for data to or from the backend and states that an HTTP 502 occurs when it expires. This is a different description, not proof of identical behaviour when keep-alive is disabled. For UI configurations, use the data-pause test described above; before automation, clarify the dependency and stored value in the installed build. Do not infer a global timeout increase from this.

For KeepAlive, the example shows Enable/Disable, but the table lists only 0 and Enable, with a default of ON. Do not silently repair this discrepancy with an assumed Disable. DisableReuse lists Disable and Enable and corresponds to Disable backend connection pooling. Save the previous state, read back the changed object, and only then check representative data transfers and backend logs. An API response alone proves neither backend reachability nor appropriate connection settings.

Protection policy and dependent options

According to the table, ProtocolSecurity requires Name, Mode and RequestSizeLimit. For Name, the limit is 60 UTF-8 characters without commas; Mode lists Monitor and Reject. The switches CookieSigning, StaticUrlHardening and FormHardening correspond to the cookie, URL and form protection above. According to the table, PassOutlookAnywhere defaults to OFF: the API describes Exchange access only briefly, while the GUI explicitly states that Web Server Protection is bypassed. Therefore, leave it disabled unless there is a justified legacy use case; do not treat it as an ordinary compatibility switch. When StaticUrlHardening is enabled, the reference describes EntryURLType with Manual, SitemapFile, SitemapURL; for the manual case, the example shows EntryURLList/EntryURL, with multiple entry URLs of up to 255 characters each. Do not infer from this that the GUI offers all API variants in the same way.

The API table lists CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation, and ThreatsFilter each with Default OFF, and ParanoiaLevel with Default 1. A new or referenced policy therefore does not, in itself, establish that protection checks are enabled. When creating a policy, explicitly set the intended switches and read them back. When editing without a confirmed update contract, assume neither that omitted fields are preserved nor that they are reset to defaults.

When AntiVirus is enabled, AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent and LimitScanSize become relevant. The integer Megabytes additionally depends on LimitScanSize being enabled. This remains separate from the body limit. SkipRemoteLookups depends on BlockClientsWithBadReputation; do not infer the effect of reputation checking solely from the brief API description.

ThreatsFilter enables the Common threat filter. This includes ThreatFilters/Filter, ParanoiaLevel with 1 to 4, and SkipFilterRules/FilterRules as a list of integer rule IDs. The permitted filter tokens are literally Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. The last token differs from the GUI name Data leakage. Make targeted exceptions only for evidenced false positives, then cross-check the remaining protection; level, category and exception are separate decisions.

RequestSizeLimit remains a source conflict: The API table lists it as mandatory, with a default of 10, the description “Megabytes” and an integer range of 1 to 1073741824. The current GUI, by contrast, documents 1 to 1024 MB, with a default of 10 MB. RequestSizeLimit is entirely absent from the API example. Do not infer a byte/MB conversion, an extended production limit or safe optionality from this. For the GUI, use the documented MB range; use an API write value only after confirming the unit, range and mandatory-field behaviour in the installed build. The same applies to the table label HSTS Enforcement, which is absent from the example: do not invent an XML tag from the name. XContentTypeOptions describes MIME protection; check the stored policy assignment and actual headers externally.

Distinguishing XML responses by operation

The following numbers are XML object statuses, not HTTP status codes. Here, Message.* denotes an unresolved symbol name from the reference, not a translated error message or proof of a precise cause. Check the response, operation and stored object state together; never blindly write again after errors, warnings or a possible partial change. The central API security guide explains the safe verification and escalation process.

For WAF-relevant responses from FirewallRule, the following differences are particularly important:

• Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. For 202, also read back the object name and references rather than simply reusing the old name.
• Add firewall rule 541 → Message.VHIPRangeConflict. Edit firewall rule 541, by contrast, has Message.FWRuleFailMaxUser; the same code must not trigger the same diagnosis.
• Add firewall rule 543 and Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 and Edit firewall rule 543 → Message.CannotUseDefaultPort. The mapping is reversed between Add and Edit: check the listener, port and redirect rather than classifying solely by the number.
• For Add firewall rule and Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Compare the existing listener/domain configuration; do not change port permissions on speculation.
• For both operations: 547 → Message.warn_update_business_policy; 548 and 549 both use Message.MaxIPv4ForAppServerAllowed. The duplicate symbol mapping does not establish different invented limits. Check the warning and the WAF state actually stored.
• Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Do not confuse public wildcard domains with a suitable backend host. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: check the name and policy type rather than overwriting an unrelated object.
• For Add, Edit and Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. Delete also lists 200 → Message.FWDelSuccess and 500 → Message.FWRuleDeleteFail. Clarify management responsibility and references before trying again. The Delete page describes Name as optional and uses an inappropriate description concerning Before/After; this is not a safe deletion template. Confirm the exact target and the build-specific Remove contract; otherwise, do not delete.

The backend and protection policy also have their own response sets: Add Web Server 200/500/502 stand for Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500 for Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 stand for Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500 for Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. The spellings RecodExist are retained literally, not corrected symbol names. For name collisions, first read the existing object; delete-and-recreate is not a safe standard retry.

For the global object WAFSlowHTTP, RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit and RequestHeaderTimeoutExtensionRate correspond to the switch and the three limits explained above. All four are documented as mandatory fields; the switch lists Disable and Enable, while the remaining values are integers with no specified range. NetworkExceptions/Host is an optional list of host references. The example values 10, 30, 5000 are not proven defaults. SlowHTTP Protection lists 200 with Operation Successful. and 500 with Operation Fail.. Changes remain global: check stored values and narrowly scoped exceptions, and validate all affected publications with slow legitimate clients.

Frequently Asked Questions