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.

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.

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.

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 built, but whether it can be operated securely, tested, and rolled back later. This classification helps before technical implementation:

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.

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.

Plan WAF Release 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 a productive publication:

For certificates, clarify early whether an existing certificate will be imported, 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.

Basic Structure of a WAF Rule

A WAF publication consists of several components:

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

Create a WAF Rule

The menu path is:

Rules and policies > Firewall rules

Procedure:

1. Select IPv4.
2. Open Add firewall rule.
3. Select New firewall rule.
4. Assign a descriptive rule name.
5. Choose Protect with web server protection for Action.
6. If no special template is needed, leave Preconfigured template as None.
7. Under Hosted server details, define the public address, listening port, HTTPS, certificate, and domains.
8. Under Protected servers, select or create the internal web server.
9. Set Allowed client networks consciously. For public websites, Any IPv4 may be necessary; for portals, a restriction is usually better.
10. Set Blocked client networks or Blocked countries if needed.
11. Check protection profile, IPS, and advanced options.
12. Save the rule and test externally.

When the rule is saved, Sophos restarts the Web Server Protection rules. Existing live connections over these rules may be interrupted. Therefore, changes to productive WAF rules should be made during a maintenance window or at least consciously.

Plan Go-live and Rollback

A WAF publication should not be considered complete just by saving the rule. The key is whether DNS, certificate, hosted address, backend, protection profile, and logging work together. Especially with existing port forwarding, treat the switch like a small publication.

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, not just test from the internal LAN.
• Define test cases: homepage, login, upload, download, API path, WebSocket, logout, and error message.
• Set expected log points: 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 parts defective.

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 behavior is difficult to understand. 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, the old rule should be reactivatable on the same hosted address or an alternative access should be available.

After go-live, the first accesses should be actively monitored. Important are 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 quickly identify whether a problem lies with DNS, certificate, WAF matching, protection profile, or application.

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

• Access via the correct hostname and via a non-matching domain.
• Login with valid and invalid user if the application or WAF authenticates.
• Upload, download, API, or WebSocket function if the application uses such functions.
• Access from an allowed source and, if possible, from a deliberately not allowed source.
• Behavior of a known harmless WAF test request to make logging and block path visible.

If the application seems to work after go-live but no matching logs are visible, the test is not yet complete. It may be that another publication matches, logging is missing, or access does not run through the expected path.

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.
• For multiple hostnames on the same IP, the firewall uses SNI.
• Wildcard certificates are possible but should be well documented.
• The backend can use a different internal name if host headers and the 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 fits based on SNI and hostname for HTTPS.

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 be visible first for the application and 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 evaluation
• Rate limits or login protection at the application level
• Error analysis with user or source IP reference
• SIEM or monitoring correlation
• Forensic evaluation 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 should not be able to set X-Forwarded-For directly as a security proof. In practice, the web server should therefore only trust the firewall IP and ignore or overwrite headers from other sources.

For troubleshooting, this means: Log Viewer, reverseproxy.log, and 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 behavior.

Restrict Client Access

Not every web application needs to be accessible worldwide. Access can already be limited 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 self-lockout has been assessed.
• For portals, additionally use WAF-MFA or pre-authentication.
• Block known malicious sources via Threat Feeds.

For country and bad 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 not only consider the WAF rule itself. Since SFOS 22, Threat Feeds are also more relevant for incoming, forwarded traffic like WAF and DNAT publications. The firewall can match such hits with MDR Threat Feeds, NDR Essentials, and Third-Party Threat Feeds.

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

Practically, you should 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 in operation?
• Is there a process for false positives, allowlisting, and emergency approvals?
• Is it clear who responds to hits and whether only logged or actively blocked?

Especially for customer portals, admin interfaces, or partner accesses, this check should happen before go-live. If a feed later blocks productive traffic, operations must know where to see the hit and how to decide cleanly: real attack, false alarm, 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

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

⚠️ Every exception reduces the protection effect. Path, source, reason, date, and review date should be documented so that temporary workarounds do not remain permanent.

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 to multiple internal services.

Examples:

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

Note that the firewall does not simply evaluate paths according to table order. Specific paths must be planned and tested cleanly. If WebSocket is needed, WebSocket passthrough can be activated. WebSocket traffic is then passed through without the same WAF inspection because the protocol cannot be inspected like normal HTTP traffic.

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

Common Errors

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 called 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 there a more general WAF rule that matches first?
8. Is the access shown as allowed, blocked, or dropped in the Log Viewer?
9. Are there any hints in /log/reverseproxy.log?

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.

Checklist for Productive WAF Rules

• Rule name describes application, hostname, and environment.
• Responsible person or system owner is documented.
• DNS, certificate, and hosted address are checked.
• Backend accessibility 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.

Frequently Asked Questions