Using Sophos Firewall Web Categories and Instant Alerts

Web categories on the Sophos Firewall are more than just a simple web filter for unwanted websites. When used correctly, they help limit risky browsing behaviour, accurately log categories, and respond more quickly to critical access.

With instant alerts, the firewall can send email notifications for selected web categories. This is particularly useful in schools, sensitive corporate areas, or environments where certain web accesses should not only be noticed in the monthly report.

Expectations are important: web categories, URL groups, web policies, TLS inspection, QUIC handling, logging, and reports must align. If only one category is activated but the web policy is not used in a firewall rule, nothing happens in productive traffic.

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.

Clearly Distinguish Terms

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

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.
• The appropriate log types are activated under System services > Log settings.
• Email notifications work if instant alerts are to be used.
• For long-term evaluation, Sophos 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 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.

URL groups are often more performant and less prone to false positives for pure domain matches than categories with keywords. Keyword categories should therefore be used sparingly, especially for allow rules.

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.

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.

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.

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. Activate rule status.
9. Check rule position.
10. Save.

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. Search for Web - Instant alerts.
7. Activate checkbox under Email.
8. Check mail delivery and recipients.
9. Generate test access and check notification.

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 should only be activated for categories where a defined recipient can actually respond. A large alert list without responsibility usually leads to alert fatigue.

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:

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.

Testing and Evaluation

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

Useful test steps:

1. Open Web > Policies > Policy tester.
2. Test user, URL, and policy.
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 Central or SIEM, check if the events arrive there.

The policy tester is helpful but does not replace real packet flow. If a rule does not match, an SD-WAN route decides differently, or TLS/QUIC changes the path, this is often only seen in the log viewer or 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.

Typical Errors

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.

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:

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.

Frequently Asked Questions