Operating Sophos Firewall NDR and Active Threat Response

Sophos Firewall can provide additional insights into suspicious network traffic with NDR Essentials and NDR Active Threat Intelligence. This is useful when you want to not only block attacks but also detect, investigate, and further process them in Sophos Fusion (formerly Sophos Central), XDR, MDR, or a SIEM.

It’s important to set expectations: NDR on the firewall is not a magic switch that automatically solves every problem. The function requires appropriate licenses, visible traffic, activated log types, consciously selected firewall rules, and a process to evaluate hits. Without this operational part, only additional logs are generated.

Quick decision for SFOS 22: NDR Essentials learns from selected interface flows and keeps detected IP and domain IoCs in a local feed. NDR Active Threat Intelligence, by contrast, only checks traffic for firewall rules in which Scan with NDR Active threat intelligence is enabled. For both features, Action is fixed at Log threats, so the NDR modules themselves don’t block the detected traffic.

Addition from the SFOS 23 documentation: Alerts from NDR Essentials and NDR Active Threat Intelligence are logged, but these alerts alone neither change endpoint Security Heartbeat status nor isolate endpoints. Any necessary containment remains a separately authorised action. This is a documented limitation, not a version change tested here.

For classic indicators of compromise like malicious IP addresses, domains, or URLs, first set up Sophos Firewall Threat Feeds and operate them securely. This article focuses on NDR Essentials, NDR Active Threat Intelligence, and operational evaluation.

Unresolved limit on the Threat Feeds handoff: The Sophos documentation’s ATR prose and SVG traffic matrix disagree about Sophos X-Ops eligibility for certain match directions, particularly destination matching and local-source matching for outgoing traffic. This conflict remains unresolved. Only established cases for the specific module and traffic path can be relied on; statements about MDR, NDR, or third-party threat feeds do not establish equivalent X-Ops behavior, including for DNAT/WAF or system-bound traffic. Disputed cases require restrictive firewall, DNAT/WAF, and access controls independent of the feed, plus authorised, controlled verification of match direction, module, logs, and actual effect. Until the issue is authoritatively clarified, do not make the disputed feed behavior a prerequisite for protection.

Clearly distinguish the terms

Sophos uses several similar names. For admins, distinguishing them is important because each function works differently.

• NDR Essentials: The firewall captures metadata from TLS-encrypted traffic and DNS queries, sends it to the selected Sophos Cloud service for analysis, and detects IoCs such as IP addresses or domains. Network-based insights without a separate sensor VM and without full TLS decryption for every detection.
• NDR Active Threat Intelligence: The firewall uses curated Taegis-NDR patterns, detects suspicious traffic, logs events, and sends them to the Sophos Data Lake. High-signal detection for XDR, MDR, or Security Operations.
• Sophos NDR: Separate NDR product with its own sensor VM, typically via SPAN, Mirror, or TAP. Broader view of east-west traffic, unmanaged devices, and internal network movements.
• Threat Feeds: IoC lists like IPs, domains, or URLs are checked against traffic. Block or monitor known malicious targets or sources.

NDR Essentials and NDR Active Threat Intelligence thus extend the firewall’s view. Sophos NDR is a separate architecture with a separate sensor. Third-party Threat Feeds are another component: They work indicator-based and can directly block depending on the action.

When deployment is sensible

NDR and Active Threat Response are particularly useful when a firewall is not just operated as a packet filter but is part of a detection-and-response process.

Typical scenarios:

• Client internet traffic should be checked for suspicious targets or patterns.
• Servers or DMZ systems should provide additional detection signals.
• XDR, MDR, or SOC should include firewall events in investigations.
• Multiple firewalls should be centrally evaluated in Sophos Fusion or a SIEM.
• There is already a process for alarms, tickets, false positives, and escalation.

Deployment is less sensible if no one checks the events, logs are not forwarded, or relevant firewall rules are not adjusted. In that case, Central Firewall Reporting or Send Sophos Firewall Syslog to SIEM is more important first.

Prerequisites

Before activation, these points should be checked:

• The firewall runs on a supported SFOS version.
• The Xstream Protection Bundle is active for NDR Active Threat Intelligence.
• The exact subscription is verified for NDR Essentials. The Sophos Firewall bundle overview distinguishes the available bundles, but does not replace a live entitlement check: confirm the purchased subscription on the firewall or with the Sophos partner, because NDR Essentials can be assigned differently from NDR Active Threat Intelligence and entitlements can change.
• When using Central Firewall Reporting or optional XDR/MDR analysis for NDR Active Threat Intelligence, enable Send reports and logs to Sophos Central under Sophos Central Services. Investigation in XDR or MDR additionally requires the appropriate XDR, MDR Essentials, or MDR Complete licence. Central export is not a prerequisite for local detection and IPS log review; the Xstream licence, supported platform, global activation, per-rule activation, and IPS logging remain required.
• The relevant log types are activated under System services > Log settings.
• IPS logging is active for NDR Active Threat Intelligence.
• Active-Threat-Response logging is active for NDR Essentials.
• There is a defined owner for review, tuning, exceptions, and escalation.

Before activation, platform limits must be checked. NDR Essentials is supported on all Gen.1 and Gen.2 XGS appliances as well as VMware, KVM, Hyper-V, Azure, AWS, XEN, and software appliances, but not in Active-Active HA. NDR Active Threat Intelligence is additionally unsupported on XGS 87, XGS 87w, XGS 88, and XGS 88w; the other listed platforms are supported. In HA environments, Understand Sophos Firewall HA Cluster Variants should be checked first.

This guide covers SFOS 22.0 MR2. NDR Active Threat Intelligence arrived in 22.0 MR1, when Sophos also extended NDR Essentials to XGS appliances and virtual, software, and cloud firewalls. Before rolling out on an older 22.0 build, follow the Sophos Firewall firmware update preparation guide, record the installed build, and verify the supported upgrade path and current known-issue status in the firewall and the partner or support portal.

Configure NDR Essentials

Configure NDR Essentials under Protect > Active threat response > NDR Essentials and Active threat intelligence.

Basic procedure:

1. Activate NDR Essentials.
2. Add relevant interfaces.
3. Choose data center location for analysis.
4. Set minimum threat score consciously.
5. Check action. NDR Essentials initially detects and logs.
6. Open System services > Log settings.
7. Activate logging for Active threat response.
8. Select Save, then check Log Viewer, Reports, or Central after a few minutes.

For Data center location, SFOS selects the region with the lowest latency by default. Changing it later can lose analyses in progress. Don’t use the region as a performance-tuning switch: first settle data residency, internal approval, and reachability, document the region and time, and run a new test after any necessary change.

When selecting interfaces, do not choose everything indiscriminately. SFOS 22 supports physical interfaces, VLANs directly on physical interfaces, LAGs, and bridge members in LAN, DMZ, and custom zones. RED and XFRM interfaces, VLANs over LAG or bridge, the dedicated management interface, and WAN and Wi-Fi zones aren’t supported. If a monitored interface is unbound from its zone, SFOS removes it from the NDR list. The firewall only needs to monitor one side of the flow.

If no interfaces are selected, NDR Essentials will not detect new IoCs from the traffic. However, the firewall can still work with already detected IoCs. This is easy to overlook in operation.

For Minimum threat score, High risk (Score 9 and 10) - Recommended is a sensible starting point. Sophos keeps IoCs with scores of 6 or higher. The Summary widget shows monitored traffic flows and unique IoCs grouped by score; the number of IoCs that can be stored depends on appliance size. For subsequent traffic, SFOS generates logs, email notifications, and local and Central reports according to the configured destinations.

Each IoC has a TTL, and a daily job removes expired entries. If an IoC later receives a lower score, the stored score remains unchanged and only the TTL is updated. For a higher score, SFOS also updates the rating. Under Threat indicators, searches can use an IP address, domain, or partial string. This dynamic behavior matters before turning a single value into a permanent block.

NDR Essentials itself remains on Log threats. If a confirmed IoC must be blocked selectively, connect to the firewall over SSH, choose 5. Device Management and then 3. Advanced Shell, and inspect the current feed with the read-only commands cd /content/ndr and cat threatfeed.json. Under Hosts and services > IP host or FQDN host, create an object for exactly that IP address or domain. Under Rules and policies > Firewall rules, a narrow, logged drop rule uses this object as the Destination network and sits above a more general allow rule.

This is a controlled manual action, not permanent feed automation. Source, ticket, owner, expiry date, and the same traffic test belong in the approval. To roll it back, first retain the hit and rule statistics, disable the dedicated drop rule, and repeat the formerly blocked traffic test. Only delete the host object when no other rule references it.

Validate NDR Essentials with the Sophos test

Sophos provides a harmless test that simulates communication with suspicious domain and certificate characteristics. Run it on an approved Windows test device behind the firewall whose traffic actually crosses one of the monitored interfaces. Only obtain the file from Sophos Test. Although the simulation isn’t malicious, run it in an announced test window because it intentionally generates a security event.

1. On Sophos Test, open Network Security > Network Detection and Response and download the test file.
2. Extract the archive on the Windows test device and start Command Prompt as administrator.
3. In the extracted directory, run NdrEicarClient.exe -- all.
4. Wait a few minutes and run the same command a second time.
5. Look for the new IoC under Threat indicators and the matching NDR event under Log viewer > Active threat response.

The first run provides the connection for cloud analysis. After NDR classifies the destination as an IoC and updates the firewall feed, the second run confirms local detection and logging. If no event appears, first check the monitored interface, the actual egress path, cloud connectivity, Active Threat Response logging, and the waiting time. An enabled switch alone doesn’t replace this end-to-end test.

Configure NDR Active Threat Intelligence

NDR Active Threat Intelligence uses curated Taegis-NDR detection patterns. The firewall detects and logs matching events and forwards them to the Sophos Data Lake. These signals can then be investigated in Sophos Fusion, XDR, MDR, or a SOC context.

Typical patterns include misuse of Certutil to download executable files, SSH scanning and brute-force attempts by an already compromised host, HTTP GET traffic on the standard DNS port, or data exfiltration with legitimate tools such as finger. These activities cannot always be blocked immediately as confirmed threats. They are strong investigation signals and must be correlated with host, user, and other network information.

Basic procedure:

1. Open Protect > Active threat response > NDR Essentials and Active threat intelligence.
2. Activate NDR Active threat intelligence.
3. Choose minimum severity level.
4. Check Action. The action is set to Log threats.
5. Open System services > Log settings.
6. Activate IPS logging.
7. Save.
8. Open Rules and policies > Firewall rules and edit a relevant rule.
9. Under Other security features, activate the option Scan with NDR Active threat intelligence.
10. Save changes and validate with defined traffic.

The last point is crucial. Global activation alone is not enough. NDR Active Threat Intelligence must be activated in each firewall rule whose traffic is to be analyzed.

Minimum severity level is a cumulative threshold. Critical (1) includes only critical patterns, while Warning (5) includes every level from Critical through Warning. The Summary widget shows the total for the last seven days and groups detections by severity. The threshold must match the available analysis capacity; broad collection without a triage process only creates more unattended signals.

Which rules to select first

A good rollout does not start on all rules at once. A controlled pilot with well-understood traffic is better.

Sensible starting points:

• Client networks with internet access.
• Server networks with outgoing internet access.
• DMZ rules with published services.
• Rules for particularly critical internal segments.
• Rules with already activated IPS, Web, or TLS Inspection concept.

Rules without clear logging, without an owner, or with very broad unclassified traffic are not a good start. The rule base should be cleaned up first. An adaptable pilot example is a logged LAN-to-WAN rule for a managed test network such as 192.0.2.0/24; replace this documentation network with the real test network. What matters is that the clients demonstrably match this rule and the owner reviews the additional IPS events. For rule analysis and matching, see Test firewall rule with Log Viewer, Policy Test, and Packet Capture.

Visibility, TLS and DNS

NDR signals are only as good as the traffic the firewall actually sees. For NDR Essentials, the important point is that the feature can evaluate TLS metadata and DNS queries and therefore provide indicators for suspicious encrypted communication without full TLS Inspection. However, this does not replace properly planned Web or TLS Inspection when content, downloads, web categories, or additional protection modules must be inspected.

For NDR Active Threat Intelligence and other security features, rule and inspection planning remains decisive. If traffic does not pass through the expected firewall rule, logging is missing, or the browser bypasses the expected path, gaps appear in the evaluation.

This does not mean that TLS Inspection should be activated everywhere immediately. TLS Inspection is its own operational project with certificates, exceptions, data protection, performance, and support effort. For a planned rollout, Properly introduce Sophos Firewall TLS Inspection is suitable.

QUIC and HTTP/3 can also influence web and inspection concepts. If browser traffic bypasses classic HTTPS inspection paths, Properly block Sophos Firewall QUIC and HTTP/3 should be checked.

Logs and evaluation

Without log evaluation, NDR is hardly useful. Depending on the function, different log areas are relevant.

• NDR Essentials: Active threat response logs, Threat indicators, Central Reporting, or SIEM.
• NDR Active Threat Intelligence: IPS logs, Log Viewer filter Category is NDR Active threat intelligence, Central Firewall Reporting.
• XDR/MDR evaluation: Sophos Fusion Threat Analysis Center, Detections, or Cases.
• Long-term correlation: Syslog, SIEM, SOC, or MDR platform.

For local reports, go to Reports > Network & Threat > Intrusion attacks. In Sophos Fusion, the events are under My Products > Firewall Management > Report Generator; select the IPS report under Report templates. Both views complement the Log Viewer filter but do not replace checking the actual traffic path and matching firewall rule.

For Sophos Fusion, the firewall must send logs and reports to Central. The procedure is described in Activate and operate Sophos Firewall Central Reporting. For a custom SIEM, the appropriate log type must be forwarded via Syslog and parsed in the target system. Simply activating the function does not prove that detections can be found later.

Checkpoints after activation:

• Do local log entries appear in the Log Viewer?
• Are Active-Threat-Response or IPS logs sent to Central?
• Do the logs arrive in the SIEM?
• Are fields like Source, Destination, Firewall, Rule ID, and Category correctly recognized?
• Is there a dashboard or search for NDR/ATR hits?
• Is it clear who evaluates hits?

For NDR Active Threat Intelligence acceptance, an empty report isn’t proof of success. First confirm the global setting, IPS logging, Central forwarding when Central/XDR/MDR evaluation is used, and the counter of the pilot rule that actually matched. Treat a detection as a positive end-to-end criterion only when it comes from a Sophos-documented test or an existing, safely understood event. Unverified exploit or malware simulations don’t belong on a production network.

What should happen when a hit occurs

A hit is initially an investigation signal. Not every hit is automatically a confirmed attack, but every relevant hit needs a process.

The SFOS 23 documentation makes this clear for both NDR features: an alert alone does not change endpoint Security Heartbeat status or trigger endpoint isolation. Any isolation or manual block needed after investigation must be separately authorised, carried out, and checked for its actual effect.

Minimal process:

1. Record source IP, destination IP, user, rule, and time.
2. Check in the Log Viewer which rule and module were involved.
3. Search in Central, XDR, MDR, or SIEM for further events of the same host.
4. Correlate endpoint, DNS, web, and authentication logs.
5. Decide whether endpoint isolation, a narrow firewall block, or further analysis is necessary. Only consider a Threat Exclusion after confirming a false positive and documenting its impact.
6. Document the result.

For repeated false positives, a broad exception should not be set immediately. A narrow exception with reason, ticket, and review date is better. Exceptions in Active Threat Response can remove protection and therefore belong in a controlled process.

A Threat Exclusion removes a source or destination from scanning by every Active Threat Response module, including NDR Active Threat Intelligence. It doesn’t apply only to one signature and can therefore weaken other threat feeds as well. Investigate the context first. Only if the false positive is confirmed and the cross-module impact is acceptable should you consider a tightly scoped host, network, IP address, domain, or URL exclusion; otherwise, ask Sophos Support to review the log details and pattern information.

Roll back safely

A rollback should remove the new analysis selectively, not disable unrelated protection modules:

1. Record the time range, pilot rules, interface selection, thresholds, and latest relevant hits.
2. For NDR Active Threat Intelligence, first remove Scan with NDR Active threat intelligence only from the pilot rules. Then disable the global switch if required.
3. For NDR Essentials, remove the monitored interfaces or disable the switch. When no interfaces are selected, Sophos states that the firewall can still act on previously detected IoCs, so check Threat indicators and Log viewer > Active threat response afterward.
4. Disable and test manual IoC drop rules separately. Turning off NDR Essentials doesn’t remove them.
5. Review Threat Exclusions created during the pilot separately and only remove them if no other approved use case needs them.
6. Only roll back IPS logging, Central Reporting, or Syslog if no other protection or operational function needs those settings.

The rollback is successful when the pilot rule still handles the expected traffic, NDR Active Threat Intelligence is no longer enabled on it, and no manual block rule or pilot exclusion remains active unintentionally. With NDR Essentials, previously detected IoCs can continue to generate logs until they expire, so such entries don’t automatically mean the rollback failed.

Typical mistakes

• NDR Active Threat Intelligence is activated globally but not enabled in the firewall rules.
• NDR Essentials is activated, but no suitable interfaces are selected.
• IPS or Active-Threat-Response logging is not active.
• Central Reporting or Syslog is not set up, although central evaluation is expected.
• Detections are generated, but no one checks them.
• Severity or Threat Score is set too sensitively, creating unnecessary noise.
• Exceptions are set too broadly.
• Active-Active HA or small XGS appliance models are planned, although the function is not supported there.
• TLS Inspection is treated as a side issue instead of being properly planned.

Two issues fixed in early SFOS 22.0 builds can also be misleading: NC-152904 showed unsupported interfaces in the NDR selection, and NC-165825 incorrectly showed Doesn’t comply in Firewall Health Check for virtual firewalls. Both were fixed in build 411. If either symptom appears, use the ID as the lookup key in the current partner or support portal, compare the installed build locally, and follow the supported update path instead of bypassing the platform restrictions.

Checklist

• SFOS version and license checked.
• Supported appliance or platform confirmed.
• HA mode checked.
• Sophos Fusion registration checked if Central Reporting, XDR, or MDR is used.
• Relevant log types activated under System services > Log settings.
• NDR Essentials interfaces consciously selected.
• Data center location and minimum threat score documented.
• NDR Active Threat Intelligence activated.
• Relevant firewall rules marked with Scan with NDR Active threat intelligence.
• Log Viewer, Central Reporting, or SIEM checked for hits.
• Owner, alerting, false-positive process, and review interval documented.

Frequently Asked Questions