Enable and verify Sophos Firewall MDR threat feeds

MDR threat feeds connect the Sophos MDR service to Sophos Firewall. MDR analysts can send IPv4 addresses, domains, and URLs related to an active incident in your environment to the firewall through Sophos Fusion (formerly Sophos Central). The firewall then logs or blocks matching traffic without requiring a manually maintained feed file.

A safe rollout requires more than enabling a switch in WebAdmin. The MDR licence, Sophos Fusion registration, local action, required traffic visibility, log destinations, and contact path to the MDR team must all align. A local Log and drop status does not yet prove that a specific IoC has arrived or that an affected traffic flow passes through the required inspections.

Interface labels: The Sophos Fusion paths used here follow the SFOS 22 help. The SFOS 23 help still uses Sophos Central for the same cloud integration. If your build shows this label, open the corresponding Sophos Central page; the name alone tells you nothing about registration, MDR entitlement, or feed delivery. Send reports and logs to Sophos Central remains the documented name of the logging option.

MDR threat feeds in eight steps

1. Verify that the firewall has an active Xstream Protection Bundle and Sophos Fusion has an active MDR entitlement.
2. Under System > Sophos Fusion, confirm that the correct firewall is registered with the correct Sophos Fusion account.
3. Document the intended Threat response mode and the operational MDR contact path in Sophos Fusion.
4. Under System services > Log settings, enable at least one usable log destination for Active threat response.
5. Open Protect > Active threat response > MDR threat feeds and turn on the feature.
6. Select Log only for a short controlled pilot or Log and drop for production protection after successful acceptance testing, then click Apply.
7. Perform positive and negative checks using Log Viewer, endpoint context, and Sophos Fusion.
8. Document the audit ID, responsible parties, exception process, review date, and rollback.

Important: MDR threat feeds are only one part of MDR operations. They do not replace the MDR contract, endpoint sensors, incident communications, restrictive firewall rules, or a tested recovery process. A broad exception or uncontrolled deactivation can weaken an ongoing response by the MDR team.

What MDR threat feeds do

Sophos MDR analysts can send intelligence about an active incident directly to the firewall through Sophos Fusion. The feed is therefore more customer-specific than a general global reputation list. A delivered IoC can be an IPv4 address, domain, or URL.

The local firewall action determines what happens when a match occurs:

• Log only logs the match but allows the traffic.
• Log and drop logs and drops the matching traffic.

Sophos recommends blocking known IoCs. A short Log only pilot can nevertheless be useful when an existing environment first needs to check visibility, logging, and possible side effects. This pilot needs a fixed end date. Without a planned transition, an active MDR integration could otherwise remain permanently without local blocking.

The Threat response mode in Sophos Fusion and the local feed action are two different layers. The Sophos Fusion mode defines the response authority granted to the MDR team. Log only or Log and drop determines how the firewall handles an IoC that has already been delivered. Before rollout, both settings are checked against the MDR contract and the internal incident process. The current Sophos documentation on Threat response mode distinguishes between Collaborate, Authorize, and Notify Only.

Distinguish firewall telemetry from analyst response

Data also flows in the other direction: the firewall supplies security events for MDR investigations. For this, it must be registered with Sophos Central firewall management; Sophos Central services must be enabled on the firewall and Send reports and logs to Sophos Central must be selected. MDR continuously analyses security logs from Advanced Threat Protection (ATP), Intrusion Detection and Prevention (IDP/IPS), Antivirus, Antispam, Sandstorm Sandbox, Web Protection, and Application Control. Together with data from endpoints, servers, and other integrated sources, these events help identify malicious activity, IoCs, and attempts at lateral movement. Incoming firewall telemetry is not, however, the customer-specific IoC feed that MDR analysts send back to the firewall.

During a critical incident, the MDR team can, for example, terminate the VPN sessions of compromised users. This is an incident response action performed by analysts within the authority granted to them, not an automatic consequence of a feed match or a local click-by-click or CLI procedure. With Authorize, the team can respond to active threats without first consulting the designated contacts; with Collaborate, the response is coordinated with those contacts. This does not imply unrestricted response authority for all devices or integrations. Production VPN sessions are not terminated as a functional test.

Actions through Live Response require Live Response to be permitted on the device concerned. Isolate Sophos Endpoint and investigate with Live Response explains the prerequisites and safe procedure. Microsoft 365 actions such as blocking or allowing sign-ins, revoking active sessions, and disabling Inbox Rules require the response integration to be set up; follow the separate procedure in MDR and XDR integrations. Firewall logging or a delivered MDR IoC does not automatically enable these actions.

The cybora.io Threat Feeds used by Avanet for Sophos Firewall, by contrast, are Third-Party Threat Feeds, not Sophos MDR Threat Feeds or MDR feeds created by Avanet. Their setup follows the Third-Party feed procedure; it does not grant the Sophos MDR team any additional response authority.

Understand processing order and lifecycle

SFOS 22 processes Active Threat Response in the order MDR, NDR Essentials, Sophos X-Ops, and Third-Party Threat Feeds. If an IoC matches MDR with Log and drop, the firewall drops the traffic, logs it under MDR, and does not check the subsequent feeds. With Log only or Monitor, separate events can be generated for MDR, X-Ops, and Third-Party Feeds. For Log only or mixed module actions, do not infer a general allow exemption; consider the other configured actions and verify traffic and log evidence.

Individual MDR IoCs are not created or edited in WebAdmin. MDR analysts add and remove them through Sophos Fusion. Both operations are logged with the action and analyst identity as audit_ID. Look for these management events in the Admin detail view of Log Viewer or in the Sophos Fusion Firewall Task Queue; do not confuse them with traffic matches under Active threat response. Locally, you only control whether the MDR feed is active and whether matches are logged or also dropped. Threat Exclusions, by contrast, are global and apply to all Active Threat Response modules.

The SFOS 22 documentation does not specify an administrator-configurable validity period for MDR IoCs. You must therefore not infer an expiry date from the local interface. If an entry is questionable or potentially outdated, capture the audit_ID, IoC, and timestamp, and clarify its status with the MDR team. This also matters when reverting changes: switching from Log and drop to Log only affects all currently delivered MDR IoCs; a Threat Exclusion can additionally weaken NDR, X-Ops, and Third-Party Feeds.

Check the prerequisites thoroughly

Licensing and Sophos Fusion

MDR threat feeds require the Xstream Protection Bundle on the firewall. The SFOS 22 licensing table additionally lists Sophos MDR Essentials or Sophos MDR Complete in Sophos Fusion; the current Sophos Fusion documentation calls the service variants MDR and MDR Plus. Check the active MDR entitlement in your Sophos Fusion account rather than assuming entitlement solely from an old product name. The Xstream bundle alone does not include an MDR service.

The firewall must be registered in the correct Sophos Fusion account. Under System > Sophos Fusion, check registration and the forwarding of reports and logs. Connect Sophos Firewall to Sophos Fusion explains the complete connection process.

The Sophos MDR service must also be set up. Firewall registration and licence checks alone do not replace this setup. Before enabling the feature locally, confirm with the person responsible for MDR that the service is set up for the correct customer and that the Threat response mode has been deliberately selected. Sophos requires at least one authorised contact before further MDR settings can be configured or the service can be used. For additional endpoint context through Synchronized Security, the SFOS 22 licensing table also lists an Intercept X licence in Sophos Fusion; the Xstream bundle alone does not guarantee this context.

Sophos MDR: configure contacts and Threat Response describes the complete central procedure, including contact roles, the Collaborate fallback, device access and safe verification of saved values. It does not replace the subsequent local feed configuration.

Responsibilities must also be clarified before activation:

• Who may change the Threat response mode in Sophos Fusion?
• Who answers an MDR call or enquiry outside office hours?
• Who may approve an exception?
• Where are the audit ID, incident ID, and technical evidence documented?
• Which systems may be isolated if compromise is confirmed?

Enable log destinations

Under System services > Log settings, enable at least one of these destinations in the Active threat response row:

• Local reporting for Log Viewer and local reports
• A configured Syslog server for the SIEM or SOC
• Central reporting for Sophos Fusion

The Central reporting column only appears when Send reports and logs to Sophos Central is enabled on the Sophos Fusion page. XGS 87/87w and 107/107w do not support local reporting; these models require Central Reporting or Syslog.

After selecting the log destinations under System services > Log settings, click Apply. Then reload the page and check that the intended destinations remain selected in the Active threat response row. This confirms the saved configuration; actual log transport and delivery of incident notifications are checked separately.

For notifications, also check System services > Notification list. Enabling a log destination defines the transport path, but proves neither actual delivery nor correct alert handling.

Visibility for IP addresses, domains, and URLs

An IoC only affects traffic that the firewall can process appropriately. Forwarded destination-IP traffic requires a matching firewall rule. Domain matches require Application Classification or an IPS policy in the relevant rule. A full HTTPS URL path requires Web Proxy with decryption or DPI with an appropriate SSL/TLS inspection rule.

Traffic directed at the system itself, to services under Administration > Device access, such as WebAdmin, VPN Portal, and VPN, can be checked against a malicious source IPv4 address. For incoming forwarded DNAT or WAF traffic, Remote source match (inbound traffic) must also be enabled under System services > Log settings > Active threat response to provide the expected log visibility.

Unresolved limitation for ATR/X-Ops: The official description and the traffic matrix contradict each other regarding destination-address and local source-address matches for Sophos X-Ops. Neither support nor exclusion has been reliably established for these cases; the linked traffic/module information is not an approved basis for configuring them. No MDR traffic direction is inferred from this, and no protection is assumed for the affected X-Ops cases. Before making a change based on this behaviour, obtain definitive clarification from Sophos or conduct an explicitly approved product test; the following links do not resolve this contradiction.

The general traffic, module, and inspection logic is covered in Set up and safely operate Sophos Firewall threat feeds. It also explains why domain or URL detection may not occur without the appropriate classification or decryption.

Configure MDR threat feeds

1. Sign in to WebAdmin with a personal administrator account.
2. Open Protect > Active threat response > MDR threat feeds.
3. Turn on MDR threat feeds.
4. For Action, select Log only for a time-limited pilot or Log and drop after successful acceptance testing.
5. Save with Apply.
6. Reload the page and check that the switch setting and Action have been saved.
7. Check the timestamp, administrator, and change in the audit trail.
8. In Sophos Fusion, check that the firewall is online and MDR is assigned to the correct customer or tenant.

Do not make widespread changes to logging, inspection, exceptions, and Action simultaneously. A staged rollout makes it clear which change caused a match or a side effect.

Verify effectiveness with reliable evidence

Accessing a real malware domain or known malicious IP is therefore not a suitable acceptance test. Technical verification is divided into several independently verifiable layers. A test using your own Third-Party feed only demonstrates the traffic and inspection path tested, not delivery of an MDR IoC by the analyst team.

Configuration and transport

1. Check the MDR switch and desired Action on the firewall.
2. Check Sophos Fusion registration and the MDR licence.
3. Confirm Active Threat Response logging for the expected destination.
4. In Sophos Fusion, check whether MDR or firewall tasks have been processed successfully.
5. During a real MDR incident, confirm the expected IoC and its associated audit ID with the MDR team.

The Sophos Fusion Firewall Task Queue shows MDR and API tasks. Success confirms processing of the Sophos Fusion task, but not yet its effect on a specific traffic flow. For Partial Success or Failed, capture the affected firewall, Entity, Action, and Credential ID, and compare them with the local configuration.

Investigate matches in Log Viewer

Under Log viewer > Active threat response, capture at least the following information:

• Timestamp, firewall, and, for HA, the node that processed the traffic
• Action and feed name
• Source and destination IP, domain, or URL
• Ports and protocol
• Event ID and other detail fields
• For MDR, also the associated audit_ID from the management event or Task Queue

Traffic evidence and the analyst action are separate pieces of evidence. A missing audit_ID field in the traffic entry is not, by itself, a delivery error. Correlate them using the IoC, firewall, and time window, and confirm with MDR if anything is unclear.

With Synchronized Security, the firewall can also show the user, host, and process for managed Windows endpoints. Relevant fields in Log Viewer are Process user and Executable, along with host_process_user, endpoint_id, and execution_path in the detail view. These process details do not appear on macOS; identify the endpoint using the source IP and Sophos Fusion data instead.

When a detection occurs, the firewall queries the endpoints managed through Sophos Fusion for these details. The help describes this display for Windows 7 and later; this is not a recommendation to use Windows 7 or a guarantee of current endpoint support for every older Windows system. On macOS, a generic message such as Active threat C2/Generic-C deleted may appear instead. It replaces neither host identification through the source IP nor evidence of which firewall action was applied to the traffic.

The local summary is under Reports > Network & threats > Active threat response in the Synchronized IoC list. The Overview of Sophos Firewall services and log files also explains the role of atr.log. Never assess a single log entry in isolation: firewall, DNS, web, IPS, endpoint, and Sophos Fusion events from the same time window must be considered together.

Positive and negative checks

A production pilot should include at least these two cases:

1. Positive: For a real IoC or incident confirmed by the MDR team, separately capture a traceable traffic entry with the correct Action and the associated analyst action with its audit ID, then correlate them. Do not generate additional traffic to malicious infrastructure for this purpose.
2. Negative: A comparable legitimate business process remains accessible and does not trigger an unintended MDR block.

Do not artificially create an MDR IoC in the absence of a real incident. Instead, check configuration, task processing, log transport, and the communication path. For a fully controllable traffic test, your own Third-Party pilot feed is more suitable than an external malicious destination.

Treat MDR matches as incidents

An MDR match is a strong signal, but the log entry alone does not explain the complete attack path. A measured procedure is:

1. Capture the timestamp, Action, IoC, feed name, event ID, and audit_ID.
2. Identify the affected host and user using the source IP, DHCP, Synchronized Security, and endpoint data.
3. In Sophos Fusion, open the associated MDR case, detection, and other device events.
4. Correlate firewall, DNS, web, IPS, and endpoint logs within the same time window.
5. Clarify with the MDR team why the IoC was added and what response is intended.
6. If compromise is confirmed, initiate the internal incident response process.
7. Only then decide on remediation, additional rules, or a narrowly scoped exception.

The audit ID identifies the MDR analyst action. In Log Viewer, first click the button for the detail view, then select Admin from the dropdown. Capture the action and audit_ID for the addition or removal there. Alternatively, the analyst action is available under My Products > Firewall management > Tasks Queue in Sophos Fusion. When contacting MDR, include the audit ID in the case together with the firewall serial number, timestamp, IoC, event ID, and incident ID. A logged removal proves a management action, not remediation of the affected endpoint.

Manage exceptions in a controlled way

Under Protect > Active threat response > Add threat exclusions, you can create host/network and threat exclusions. These exclusions apply across modules. An exception for an MDR match can therefore also weaken X-Ops, NDR, or Third-Party Threat Feeds.

Before creating an exception, document the IoC, affected business process, MDR case, and false-positive confirmation. Keep the exception as narrow as possible and assign a reason, owner, ticket, and review or expiry date. Entire client networks or broad domain ranges are not suitable quick fixes.

Threat feed configurations cannot be imported or exported separately; Threat Exclusions can. MDR feed settings also cannot be transferred into the initial configuration of a new Sophos Fusion firewall group through Import existing configuration. After migration, restoration, or replacement, explicitly recheck the feature, Action, logging, and Sophos Fusion assignment.

If no MDR match appears

Do not start troubleshooting with a service restart. First, check the layers separately:

1. Are the MDR licence, Sophos Fusion account, firewall registration, and Threat response mode correct?
2. Are MDR threat feeds enabled locally, and has the Action been saved?
3. Has the MDR team actually delivered the relevant IoC for this environment?
4. Does the Sophos Fusion Firewall Task Queue show Success, Partial Success, Failed, or still Pending?
5. Are Active Threat Response logs enabled locally, for Syslog, or in Sophos Fusion?
6. Does the traffic pass through the expected firewall, rule, and inspection?
7. Is the IoC included in Active Threat Response, web, or SSL/TLS exclusions?
8. Are the time window and, for HA, the node being examined correct?

For engine and feed status, correlate atr.log with Log Viewer and the Sophos Fusion Firewall Task Queue by timestamp. Logs are read only; undocumented changes to feed data, databases, or services are not a standard troubleshooting step. If the cause remains unclear, collect the CTR, relevant logs, task ID, audit ID, build, and timestamp for Sophos MDR or Sophos Support.

Rollback and change control

Before activation, document the previous switch status, Action, log destinations, and existing exceptions. If an unexpected business disruption occurs, do not immediately create a broad exception.

1. Capture the affected match and business impact.
2. Inform the MDR team, referencing the audit ID and incident.
3. If approved by the relevant business stakeholders, temporarily change the local Action from Log and drop back to Log only.
4. Only if this is also insufficient and MDR agrees, revert the feed to its documented previous state in a controlled manner.
5. After each change, recheck the same business process and the resulting logging.
6. Resolve the cause and restore production protection with a new review date.

In HA environments, check configuration and status on the current Primary. Logs reside on the node that processed the traffic. After a controlled failover, repeat acceptance checks for the Sophos Fusion connection, feed status, new log entries, and real traffic; do not assume uninterrupted MDR or logging continuity.

Checklist

• Xstream Protection Bundle active
• Active MDR entitlement available in Sophos Fusion
• Firewall registered in the correct Sophos Fusion account
• Threat response mode and MDR contact path documented
• Active Threat Response log destination enabled
• MDR threat feeds turned on
• Action deliberately selected and pilot end date set
• Traffic visibility for IPv4, domains, and URLs checked
• Remote source match enabled for DNAT/WAF if required
• Task Queue compared with local status
• Audit ID and incident process understood
• Endpoint context and platform limitations checked
• Exceptions assigned an owner and review date
• Rollback and HA verification documented

Frequently asked questions