Configure Sophos Firewall ATP: X-Ops Threat Feeds

The former Advanced Threat Protection (ATP) is called Sophos X-Ops Threat Feeds in SFOS 22. The firewall compares outgoing traffic with a Sophos-maintained database of known malicious IP addresses, domains, and URLs. This can, for example, prevent an infected client from reaching a known command-and-control server.

A threat feed is a continuously updated list of these indicators, known as IoCs (Indicators of Compromise). X-Ops receives the global SophosLabs database automatically; no custom feed URL is entered. Under Active Threat Response, you can configure one or more modules: MDR Threat Feeds provide information from MDR analysts about active threats in your own network; NDR Essentials analyzes firewall traffic using machine learning, evaluates detected IoCs, and logs them. With Third-Party Threat Feeds, by contrast, you enter your own feed URLs. An active X-Ops module does not automatically enable the other modules.

For production use, Log and drop is the goal. The feature is disabled by default and only blocks traffic after it is enabled if this action is selected.

Set up X-Ops Threat Feeds

The X-Ops module requires Network Protection. Implementing threat-feed inspection additionally requires Web Protection. Both licences are included in the Standard and Xstream Protection bundles or can be licensed separately; X-Ops does not require an additional Sophos Fusion (formerly Sophos Central) licence.

Before making changes, document the firmware build, licenses, current Action, inspection scope, log destinations, and exceptions. Synchronized Security also requires an Intercept X license in Sophos Fusion or Sophos Central; the X-Ops license alone does not provide endpoint integration. Also check whether firewall rules respond to a red Security Heartbeat: the status change documented in SFOS 23 may then affect the endpoint’s access in addition to the individual blocked connection.

Open System services > Log settings.
In the Active threat response row, enable at least Local reporting. Depending on the operating model, also select the required syslog destination and Central reporting. On the Log settings page, save the log destinations supported on this model with Apply. Reload the page and confirm that the selected destinations are still set before moving to the X-Ops configuration. Local event logs are not the same as on-box reporting; alternatives for models without local reporting are listed below.
Open Protect > Active threat response > Sophos X-Ops threat feeds.
Enable Sophos X-Ops threat feeds.
Under Action, select either Log only for a short, controlled pilot or Log and drop for production protection.
SFOS 23: Log only logs the event without changing the endpoint’s Security Heartbeat status. Log and drop logs the event, blocks the threat, and sets the endpoint’s Security Heartbeat status to red.
Under Advanced security settings, choose between Inspect untrusted content and Inspect all content.
Save with Apply.
Then check the setting, log destinations, and existing exclusions.

XGS 87/87w and 88/88w do not support local reporting. On these models, use Central Reporting or a syslog server instead. The Central reporting column only appears after Send reports and logs to Sophos Central has been enabled under Sophos Fusion (formerly Sophos Central).

Sophos recommends blocking known IoCs rather than only logging them. For a new or previously unmonitored environment, Log only can still be useful for a short, clearly time-limited observation phase. This phase needs an owner and a switch-over date; otherwise, the feature can easily remain permanently active without blocking.

What X-Ops protects – and what it does not

X-Ops checks known malicious destinations in outgoing forwarded traffic. A typical hit occurs when a client or server attempts to access a known malware, phishing, or C2 IP address, domain, or URL. Depending on the action, the attempt is either logged or dropped immediately.

The overview and the X-Ops description are not fully consistent: The traffic matrix in the SFOS 22/23 overview marks Destination Match as unsupported for X-Ops, but local Source Match as supported. The X-Ops configuration section, however, describes matching malicious IP addresses, domains, and URLs, which is the basis for destination inspection in this article. This contradictory matrix provides neither a guarantee for all forwarded destinations nor a reliable basis for asserting local Source Match coverage. Confirmation for the deployed build is needed to establish this scope before replacing existing protection rules. The matrix consistently shows no X-Ops protection for remote sources with DNAT/WAF or for sources of system-destined traffic to WebAdmin, VPN Portal, or VPN. Restrictive firewall, WAF, and Device Access rules remain necessary for these services; alternative feeds are discussed in the article on Third-Party Threat Feeds.

IPS, malware scanning, and Zero-Day Protection also perform different tasks. X-Ops is indicator-based: a destination must already be known as a malicious IoC. IPS, by contrast, detects known attack patterns in traffic. The two features complement each other but do not replace one another.

Active Threat Response checks modules in this order: MDR, NDR Essentials, Sophos X-Ops, then Third-Party Threat Feeds. If an earlier module blocks the same IoC, the firewall stops checking. A missing X-Ops log entry therefore does not automatically mean that no protection took effect. The Third-Party Threat Feeds guide explains the order and overlapping indicators in more detail.

Requirements for a match

Activation alone does not guarantee that the firewall can see every IP, domain, or URL indicator. The information visible in the relevant network path is decisive.

IP addresses

For a destination IP match, outgoing traffic must pass through a suitable firewall rule. The firewall can compare the destination address directly with the X-Ops feed; TLS decryption is not required.

Domains

For domain detection, the required IPS-related settings must be effective: Application Classification must be enabled, or an IPS policy must be selected in the relevant firewall rule. According to the documentation, Application Classification is enabled by default; nevertheless, verify its actual state. It should not be understood here as an additional toggle in every firewall rule. This requirement applies particularly to HTTPS and DNS queries to external resolvers over HTTP or HTTPS. If the required classification is missing, domain matching may not take place in the affected traffic path.

If the firewall answers client DNS requests itself, the DNS module performs the domain match. If clients use an external resolver, that DNS path must also pass through the firewall and be visible with the required IPS-related settings. When a domain match is missing, check the resolver path actually in use, not only the client rule to the web destination.

Full URLs over HTTPS

A URL includes not only the domain but also a path, for example https://example.invalid/download/payload.exe. With encrypted HTTPS traffic, the firewall normally sees only the domain through SNI without decryption, not the path /download/payload.exe.

Checking the full URL indicator requires Web Proxy with HTTPS decryption enabled or a suitable SSL/TLS inspection rule with Decrypt. TLS Inspection should not be enabled globally without control solely for X-Ops: certificate distribution, privacy, exclusions, application compatibility, and performance belong in a dedicated rollout.

For the Web Proxy, select Use web proxy instead of DPI engine and Decrypt HTTPS during web proxy filtering under Web filtering in the appropriate firewall rule. For the DPI path, leave Use web proxy instead of DPI engine disabled; configure the appropriate decryption rule under Rules and policies > SSL/TLS inspection rules with Action set to Decrypt. Both paths also require the classification prerequisites mentioned above for full HTTPS URL inspection. Change only the approved traffic path, then check certificate trust, the normal business workflow, and the rule actually matched in the Log Viewer.

Choose the inspection scope deliberately

Under Advanced security settings, the scope of traffic inspected by X-Ops is defined:

Inspect untrusted content limits inspection to traffic with untrusted sources or destinations. This setting requires fewer resources and is a sensible starting point when load and side effects are not yet known.
Inspect all content inspects both trusted and untrusted traffic. This provides broader coverage but can affect performance, particularly in heavily loaded environments.

For especially sensitive client, server, or administration networks, Inspect all content can be useful if the appliance has sufficient capacity. The change should be made during a maintenance window. CPU utilisation, latency, throughput, and helpdesk feedback are then compared with the previous state.

The documentation describes the performance difference between the two inspection scopes as generally small, but potentially significant under high traffic loads. Record the current value before switching. If the comparison shows a meaningful deterioration, restore the previous inspection scope under Advanced security settings, save with Apply, and check the business workflow, load, and logging again. This does not require disabling the blocking action across the board.

Action and inspection scope should not be changed several times simultaneously during an introduction. Changing visibility first and the blocking action afterwards makes it easier to determine which setting caused a problem.

Check effectiveness and logging

After saving, the administrator should not only check whether the switch is active. A reliable operational check covers three levels:

Configuration: X-Ops is enabled, and the required action and inspection scope are saved.
Visibility: The firewall rule, Application Classification or IPS, and TLS decryption for full HTTPS URLs match the indicator type.
Evidence: Hits can be found under Log viewer > Active threat response or in the configured Central or syslog destination.

For a local summary, open Reports > Network & threats > Active threat response. The widget of the same name in the Control Center provides an overview of affected hosts and threat events. MDR and X-Ops show status and blocked threats; NDR Essentials shows status and monitored threats; Third-Party Threat Feeds also shows configured feeds and their synchronization status. Configure opens the configuration, Reports opens the reports, and More details expands the widget view. On devices without local reporting, the Reports button is absent; use the configured Central or Syslog destinations instead. An NDR count of monitored threats is not evidence of blocking. Check the specific action and connection details in the report or Log Viewer. For Third-Party Threat Feeds, the widget also shows the number of threats blocked by these feeds.

The technical syslog log type remains ATP, although the interface now uses X-Ops and Active Threat Response. Depending on the processing path, log_component can show Firewall, DNS, IPS, or Web. For an investigation, timestamp, action, source, destination, ports, domain or URL, threat name, feed name, and event ID are particularly useful.

In the Advanced Shell, ips.log is the most important engine log for Active Threat Response. garner.log helps with event processing and forwarding, especially when Central Reporting appears incomplete. These files and secure SSH access are explained in the overview of Sophos Firewall services and log files.

There is no generally documented harmless X-Ops test indicator. A real malware domain or known malicious IP address should therefore not be accessed deliberately. If a reproducible functional test is required, a dedicated Third-Party pilot feed with a controlled test destination is the safer method. For X-Ops itself, configuration and visibility are checked; the next genuine, carefully investigated hit confirms the actual blocking effect.

When an IoC is not blocked or no X-Ops log appears

Start with the specific indicator type and the actual traffic path. This avoids broad exclusions or global TLS changes made on suspicion:

Under Protect > Active threat response > Sophos X-Ops threat feeds, confirm that X-Ops is enabled and Action is actually set to Log and drop. Log only only creates an entry.
In Log viewer > Active threat response, check the module, actual action and connection details for the same IoC. Only an evidenced blocking action by an earlier module, such as MDR with Log and drop, stops further checks before X-Ops. NDR Essentials detects and logs threats with Log threats, but does not block them. A monitored NDR event alone does not stop the X-Ops check or explain a missing X-Ops log entry.
For destination IP addresses, check the LAN-to-WAN firewall rule that actually matches. For domains, also check Application Classification, the IPS policy, and the resolver path.
For full HTTPS URLs, search for the server name in Log viewer > SSL/TLS inspection. If the matching SSL/TLS rule shows Don't decrypt, X-Ops cannot see the URL path. Plan the narrowest possible Decrypt rule only after identifying that rule.
Search for the domain or URL in Log viewer > Web filter; also check the Category column and the detail view. These identify the firewall rule ID and the selected web policy. If the responsible Web policy shows Allow, check the rule and policy order. For a confirmed malicious domain or URL, you can use a narrowly scoped URL group with a web policy action of Block in an appropriate LAN-to-WAN rule above the rule that previously allowed it. For the web proxy path, also check Web > Exceptions: URL pattern matches, Web categories, Destination IP addresses, and Source IP addresses may match the indicator or the requesting endpoint. For the DPI path, check the SSL/TLS Exclusion Lists. Do not remove an exception indiscriminately; first clarify its purpose, the affected business workflow, and approval.
Under Protect > Active threat response > Add threat exclusions, look for both the IoC and the requesting host or network. These exclusions apply across modules.

After each correction, repeat the same business process and check the relevant logs. If the cause remains unclear, save the timestamp, firewall rule ID, web or SSL/TLS rule ID, and the detailed Active Threat Response event for the support case.

Investigate an X-Ops alert

A blocked IoC is a strong signal but not a complete incident analysis. The destination may have been contacted by malware, a phishing link, a compromised browser extension, or a legitimate but incorrectly classified service.

A sensible process is:

Save the timestamp, firewall or HA node, action, and complete log details.
Record the source IP, destination IP, domain or URL, ports, protocol, threat name, and feed name.
Correlate firewall, DNS, IPS, and web logs within the same time window.
Identify the internal client using the DHCP lease, user mapping, or endpoint data.
Search the affected system for the related process, browser history, download, and additional security events.
If compromise is confirmed, isolate the system and handle it according to the internal incident response runbook.
Only after analysis, decide whether remediation, an additional block, or a narrowly scoped exclusion is required.

With Synchronized Security, supported Windows endpoints can also show the process user, endpoint ID, and execution path. These process details are not available on macOS; the source IP therefore remains particularly important for attribution.

Known HA false positive `NC-170292`

On an HA system with SFOS 21.5.1 MR1 Build 261, NC-170292 can trigger a false Advanced threat detected alert with raw logs in Sophos Fusion. An email from the firewall may arrive at the same time without useful details.

This limitation does not generally apply to other builds or standalone firewalls. An alert should therefore first be saved and investigated as described above. If the system matches the affected build exactly and no reliable hit details are available, Sophos names restarting the Garner service as a temporary workaround. Because the Known Issues list does not provide a specific CLI command for this issue, the restart should only be performed through an approved support or maintenance procedure. For recurring alerts, the HA status, firmware build, timestamp, and garner.log belong in the Sophos Support case.

Add exclusions only after confirmed analysis

Under Protect > Active threat response > Add threat exclusions, Host and network exclusions and Threat exclusions can be created for IP addresses, domains, or URLs. A Threat exclusions entry can contain up to 128 characters. Such an exclusion applies not only to X-Ops but to all Active Threat Response modules. A quick exclusion can therefore also weaken protection from MDR, NDR, or Third-Party Threat Feeds.

If a false positive is confirmed, only the smallest required indicator should be excluded. The exclusion should include a reason, ticket, owner, and review date. Excluding entire client networks or broad domain ranges as a precaution may remove the visible alert, but also removes a large part of the protection.

For an approved exclusion, open Protect > Active threat response > Add threat exclusions and use one of the following alternatives depending on the exclusion type:

Hosts or networks: Under Host and network exclusions, click Add new item and select only the approved host or network objects.
Threat indicator: Instead, under Threat exclusions, enter the approved IP address, domain or URL and use Add to add it to the list. Observe the limit of 128 characters per entry.

Then save with Apply. Reopen the page and check that only the intended entries have been saved. Add new item or Add alone does not replace this final save step.

After the change, the same business process is tested again, and the Log Viewer is checked to ensure that only the intended hit is absent. Other X-Ops events must continue to be logged or blocked.

To roll back, only the most recent change is undone: the inspection scope is set to the documented previous value and saved with Apply; a newly created Web/SSL/TLS rule or exception is specifically reverted without changing existing rules or other exceptions. The business process, the rule that actually matches, and the logs are then checked again. If an exception is reverted, the corresponding match may be blocked again. If Log only is temporarily required due to an operational disruption, X-Ops blocking is suspended during that time; the responsible parties and an end time are specified, and Log and drop is restored once the cause has been clarified. A disabled module is not an equivalent rollback, as its inspection is also disabled. A controlled test with a dedicated pilot feed under Third-Party Threat Feeds verifies only that feed’s traffic path, not X-Ops database delivery or matching.

XML API: treat activation, action and exclusions separately

When automating X-Ops, distinguish three independent settings in the documented XML object ATP. The SFOS-22/23 API reference describes:

ATP/ThreatProtectionStatus: a scalar module switch with Enable or Disable. It enables or disables X-Ops; it is neither the action on a match nor an individual exclusion.
ATP/Policy: the scalar action on a match. The parameter table lists Log Only and Log and Drop, gives Log Only as the default and marks the field as required when X-Ops is enabled. This is information from the API table, not evidence of the saved state on your own firewall.
ATP/InspectContent: a scalar inspection scope with all or untrusted. A different inspection scope is not equivalent to Disable or a change to the action on a match.
ATP/HostException/Host: an array of strings for source hosts or source networks to exclude. The example contains HostName; an entry requires the approved object reference from your own configuration.
ATP/ThreatException/Threat: a separate array of strings for destination indicators to exclude. The API table lists destination IP addresses and domains. The URL entry in the interface described above does not, by itself, establish XML payload syntax for URLs.

The two exclusion arrays are therefore nested under different parents and can contain multiple entries. They are not global disable switches. The API table describes their effect on X-Ops, MDR and Third-Party Threat Feeds; the broader cross-module warning and approval rules in the exclusions section therefore remain important.

Resolve the Policy conflict before sending a write request: The XML example uses the text alert/drop for Policy, whereas the parameter table lists Log Only and Log and Drop. These forms are not silently converted into one another; the wording of the UI labels is not proof of a valid API value either. Before automating, confirm the specific value and request structure using the API help for the installed build or with Sophos Support. Until then, the example is not a ready-to-copy request verified to work.

Secure XML API setup is covered separately. Before an approved change, back up the module status, action, inspection scope and both exclusion arrays. Afterwards, read back the actual saved state or open the configuration page and compare these five areas individually. If an error occurs, check the saved state before retrying; an exclusion or a different inspection scope must not inadvertently become a global deactivation.