Configure Sophos Firewall ATP: X-Ops Threat Feeds

The former Advanced Threat Protection (ATP) is called Sophos X-Ops Threat Feeds in current SFOS versions. 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.

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

Before activation, Network Protection and Web Protection must be licensed. Both features are included in the Standard and Xstream Protection bundles; X-Ops does not require an additional Sophos Central licence.

1. Open System services > Log settings.
2. 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.
3. Open Protect > Active threat response > Sophos X-Ops threat feeds.
4. Enable Sophos X-Ops threat feeds.
5. Under Action, select either Log only for a short, controlled pilot or Log and drop for production protection.
6. Under Advanced security settings, choose between Inspect untrusted content and Inspect all content.
7. Save with Apply.
8. Then check the setting, log destinations, and existing exclusions.

XGS 87/87w and 107/107w 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 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.

X-Ops does not support local or remote source matches. It therefore does not automatically block known attacker IP addresses that access a DNAT or WAF publication, WebAdmin, or a VPN portal as a source. For these use cases, MDR, NDR, Third-Party Threat Feeds, and restrictive firewall, WAF, and Device Access rules are more suitable.

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.

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, Application Classification must be active in the affected firewall rule or an IPS policy must be selected. If both are absent, the necessary classification may not take place in that traffic path.

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.

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.

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:

1. Configuration: X-Ops is enabled, and the required action and inspection scope are saved.
2. Visibility: The firewall rule, Application Classification or IPS, and TLS decryption for full HTTPS URLs match the indicator type.
3. 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 shows the status and number of blocked threats; check the specific action and connection details in the report or Log Viewer.

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.

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:

1. Save the timestamp, firewall or HA node, action, and complete log details.
2. Record the source IP, destination IP, domain or URL, ports, protocol, threat name, and feed name.
3. Correlate firewall, DNS, IPS, and web logs within the same time window.
4. Identify the internal client using the DHCP lease, user mapping, or endpoint data.
5. Search the affected system for the related process, browser history, download, and additional security events.
6. If compromise is confirmed, isolate the system and handle it according to the internal incident response runbook.
7. 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 Central. 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. 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.

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.