Using Sophos Firewall Web Categories and Instant Alerts

Web categories control which websites users can access. Instant alerts add email notifications for a small number of deliberately monitored categories. For either feature to work reliably, the category, web policy, firewall rule, logging, and email delivery must align.

This is particularly useful in schools, sensitive business areas, or environments where certain web requests shouldn’t remain unnoticed until the monthly report.

A category alone doesn’t change traffic. A web policy must use it for an action, and that policy must be assigned to a matching firewall rule before the action enters the production traffic path. TLS inspection, QUIC handling, and logging also determine what the firewall can identify and report later.

For general web policy planning, start with Setting up Sophos Firewall Web Protection with Web Policies. For rule base assistance, see Understanding and Correctly Configuring Sophos Firewall Rules. This article focuses on the operational web part: categories, URL groups, instant alerts, evaluation, and response.

Orientation

Start by deciding which protection or configuration method fits the actual use case. This avoids broad rules and duplicated troubleshooting later.

Clearly Distinguish Terms

Sophos uses several web objects that are easily mixed up in everyday use.

• Web category: Category for domains, URLs, or keywords. Many categories come from Sophos, custom categories are possible. Allow, block, limit, or report web access based on risk or content.
• URL group: List of domains that can be used in web policies or TLS exceptions. Explicit allow or block lists when specific domains are more important than categories.
• Web policy: Rule set for users, groups, categories, URL groups, file types, content filters, and actions. Control web access and link with a firewall rule.
• Instant alerts: Email notification for access to monitored categories. Quick notification for particularly sensitive or high-risk categories.
• Log Viewer and Reports: Evaluation of the actual decision. Check if category, policy, user, and firewall rule work as expected.

A web policy only takes effect when selected in a suitable firewall rule under Security features > Web filtering. The web policy alone is not yet a productive rule.

When Web Categories Are Useful

Web categories are particularly useful when web access should not just be generally allowed or blocked. Typical scenarios:

• Block malware, phishing, and fraud categories.
• Restrict anonymizers, proxies, and circumvention services.
• Closely monitor command-and-control or spyware categories.
• Block categories like adult content, gambling, or controlled substances depending on the environment.
• Allow business-critical cloud applications but restrict private cloud or file-sharing services.
• In schools or supervised environments, monitor particularly sensitive categories with instant alerts.
• Limit bandwidth for certain web categories through traffic shaping.

Categories should not all be set to block or alert indiscriminately. Otherwise, many hits occur that no one can reasonably review. A small, clear set with an owner, response path, and review is better.

Prerequisites

Before configuration, these points should be clarified:

• Web Protection or a suitable Sophos Firewall bundle is licensed.
• There is a client or user rule that should use web filtering.
• User or group matching is planned if policies are to apply based on users.
• Log firewall traffic is active in the relevant firewall rule.
• Under System services > Log settings, at least Content filtering is selected for Local reporting. Select the same log type in the corresponding destination column for Central Reporting or syslog.
• Email notifications work if instant alerts are to be used.
• The appliance model supports Instant Alerts; XGS 87 and XGS 88 do not support this feature.
• For long-term evaluation, Central Firewall Reporting or Syslog is planned.
• QUIC and TLS inspection are consciously decided.

For central evaluation, see Enable Central Firewall Reporting. If logs are to go to your own SIEM, Send Sophos Firewall Syslog to SIEM is the better follow-up article.

Plan Policy Design

Before configuring alerts, define which categories are relevant, who receives notifications and what should happen after an alert.

Plan Categories and URL Groups

For admins, it is important to know when a custom web category and when a URL group is more appropriate.

A custom web category is useful when:

• Domains or keywords are to be used as a category in multiple web policies.
• The category should be consciously visible in reports and logs.
• A traffic-shaping concept by category is planned.
• A monitored category for instant alerts is to be created.

A URL group is usually better when:

• Only specific domains are collected.
• A small allow list or block list is needed.
• The list should also be used for TLS exceptions.
• Keyword matching should be avoided.

For pure domain matches, URL groups are more direct and easier to audit than categories with keywords. Keyword categories should therefore be used sparingly, especially for allow rules.

A URL group contains valid domains. Regular expressions aren’t allowed; entries are evaluated with OR, so a single match is sufficient. The current SFOS 22 help doesn’t specify a fixed maximum. This isn’t a promise of unlimited lists. For large or dynamically maintained lists, check whether an imported category database or threat feed is the more appropriate option.

Create and safely use URL groups shows the complete creation, web policy, TLS, and testing workflow.

Generative AI as a Web Category in SFOS 23.0

SFOS 23.0 documents Generative AI as a built-in web category for websites and services that let users create or transform content through prompts. Websites whose primary purpose is not generative AI are explicitly excluded. An additional AI feature within another service is therefore not enough to assume that the service belongs to this category. The category does not guarantee detection of all AI use.

This Sophos URL classification is used through a Web Policy. It is distinct from application signatures and the Generative AI application category in Application Control. A custom web category with the same name does not automatically synchronise with the application catalogue. An administrator-maintained domain list in a URL group or custom category is also a separate object with its own owner and review date, not the built-in category.

Before broad blocking, verify the effect on the deployed version in a limited pilot:

1. Check the category under Web > Categories and use Diagnostics > URL category lookup for an approved, harmless test URL. The lookup shows classification only, not the actual policy decision; a custom category can determine the displayed result.
2. Under Web > Policies, check the category, HTTP/HTTPS actions, and rule order. The policy must be selected in the matching firewall rule under Security features > Web filtering. Check Enable logging and reporting, Log firewall traffic, and Content filtering under System services > Log settings > Local reporting.
3. Follow Policy tester with a controlled real client request and check the category used, Web Policy, firewall rule, and action in Log Viewer. Evaluate Application Control decisions separately. If results differ, first check custom categories, rule order, exceptions, and the TLS/QUIC path rather than assuming complete AI detection.

Controlling Generative AI explains the choice between a web category, Application Filter, and supplementary domain list, along with the pilot workflow.

Block, Alert, or Just Reporting?

Not every category needs the same treatment. A good web protection design separates hard security decisions from hints and pure evaluation.

• Block: Malware, phishing, known circumvention services, clearly prohibited categories. Legitimate site may be blocked if category is incorrect.
• Warn: Grey areas, training environments, consciously allowable categories. Users get used to warnings and click through reflexively.
• Instant Alert: Few categories with real response obligation. Too many alerts lead to alert fatigue.
• Reporting only: Trend analysis, usage reports, weak signals. Hits become visible only later.

For productive environments, a small, clear selection is often better than a maximum catalogue. If no one evaluates an alert, the category should not run as an instant alert. If a category should always be blocked, an alert is only useful if a concrete follow-up results.

A fixed system boundary applies to websites Sophos classifies as highly objectionable criminal activity: the firewall blocks them regardless of web policy or exception and hides the domain name in logs and reports. In this case, a missing domain name is not a logging error.

Configuration

The configuration should be narrow, testable and easy to review later.

Create or Adjust Web Category

The menu path is:

Web > Categories

Basic procedure:

1. Edit existing category or choose Add.
2. Assign a name.
3. Select classification.
4. Optionally select a traffic shaping policy.
5. Choose configuration type.
6. Add domains or keywords.
7. Optionally activate Instant alerts.
8. Save.

For custom categories, the name should clearly describe the purpose. Names like Custom1 or Blocklist are not very helpful later. Better names are Alert_Self_Harm, Block_Proxy_Anonymizer, or Allow_Business_Cloud_Exceptions.

Domains are checked against the domain name in the URL and automatically include subdomains. Keywords, on the other hand, are checked against the full URL including path and query. This can be helpful but more easily generates false hits.

If an external URL database is used, the firewall checks this list for updates every 48 hours. This interval cannot be changed. For public blocklists, it is still advisable to check whether Setting Up and Securely Operating Sophos Firewall Threat Feeds is more appropriate.

A custom category doesn’t replace the Sophos default category for a URL. A URL can belong to multiple categories. The firewall evaluates categories in the order shown in the category list, and logs and reports show the category used for the policy decision. Retest a real request after changing entries or their order.

With Local database, no more than 2,000 entries are possible. A local .txt file contains one entry per line, while a .csv file contains comma-separated entries on one line. External URL database accepts a .txt, .csv, .tar, .gz, or .bz2 file available over HTTP or FTP, but it doesn’t support authentication to the source server. Invalid entries are ignored.

The external cache size depends on the firewall’s RAM. Sophos states that most models with more than 4 GB of RAM can cache up to 122,880 entries. Check the actual available limit in /log/nSXLd.log before using a large list in production.

Configure Web Policy

The menu path is:

Web > Policies

A web policy contains rules for users, groups, activities, categories, URL groups, file types, content filters, actions, and schedules.

Basic procedure:

1. Create a new web policy or edit an existing policy.
2. Add a rule.
3. Select users or groups if the policy is to be user-based.
4. Select categories or URL groups.
5. Set action for HTTP.
6. Check separate action for HTTPS.
7. Set schedule if necessary.
8. Under Advanced settings, turn on Enable logging and reporting if the policy should appear in logs and reports.
9. Activate rule status.
10. Check rule position.
11. Save.

Enable logging and reporting in the web policy and Log firewall traffic in the firewall rule serve different purposes. Check both deliberately when traceable evaluation is required.

The order within the web policy is crucial. Rules are evaluated from top to bottom. A broad allow rule above a specific block rule can result in the block rule never being applied.

If users are set in both the firewall rule and the web policy, the effect must be consciously tested. Users in firewall rules can take precedence over users in web policies. In case of unclear hits, it is advisable to check not only the web policy but also the firewall rule.

Activate Web Policy in Firewall Rule

The menu path is:

Rules and policies > Firewall rules > [Rule] > Security features > Web filtering

Basic procedure:

1. Open the relevant client or server rule.
2. Check source zone, source network, destination zone, and services.
3. Activate Log firewall traffic.
4. Under Web filtering, select the desired web policy.
5. Consciously activate or justifiably deactivate Block QUIC protocol.
6. Check malware scan and HTTPS scan settings.
7. Save.
8. Test with policy tester, log viewer, and real client traffic.

QUIC is a common disruptor for web filtering. When browsers communicate over UDP 443, logic and visibility do not always match the expectation of classic HTTPS over TCP. For details, see Correctly Blocking Sophos Firewall QUIC and HTTP/3.

If HTTPS content or full URL paths are relevant, web categorisation alone is not always sufficient. Then TLS inspection must be planned. This should not happen incidentally, as certificates, exceptions, data protection, performance, and support processes are affected. The rollout is described in Properly Introducing Sophos Firewall TLS Inspection.

Activate Instant Alerts

Instant alerts are activated at the category level.

The menu path is:

Web > Categories

Basic procedure:

1. Edit category.
2. Consciously select category for monitoring.
3. Activate Instant alerts.
4. Save.
5. Open System services > Notifications list.
6. Turn on Email notifications at the top.
7. Find Web – Instant alerts.
8. Select the checkbox under Email.
9. Check the mail server, sender, and recipients under Administration > Notification settings.
10. Generate a test request and check the next five-minute notification batch.

The firewall sends email notifications for monitored categories in batches every five minutes. This interval cannot be changed. An alert is therefore not a second-accurate real-time alarm but a quick email notification compared to purely downstream reports.

Instant Alerts are not available on XGS 87 and XGS 88. If the function is missing on one of these models, the email or notification configuration is therefore not necessarily faulty.

Instant alerts should only be activated for categories where a defined recipient can actually respond. A large alert list without responsibility usually leads to alert fatigue.

Analysis and Operation

Alerts are useful only if they are reviewed, classified and handled consistently in daily operation.

Data Protection and Internal Responsibility

Web category alerts can contain user, source IP, time, category, and depending on visibility, also target information. This is useful for security and operations but can raise employment law or data protection questions depending on the organisation.

Before productive use, it should therefore be clarified:

• Who is allowed to see web alerts?
• Which hits are only technically checked and which are treated as security incidents?
• How long are alert emails, reports, or SIEM events retained?
• Is the evaluation coordinated with HR, data protection, or internal policies?
• How to prevent individual harmless hits from being overinterpreted?

Technically, the setting is quickly activated. Operationally, however, it should be treated like a small monitoring process: recipient, purpose, response path, and retention must fit together.

Define Alert Triage

Instant alerts should not all be treated the same. A single category hit can be a harmless misclick, a misclassified service, a policy problem, or a real security incident. Therefore, it should be defined in advance which hits are checked immediately and which only go into the normal review.

A simple triage helps:

• High: Malware, phishing, command-and-control, exploit or spyware categories. Timely check log viewer, user, endpoint status, and other security logs.
• Medium: Anonymizer, proxy, file sharing, private cloud storage, or repeated policy circumvention. Check patterns, clarify user context, and refine policy.
• Low: Single grey areas without repetition. Include in reporting or weekly review, do not escalate immediately.
• False Alarm: Business-critical site misclassified. Check targeted URL group or category adjustment, do not set broad allow rule.

This classification should not only exist in an admin’s head. A short operational note is useful: monitored categories, recipients, response time, escalation path, allowed exceptions, and review date. This keeps it clear whether an alert should only be documented, technically corrected, or treated as an incident.

Use URL Category Lookup before the policy test

With an active Web Protection subscription, Diagnostics > URL category lookup shows which category Sophos assigns to a specific URL. Enter the complete test URL under Search URL and click Search. The result shows the category name and description. If the URL belongs to both a custom and a default category, the lookup shows the custom category.

The lookup confirms only the categorization. It does not prove which firewall rule or web policy a real client matches, whether an exception applies, or how TLS, QUIC, and the actual traffic path behave. Therefore, follow the lookup with Policy tester, a controlled client request, and evaluation in Log Viewer.

Testing and Evaluation

After each change, you should not only save but also check the effect.

Useful test steps:

1. Open Diagnostics > Tools > Pop-out tools > Policy tester. Web > Policies > Policy tester is an alternative shortcut to the same tool.
2. Enter the URL, user, time, source IP address, and source zone, then test Firewall, SSL/TLS, and web. Web policy only deliberately omits firewall rules.
3. On a test client, access a suitable website.
4. Open Log viewer.
5. Check web filter, firewall, SSL/TLS inspection, and application control logs.
6. In the firewall rule, check if the hit is on the expected rule.
7. For instant alerts, check the email inbox.
8. In Sophos Fusion (formerly Sophos Central) or SIEM, check if the events arrive there.

Policy tester models transparent web traffic and doesn’t account for SD-WAN routes, so it doesn’t replace a real packet flow. If a rule doesn’t match or TLS/QUIC changes the path, the difference often only becomes visible in Log Viewer or a packet capture. For such cases, see Testing Firewall Rules with Log Viewer, Policy Test, and Packet Capture.

For log file assignment, see Sophos Firewall Troubleshooting: Services and Logs. Among others, awarrenhttp.log, webproxy.log, and nSXLd.log are categorised for web and categorisation questions.

Define Response to Instant Alerts

An instant alert is only helpful if it is clear what should happen next. Otherwise, additional email traffic is generated, but no better security. Before activation, a simple response process should therefore be defined.

For each monitored category type, at least the following should be established:

• Who receives the alert? Prevents distribution without responsibility.
• How quickly must a response be made? Separates critical hits from mere follow-up.
• Which logs are checked? Log viewer, central reporting, syslog, or service logs provide different depths.
• When is a hit an incident? Not every category hit is automatically a security incident.
• Who can approve an exception? Prevents quick, broad allow rules without risk assessment.
• When is the category selection reviewed? Reduces alert fatigue through too broad alert sets.

A pragmatic process looks like this:

1. Record alert with user, source IP, category, URL or domain, and time.
2. In log viewer, check which firewall rule and web policy applied.
3. If available, use central reporting or SIEM for temporal classification.
4. Determine if it is an isolated case, a repeated pattern, or a false alarm.
5. For misclassification, only work specifically with URL group or category adjustment.
6. For noticeable patterns, evaluate user context, endpoint status, and other security logs.
7. Document decision: ignore, monitor, block, exception, incident.

For technical detail analysis, see Sophos Firewall Troubleshooting: Services and Logs, Enable Central Firewall Reporting, and Send Sophos Firewall Syslog to SIEM. If it is unclear whether the correct firewall rule was hit, see Testing Firewall Rules with Log Viewer, Policy Test, and Packet Capture.

Operational Recommendation

For productive environments, a three-stage model is sensible:

1. Block: Block malware, phishing, fraud, command-and-control, anonymizers, and other clearly risky categories.
2. Monitor: Equip a few sensitive categories with instant alerts.
3. Evaluate: Regularly check web reports, central reporting, or SIEM.

The most important boundary is organisational: An alert needs a recipient, a response time, and a decision on what happens with hits. Otherwise, instant alerts become just additional email noise.

Checklist

• Checked Web Protection licence.
• Identified relevant firewall rule.
• Created or adjusted web policy.
• Selected web policy in the firewall rule.
• Activated Log firewall traffic in the rule.
• Consciously decided on Block QUIC protocol.
• Consciously planned or deliberately not used TLS inspection.
• Defined critical categories.
• Activated instant alerts only for a few clear categories.
• Activated System services > Notifications list > Web – Instant alerts via email.
• Conducted test with policy tester.
• Conducted test with real client traffic.
• Checked log viewer.
• Checked central reporting or syslog if central evaluation is expected.
• Documented owner and response path for alerts.

Roll Back Changes Safely

Before making changes, record the current category status, web policy, and firewall-rule assignment. This allows a targeted rollback without disabling web filtering as a whole.

1. To stop only these notifications, turn off Instant alerts for the category under Web > Categories. Don’t turn off Email notifications globally if other system events use email.
2. If category entries or policy order changed, restore the recorded entries and positions.
3. If the firewall rule was assigned a different web policy, restore the previous policy under Rules and policies > Firewall rules > [Rule] > Security features > Web filtering.
4. Repeat the original Policy tester and client tests, then confirm the expected action in Log Viewer.

A notification generated before the rollback may still arrive in the next five-minute batch. The success criterion is that a new controlled request once again receives the recorded policy action. If you turned off Instant alerts, the request must not trigger another web instant-alert email.

Troubleshooting

If the expected result is missing, work through logging, rule matching and policy behaviour step by step.

Typical Errors

• Web policy does not apply: Policy is not selected in the firewall rule. Check firewall rule under Web filtering.
• Category is allowed although it should be blocked: Broad allow rule is above the block rule. Check order in web policy and firewall rules.
• No instant alert: The category isn’t monitored, Email notifications is off globally, or the event’s Email checkbox isn’t selected. Check Web > Categories, System services > Notifications list, then Administration > Notification settings.
• No user information in log: User not recognised or rule does not match user-based. Check authentication, STAS, captive portal, or clientless user.
• HTTPS unexpectedly allowed: No suitable TLS inspection or HTTPS action. Check web policy, SSL/TLS inspection rules, and decryption.
• Web filter seems incomplete: QUIC or incorrect traffic path. Check Block QUIC protocol, services, and log viewer.
• Too many alerts: Categories chosen too broadly. Reduce alert list and assign owner.
• Domain missing in log/report: Particularly critical category is anonymised. Check category and Sophos behaviour.

Sophos blocks websites in the highly objectionable criminal activity category by default and hides the domain name in logs and reports. If an entry in this area appears anonymised, this may be intentional.

Frequently Asked Questions