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 the environment to the firewall through 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 license, Central 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 arrived or that the affected traffic passes through the required inspections.

MDR threat feeds in eight steps

1. Verify that the firewall has an active Xstream Protection Bundle and Sophos Central has Sophos MDR Essentials or Sophos MDR Complete.
2. Under System > Sophos Central, confirm that the correct firewall is registered with the correct Central account.
3. Document the intended Threat response mode and the operational MDR contact path in Sophos Central.
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, then click Apply.
7. Perform positive and negative checks using Log Viewer, endpoint context, and Sophos Central.
8. Document the audit ID, owners, 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 communication, narrow firewall rules, or a tested recovery path. A broad exception or uncontrolled deactivation can weaken an active 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 Central. The feed is therefore more customer-specific than a general global reputation list. A transmitted IoC can be an IPv4 address, domain, or URL.

The local firewall action determines what happens on a match:

• 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 still be useful when an existing environment first needs to verify visibility, logging, and possible side effects. The pilot needs a fixed end date. Without a planned change, an active MDR integration can otherwise remain permanently without local blocking.

The Threat response mode in Sophos Central and the local feed action are two different layers. The Central mode defines which response permissions the MDR team has. Log only or Log and drop determines how the firewall handles an IoC that has already been sent. Both settings are aligned with the MDR contract and the internal incident process before rollout.

Verify the prerequisites

License and Sophos Central

MDR threat feeds require the Xstream Protection Bundle on the firewall. They also require Sophos MDR Essentials or Sophos MDR Complete in Sophos Central. The Xstream bundle alone does not include a complete MDR service.

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

Responsibilities must also be clear before activation:

• Who may change the Threat response mode in Central?
• Who answers an MDR call or query outside business hours?
• Who may approve an exception?
• Where are the audit ID, incident ID, and technical evidence recorded?
• Which systems may be isolated after a confirmed compromise?

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 Central

The Central reporting column only appears after Send reports and logs to Sophos Central is enabled on the Sophos Central page. XGS 87/87w and 107/107w do not support local reporting, so Central Reporting or Syslog is required on those models.

Also check System services > Notification list for notifications. Enabling a log destination only proves the transport path, not 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 needs a matching firewall rule. Domain matches require Application Classification or an IPS policy in the relevant rule. A complete HTTPS URL path requires Web Proxy with decryption or DPI with a matching SSL/TLS inspection rule.

System-destined traffic 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.

Set up and safely operate Sophos Firewall threat feeds explains the general traffic, module, and inspection logic. It also explains why domain or URL detection can fail without the required 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. Under Action, select Log only for a time-limited pilot or Log and drop after successful acceptance.
5. Click Apply to save.
6. Reload the page and confirm that the switch and action were saved.
7. Check the timestamp, administrator, and change in the Audit Trail.
8. In Sophos Central, confirm that the firewall is online and MDR is assigned to the correct customer or tenant.

Do not broadly change logging, inspection, exceptions, and the action at the same time. A staged rollout shows which change caused a match or side effect.

Verify the effect reliably

Sophos does not publish a general harmless MDR test indicator. Calling a real malware domain or known malicious IP address is therefore not a suitable acceptance test. Split the technical check into several provable layers.

Configuration and transport

1. Check the MDR switch and intended action on the firewall.
2. Verify Central registration and the MDR license.
3. Confirm Active Threat Response logging for the expected destination.
4. In Central, verify whether MDR or firewall tasks were processed successfully.
5. During a real MDR incident, confirm the expected IoC and associated audit ID with the MDR team.

The Sophos Central Firewall Task Queue shows MDR and API jobs. Success confirms that the Central task was processed, but not its effect on a specific traffic flow. For Partial Success or Failed, preserve the affected firewall, entity, action, and credential ID and compare them with the local configuration.

Investigate a match in Log Viewer

Preserve at least this information under Log viewer > Active threat response:

• timestamp, firewall, and, in HA, the processing node
• action and feed name
• source and destination IP address, domain, or URL
• ports and protocol
• event ID and other detail fields
• the audit_ID for MDR

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, plus host_process_user, endpoint_id, and execution_path in the detailed view. These process details do not appear for macOS; identify the endpoint there using its source IP and Central data.

The local summary is available under Reports > Network & threats > Active threat response in the Synchronized IoC list. The Sophos Firewall services and log files overview also explains atr.log. Never assess a single log entry in isolation: correlate firewall, DNS, web, IPS, endpoint, and Central events from the same time window.

Positive and negative checks

A production pilot should include at least these two cases:

1. Positive: A real IoC or incident confirmed by the MDR team creates a traceable entry on the expected firewall with the correct action and audit ID.
2. Negative: A comparable legitimate business process remains reachable and does not trigger an unintended MDR block.

Do not create an artificial MDR IoC without a real incident. Instead, verify configuration, task processing, log transport, and the communication path. A custom third-party pilot feed is safer than a foreign malicious target for a fully controlled traffic test.

Handle an MDR match as an incident

An MDR match is a strong signal, but the log entry alone does not explain the complete attack path. Use a calm process:

1. Preserve the time, action, IoC, feed name, event ID, and audit_ID.
2. Identify the affected host and user through the source IP, DHCP, Synchronized Security, and endpoint data.
3. Open the associated MDR case, detection, and other device events in Sophos Central.
4. Correlate firewall, DNS, web, IPS, and endpoint logs from the same time window.
5. Ask the MDR team why the IoC was added and which response is intended.
6. Start the internal incident-response process after a confirmed compromise.
7. Only then decide on remediation, additional rules, or a narrow exception.

The audit ID identifies the MDR analyst action. It is visible in the Admin detailed view in Log Viewer and under My Products > Firewall management > Tasks Queue in Sophos Central. Include it with the firewall serial number, timestamp, IoC, event ID, and incident ID in any query to MDR.

Manage exceptions carefully

Under Protect > Active threat response > Add threat exclusions, host/network and threat exclusions can be added. These exclusions apply across modules. An exception for an MDR match can therefore also weaken X-Ops, NDR, or third-party threat feeds.

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

Threat-feed configurations cannot be imported or exported separately, although threat exclusions can. MDR feed settings also cannot be transferred through Import existing configuration into the initial configuration of a new Central firewall group. After a migration, restore, or replacement, explicitly recheck the feature, action, logging, and Central assignment.

When no MDR match appears

Do not start with a service restart. Separate the layers first:

1. Are the MDR license, Central account, firewall registration, and Threat response mode correct?
2. Are MDR threat feeds enabled locally, and was the action saved?
3. Did the MDR team actually send the relevant IoC to this environment?
4. Does the Central Task Queue show Success, Partial Success, Failed, or still Pending?
5. Are Active Threat Response logs enabled locally, for Syslog, or in Central?
6. Does the traffic pass through the expected firewall, rule, and inspection path?
7. Is the IoC included in Active Threat Response, web, or SSL/TLS exclusions?
8. Do the time window and, for HA, the inspected node match?

For engine and feed status, correlate atr.log with Log Viewer and the Central Task Queue by time. Read logs only; undocumented changes to feed data, databases, or services are not a standard step. If the cause remains unclear, collect a 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. Do not immediately create a broad exception after unexpected business impact.

1. Preserve the affected match and business impact.
2. Inform the MDR team using the audit ID and incident.
3. If approved, temporarily change the local action from Log and drop back to Log only.
4. Only if that is insufficient and MDR agrees, restore the feed to the documented previous state in a controlled way.
5. Recheck the same business process and log effect after every change.
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 are stored on the node that processed the traffic. After a controlled failover, revalidate the Central connection, feed status, new log entries, and real traffic; do not assume uninterrupted MDR or log continuity.

Checklist

• Xstream Protection Bundle active
• Sophos MDR Essentials or MDR Complete active
• firewall registered with the correct Central account
• Threat response mode and MDR contact path documented
• Active Threat Response log destination enabled
• MDR threat feeds enabled
• action chosen deliberately and pilot time-limited
• traffic visibility for IPv4 address, domain, and URL verified
• Remote source match enabled for DNAT/WAF where needed
• Task Queue and local status compared
• audit ID and incident process known
• endpoint context and platform limits checked
• exceptions include an owner and review date
• rollback and HA check documented

Frequently asked questions